PAM modules

[Dag-Erling Smørgrav]

We currently have a number of PAM modules in ports, and while some of
them are specific to certain third-party software, many aren't. I
believe we would benefit from importing at least some of these into
base. My question is: which ones?

DES
--
Dag-Erling Smørgrav - d...@des.no
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/16/11 08:05, Dag-Erling Smørgrav wrote:
> We currently have a number of PAM modules in ports, and while some
> of them are specific to certain third-party software, many aren't.
> I believe we would benefit from importing at least some of these
> into base. My question is: which ones?

LDAP? (We do currently have some work on LDAP integration but not
sure if the community would be interested -- this would need an import
of stripped down OpenLDAP) and modifies OpenSSH to support public key
in LDAP directory.

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOc4eUAAoJEATO+BI/yjfBUFgH/1+fWilKMu/4YJu0X2hUpDJI
EvOuG1Mx481eXAaTV+yfVaHwGs039EQIgJpk18CCC+UbCOV4kG0B0XpK5D3VdOPE
nHoXB38YiiyBe+LVYg3u1YPrjPAoULK2ih4qMOki6Wbtw8EqV344BNd0a70joY+z
JTnNsfJQcMKAO8RpppPxuf/yy6goRcQSMUmDCvxBiOS923vZu641kyBEzyFeC+GU
BJjLTXxcBQ5V9XNGgHmp7g4nwHPNwi0aOPs6Gudgj7u3hKKEkcY//Irdac+chopF
St4AJBCffsdl49TbQMYKUvTSIyUb5YeI8ixtFzwhhdGUZLEPDOvtOJNooCd1x/w=
=VRQC
-----END PGP SIGNATURE-----

[Mark Felder]

On Fri, 16 Sep 2011 12:29:56 -0500, Xin LI <del...@delphij.net> wrote:

> LDAP? (We do currently have some work on LDAP integration but not
> sure if the community would be interested -- this would need an import
> of stripped down OpenLDAP) and modifies OpenSSH to support public key
> in LDAP directory.

All of this would be greatly appreciated by myself and my fellow coworkers.

[Corey Smith]

On 09/16/2011 11:05 AM, Dag-Erling Smørgrav wrote:
> My question is: which ones?

security/pam_ssh_agent_auth

It is BSD licensed and handy for sudo.

-Corey Smith

[Robert Simmons]

2011/9/16 Dag-Erling Smřrgrav <d...@des.no>:

> We currently have a number of PAM modules in ports, and while some of
> them are specific to certain third-party software, many aren't.  I
> believe we would benefit from importing at least some of these into
> base.  My question is: which ones?

Perhaps google authenticator?
http://code.google.com/p/google-authenticator/
http://www.freebsd.org/cgi/url.cgi?ports/security/pam_google_authenticator/pkg-descr

[David Cornejo]

2011/9/16 Dag-Erling Smørgrav <d...@des.no>

Another vote for LDAP

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/16/11 10:39, Mark Felder wrote:
> On Fri, 16 Sep 2011 12:29:56 -0500, Xin LI <del...@delphij.net> wrote:
>
>> LDAP? (We do currently have some work on LDAP integration but not
>> sure if the community would be interested -- this would need an import
>> of stripped down OpenLDAP) and modifies OpenSSH to support public key
>> in LDAP directory.
>
> All of this would be greatly appreciated by myself and my fellow coworkers.

I can publish the source code but note that it's for FreeBSD 8.2 and
OpenLDAP needs to be updated.

Changes are moderately intrusive but is in a manageable shape, it's used
in production at a company who wishes to remain anonymous (the work is
mostly putting together several open source models, fix bugs and they
have assigned a delegate for copyright to license it under compatible
license). I need to find some time to adapt the code to -HEAD and call
for feedback.

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOc8WDAAoJEATO+BI/yjfB9p4IAIT82Z8I+6jkhyhCL/wbcXQk
KPAfpuPQCUjn1Lm2C/UUgWdBO17SYzBJUlyt1FJuDctGab18mJgvWMvjb+cUgXKH
lfcxUdmBxkhwwTSE7EfB4qLphn28si67INOZN3xSVzyXuxGTqwXcO5fJlbJly77B
nNS8JUu3X9tjMwGHwOWjG7R6n/bEdsmJUdWtMT2t3B6thFsStgqshTnKoBs18vPN
vWdY7vdX3Mco1kjLTGoq3DZUxZyBxn75IvSSpvFLtn4T4YT22U2V0KY5h1JUsz9q
MVQGLpUpudyFI8T+rzbQR3yxtv7gqgumlIuYpjF9rP0FtoQDcB2vRlMzAqM5j1o=
=m5hN
-----END PGP SIGNATURE-----

[Mike Carlson]

On 09/16/2011 08:05 AM, Dag-Erling Smørgrav wrote:
> We currently have a number of PAM modules in ports, and while some of
> them are specific to certain third-party software, many aren't. I
> believe we would benefit from importing at least some of these into
> base. My question is: which ones?
>
> DES

LDAP support out of the box would be fantastic.

Mike C

[Dan Lukes]

On 09/16/11 17:05, Dag-Erling Smørgrav:

> My question is: which ones?

An anti-brutal force module would be nice.

security/pam_af is my favorite. Configurable, fast, BSD license.

Dan

[Brandon Gooch]

On Sep 16, 2011 10:21 AM, "Dag-Erling Smørgrav" <d...@des.no> wrote:
>
> We currently have a number of PAM modules in ports, and while some of
> them are specific to certain third-party software, many aren't. I
> believe we would benefit from importing at least some of these into
> base. My question is: which ones?
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no

+1 for LDAP

-Brandon

[Jason Hellenthal]

On Sat, Sep 17, 2011 at 01:18:27AM -0400, Jason Hellenthal wrote:
>
> +1 for LDAP

Do not mean to reply to my own post but seems these offer the most IMHO
benefit to the project and end-users.

security/pam_jail A PAM module dropping users in jails after login
security/pam_krb5 A Pluggable Authentication Module for Kerberos5
security/pam_ldap A pam module for authenticating with LDAP
security/pam_mkhomedir Create HOME with a PAM module on demand
security/pam_p11 A PAM module using crypto tokens for auth authenticate against Unix PAM
security/pam_pwdfile A pam module for authenticating with flat passwd files
security/pam_require A PAM module for restricting access based on unix group or username
security/pam_smb NetBIOS domain logon PAM module
security/pam_ssh_agent_auth PAM module which permits authentication via ssh-agent
sysutils/pam_mount A PAM that can mount volumes for a user session

[Jason Hellenthal]

+1 for LDAP

On Fri, Sep 16, 2011 at 10:25:16PM -0500, Brandon Gooch wrote:

[Lev Serebryakov]

Hello, Xin.

You wrote 16 сентября 2011 г., 21:29:56:

> LDAP? (We do currently have some work on LDAP integration but not
> sure if the community would be interested -- this would need an import
> of stripped down OpenLDAP) and modifies OpenSSH to support public key
> in LDAP directory.

Minimal ldap client, nss/pam_ldap and SSH keys in LDAP out-of-box is
great!
But it is disagree with trend to stirp-down base system :(

--
// Black Lion AKA Lev Serebryakov <l...@FreeBSD.org>

[Lev Serebryakov]

Hello, Jason.

You wrote 17 сентября 2011 г., 9:24:34:

> security/pam_ldap A pam module for authenticating with LDAP

It needs nss_ldap too for reasonnabel work, and in such case
`net/nss-pam-ldapd' is better, as it two-in-one, may be with stripped
out cache daemon.

But all these ldap-related modules are strange in their desire to
have config files like "ldap.conf" :)

--
// Black Lion AKA Lev Serebryakov <l...@FreeBSD.org>

[Hartmann, O.]

Also a strong vote for LDAP support. LDAP is our backend for several
server systems and it is a kind of pain
having to think first for the ports to be installed. Also I suspect and
hope a better integration if LDAP gets
part of the core system.

Regards,
Oliver

[Dag-Erling Smørgrav]

Jason Hellenthal <jh...@DataIX.net> writes:
> security/pam_jail A PAM module dropping users in jails after login
> security/pam_krb5 A Pluggable Authentication Module for Kerberos5

We already have that.

> security/pam_ldap A pam module for authenticating with LDAP

Not going to happen, since we don't have LDAP in base.

> security/pam_mkhomedir Create HOME with a PAM module on demand
> security/pam_p11 A PAM module using crypto tokens for auth authenticate against Unix PAM

Requires a PKCS11 implementation in base. I never finished the one I
started on...

> security/pam_pwdfile A pam module for authenticating with flat passwd files
> security/pam_require A PAM module for restricting access based on unix group or username

What does this do that pam_group doesn't?

> security/pam_smb NetBIOS domain logon PAM module

Apparently requires Perl to run, although this may be a bug in the port

> security/pam_ssh_agent_auth PAM module which permits authentication via ssh-agent
> sysutils/pam_mount A PAM that can mount volumes for a user session

That leaves us with the following candidates:

- pam_jail
- pam_mkhomedir
- pam_mount
- pam_pwdfile
- pam_ssh_agent_auth

and possibly also

- pam_require
- pam_smb

Note that pam_mkhomedir and pam_mount can be implemented using pam_exec
(possibly with some improvements) and scripts.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Fahad Ahmad]

Not everybody requires LDAP/PAM , so making it part of base is not a
valid reason.
Same can apply for any other 3rd party port (Apache,Samba,etc etc).

[Ryan Steinmetz]

On (09/17/11 14:30), Hartmann, O. wrote:
> On 09/16/11 23:36, Mike Carlson wrote:

I think some caution should be used whenever we discuss merging things
into the base system. There may be other ways of achieving the same
functionality, without the challenges that come with merging things
directly into the base system. Ports tend to be easier to update (in
terms of version bumps/features additions) when compared to things that
become part of base.

I think an interesting concept would be something that gave us the
ability to (easily) tie certain ports into software from the base system.
Something that would allow the software to be more easily kept current.
Perhaps this could be done via some sort of base-integrated ports
category that require extra-special care/controls when being updated.

Using the above idea, perhaps we could have ISOs or the like available
that include these 'base-integrated' ports pre-installed, thus giving
users the ability to (effectively) have an out-of-the-box solution that
included LDAP support, etc., while still having these 'base-integrated'
ports loosely coupled with the base OS. The concept could keep the base
system lean, but provide the flexibility that users desire.

Obviously there are some complexities associated with implementing the
framework and details that would need to be worked out, but this could
address:
-The desire to keep the base system lean
-The desire to provide certain features out-of-the-box
-The ability to keep these 'base-integrated' ports more current in terms
of features/functionality

-r

--
Ryan Steinmetz
PGP: EF36 D45A 5CA9 28B1 A550 18CD A43C D111 7AD7 FAF2

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/17/11 06:53, Ryan Steinmetz wrote:
[...]

I've put a preliminary patchset at:

http://people.freebsd.org/~delphij/misc/freebsd8.2-ldap.diff.xz

For interested parties.

That work was done to meet quakelee@'s company's needs (mostly done by
him, I helped him with some minor things with my weekends) and the
patch might needs some cleanup work (I've stripped down the unrelated
part like bringing rsync, sudo to their base system but it's well
possible rthat I've missed something or haven't removed some junk in
this patchset -- ask me and/or quakelee@ if that's the case, their
patched system works fine and I have everything in our git so let me
know if that works).

Speaking for having or not this by default for FreeBSD: It's not hard
for us to make a customized distribution, and the patchset allows one
to build a LDAP-free system, we have stripped down OpenLDAP to only do
client side and the symbols have been renamed to avoid conflicts with
port OpenLDAP. Personally I don't consider an Operating System that
have no built-in LDAP support as a complete one and consider this:
what happens when OpenLDAP's shared library version bumped (this is
not rare) and your LDAP-linked sshd, pam models would do?

"base-integrated" port -- I wouldn't object if that would ever happen
but I bet it's a much bigger one than LDAP integration :) It may take
me a day or two days to get our patchset cleaned up and updated to
- -HEAD and latest OpenLDAP -stable and universe it, plus test on amd64,
but implementing a shiny new framework is not something we (I and
quakelee@) could do.

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOdQlKAAoJEATO+BI/yjfB1YgIAJE4l+KOsTg+BPtWe3lJhLfF
bTk7HlpeZOpTgTYFJ93E0+kIls4+iZN6LfwNaiDGEQXMA6Ot7utf2oa87uK+dSxv
9mjj/cUgkYOaN2wTOs15H2bTKbq/Fyh0eD2ewZ0cu9U9S+6earPK/n/VseQYa9M7
aXcOdcrVqKpTMb7+JiEDjiAzGYKgnwldoTFEnKaVoKay032gWPP5RJ1rMiZa8HXu
p/1QrMgpumg8rS0Tk1qlpSljAOqG3T5/iEXgcIYvi6APbp/Wy9KGvLO68/xJodaf
gxLKZ1Hx4xE+4vIou/5jV9XqP2XcIueH1WJFdyDx5tDEyGrpP3NIs2lObupQ36M=
=oorR
-----END PGP SIGNATURE-----

[Łukasz Wąsikowski]

W dniu 20:59, Xin LI pisze:

>> We currently have a number of PAM modules in ports, and while some
>> of them are specific to certain third-party software, many aren't.
>> I believe we would benefit from importing at least some of these
>> into base. My question is: which ones?

> LDAP? (We do currently have some work on LDAP integration but not
> sure if the community would be interested -- this would need an import
> of stripped down OpenLDAP) and modifies OpenSSH to support public key
> in LDAP directory.

I'd love to see LDAP integration, I'm looking forward to it.

--
Best regards,
Lukasz Wasikowski

[Dag-Erling Smørgrav]

Xin LI <del...@delphij.net> writes:
> LDAP? (We do currently have some work on LDAP integration but not
> sure if the community would be interested -- this would need an import
> of stripped down OpenLDAP) and modifies OpenSSH to support public key
> in LDAP directory.

I would vote for importing a *complete* OpenLDAP, unless there are good
reasons not to; "slim base" isn't, considering how useful LDAP is.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Hartmann, O.]

On 09/18/11 20:03, Dag-Erling Smørgrav wrote:
> Xin LI <del...@delphij.net> writes:
>> LDAP? (We do currently have some work on LDAP integration but not
>> sure if the community would be interested -- this would need an import
>> of stripped down OpenLDAP) and modifies OpenSSH to support public key
>> in LDAP directory.
> I would vote for importing a *complete* OpenLDAP, unless there are good
> reasons not to; "slim base" isn't, considering how useful LDAP is.
>
> DES

If this is a real opportunity,

+1 for that.

[Mike Tancsa]

On 9/16/2011 3:10 PM, Corey Smith wrote:
> On 09/16/2011 11:05 AM, Dag-Erling Smørgrav wrote:
>> My question is: which ones?
>
> security/pam_ssh_agent_auth
>
> It is BSD licensed and handy for sudo.

Neato, I didnt know of this module for sudo! However, with the default
install on AMD64, I am getting coredump.

I added


# auth
auth include system
-
+auth sufficient /usr/local/lib/pam_ssh_agent_auth.so
file=/etc/sudokeys debug
# account
account include system

to /usr/local/etc/pam.d/sudo

and added

--- sudoers.sample 2011-09-19 13:24:56.000000000 -0400
+++ sudoers 2011-09-19 13:29:17.000000000 -0400
@@ -62,6 +62,10 @@
## Uncomment to enable special input methods. Care should be taken as
## this may allow users to subvert the command being run via sudo.
# Defaults env_keep += "XMODIFIERS GTK_IM_MODULE QT_IM_MODULE
QT_IM_SWITCHER"
+
+Defaults env_keep += SSH_AUTH_SOCK
+
+


I must be missing something obvious?

---Mike


--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/

[Patrick Lamaiziere]

Le Fri, 16 Sep 2011 15:10:09 -0400,
Corey Smith <cors...@gmail.com> a écrit :

Hello,

> > My question is: which ones?
>
> security/pam_ssh_agent_auth
>
> It is BSD licensed and handy for sudo.

But sudo itself is not the in base, so?

(while i'm here, +1 for ldap)

Regards.

[Mike Tancsa]

On 9/19/2011 2:00 PM, Mike Tancsa wrote:
> On 9/16/2011 3:10 PM, Corey Smith wrote:
>> On 09/16/2011 11:05 AM, Dag-Erling Smørgrav wrote:
>>> My question is: which ones?
>>
>> security/pam_ssh_agent_auth
>>
>> It is BSD licensed and handy for sudo.
>
>
> Neato, I didnt know of this module for sudo! However, with the default
> install on AMD64, I am getting coredump.

Actually, I tried the same setup on i386 and it seems to work just fine.
However, on an AMD64 machine, sudo just coredumps. Anyone running this
setup on amd64 ?

Running with -D9, normally it looks something like

% sudo -D9 su
sudo: settings: debug_level=9
sudo: settings: progname=sudo
sudo: settings: network_addrs=....
sudo: sudo_mode 1
sudo: policy plugin returns 1
sudo: command info: umask=022
sudo: command info: command=/usr/bin/su
sudo: command info: runas_uid=0
sudo: command info: runas_gid=0
sudo: command info: runas_groups=0,5
sudo: command info: closefrom=3
sudo: command info: set_utmp=true
sudo: command info: login_class=default

where as on amd64,

% sudo -D9 su
sudo: settings: debug_level=9
sudo: settings: progname=sudo
sudo: settings: network_addrs=....
sudo: sudo_mode 1
Segmentation fault

It seems to die in the call to

static int
policy_check(struct plugin_container *plugin, int argc, char * const argv[],
char *env_add[], char **command_info[], char **argv_out[],
char **user_env_out[])
{
return plugin->u.policy->check_policy(argc, argv, env_add, command_info,
argv_out, user_env_out);
}


I cant get it to coredump since its setuid. Before I start adding more
debug printfs, does anyone have any suggestions as to what it might be ?


---Mike

[Gary Palmer]

On Tue, Sep 20, 2011 at 03:13:32PM -0400, Mike Tancsa wrote:
> On 9/19/2011 2:00 PM, Mike Tancsa wrote:
> > On 9/16/2011 3:10 PM, Corey Smith wrote:

If you do

sysctl kern.sugid_coredump=1

can you get a coredump?

Gary

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/18/11 11:03, Dag-Erling Smørgrav wrote:
> Xin LI <del...@delphij.net> writes:
>> LDAP? (We do currently have some work on LDAP integration but
>> not sure if the community would be interested -- this would need
>> an import of stripped down OpenLDAP) and modifies OpenSSH to
>> support public key in LDAP directory.
>
> I would vote for importing a *complete* OpenLDAP, unless there are
> good reasons not to; "slim base" isn't, considering how useful LDAP
> is.

The main concern I have is that users might want to stay on an older
FreeBSD release, while wanting features of a new OpenLDAP. That's why
I would prefer a libxml style import -- users always have choice to
install a new OpenLDAP without any concern of breaking their system
and we can always deliver security fixes with freebsd-update. Would
that make the trimmed down and renamed OpenLDAP import sound sensible?

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOeOpGAAoJEATO+BI/yjfBmX4H/0fx3Ld8+EkkbYX5LTXSyBt4
9x2ARzTi18+G/j+eYaiNutD4P+9voLnIGEiJwSTa5tXCtKkysRKZUkvetr+8uV7z
6aykrn+oaD0ol6nhWHESL4sCZh8nAoXLzQYaXKqw3FYH9pbQlckjr26UM4WGT8k/
Z129X0fh6TVN8vaztruJGNkLle69ruAgWpxMvTfligC8+Pbj7mV6YmdAwUidH3hL
YtlM7UoogZZzex3qpTUMq6gpKOA0BZTxPhOXWKhfgEz8enFuiYCo1Vs4DpS8S1i+
sbRcn6fTImRkC1FVDpPXEj/piwN/cIb/xv70gfeqgjxUL4LMFSrn9L5kkQ4K0wY=
=mRAO
-----END PGP SIGNATURE-----

[Mike Tancsa]

On 9/20/2011 3:21 PM, Gary Palmer wrote:
>
> If you do
>
> sysctl kern.sugid_coredump=1
>
> can you get a coredump?

Tried that too.

% sysctl -a | grep core
kern.corefile: %N.core
kern.nodump_coredump: 0
kern.coredump: 1
kern.sugid_coredump: 1
debug.elf64_legacy_coredump: 1
debug.elf32_legacy_coredump: 1

Actually, my mistake on i386. It seems the plugin works with

sudo-1.8.1_5

but not 1.8.2

Seems to die in the function policy_check in sudo.c

return plugin->u.policy->check_policy(argc, argv, env_add, command_info,
argv_out, user_env_out);
}

---Mike
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/

[Dag-Erling Smørgrav]

Xin LI <del...@delphij.net> writes:
> The main concern I have is that users might want to stay on an older
> FreeBSD release, while wanting features of a new OpenLDAP. That's why
> I would prefer a libxml style import -- users always have choice to
> install a new OpenLDAP without any concern of breaking their system
> and we can always deliver security fixes with freebsd-update. Would
> that make the trimmed down and renamed OpenLDAP import sound sensible?

Yes, you have a point. So you're saying:

- client side only (for nss_ldap, pam_ldap etc)
- namespace hacks to avoid colliding with the port

right? I would definitely support that.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Lev Serebryakov]

Hello, Dag-Erling.

You wrote 21 сентября 2011 г., 1:19:11:

> Yes, you have a point. So you're saying:
> - client side only (for nss_ldap, pam_ldap etc)
> - namespace hacks to avoid colliding with the port
> right? I would definitely support that.

Maybe, BSD implementation, based on asn.1 to C compiler from Lev
Walkin (http://lionet.info/asn1c/blog/)? ;-)

Client-only part doesn't look very hard to implement, when all
boilerplate code (packing/unpacking/network processing, etc) is
auto-generated from RFCs.

--
// Black Lion AKA Lev Serebryakov <l...@FreeBSD.org>

_______________________________________________

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/20/11 15:25, Lev Serebryakov wrote:
> Hello, Dag-Erling. You wrote 21 сентября 2011 г., 1:19:11:
>
>> Yes, you have a point. So you're saying: - client side only (for
>> nss_ldap, pam_ldap etc) - namespace hacks to avoid colliding with
>> the port right? I would definitely support that.
> Maybe, BSD implementation, based on asn.1 to C compiler from Lev
> Walkin (http://lionet.info/asn1c/blog/)? ;-)
>
> Client-only part doesn't look very hard to implement, when all
> boilerplate code (packing/unpacking/network processing, etc) is
> auto-generated from RFCs.

That's true but is there any very compelling reason to do that (not
say no if someone really want to invest time on this and maintain it)
instead of just using an actively maintained codebase? The OpenLDAP
license is pretty similar to a BSD license:

===================================
The OpenLDAP Public License
Version 2.8, 17 August 2003

Redistribution and use of this software and associated documentation
("Software"), with or without modification, are permitted provided
that the following conditions are met:

1. Redistributions in source form must retain copyright statements
and notices,

2. Redistributions in binary form must reproduce applicable copyright
statements and notices, this list of conditions, and the following
disclaimer in the documentation and/or other materials provided
with the distribution, and

3. Redistributions must contain a verbatim copy of this document.

The OpenLDAP Foundation may revise this license from time to time.
Each revision is distinguished by a version number. You may use
this Software under terms of this license revision or under the
terms of any subsequent revision of the license.

THIS SOFTWARE IS PROVIDED BY THE OPENLDAP FOUNDATION AND ITS
CONTRIBUTORS ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE OPENLDAP FOUNDATION, ITS CONTRIBUTORS, OR THE AUTHOR(S)
OR OWNER(S) OF THE SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

The names of the authors and copyright holders must not be used in
advertising or otherwise to promote the sale, use or other dealing
in this Software without specific, written prior permission. Title
to copyright in this Software shall at all times remain with copyright
holders.

OpenLDAP is a registered trademark of the OpenLDAP Foundation.

Copyright 1999-2003 The OpenLDAP Foundation, Redwood City,
California, USA. All Rights Reserved. Permission to copy and
distribute verbatim copies of this document is granted.
===================================

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOeRThAAoJEATO+BI/yjfBZc0H/1AftG4jvcAcA4vKVVDum6Bo
4tzA2sm1bK5ci/158ATF6VFvAEYQ3+rmRCDopkXvpbtJDzbuKOUEszI9SW2qfhz+
R0PIl64jYHngP3T6jw5theo+LJ/RHb/pIP7oIll1zANcpJIMHv9N00HY0HAFq4XQ
go3ASif1DU8OjHKWxH5zPLSBvGck6mBj+31J+0/FlohinEG3JJZBLQ+cAElTUV5r
fKhQ4rIlR1wwP7TrStapzdTHsyysAwblIOQ/WtzBhqxJcgh52TxI1QmJmILpmKQ7
vqFMpDnmOmgRZjfzSXfCSpd6ehx1Ko54KOm1m9WaFXI1zv8sTeP7AIoe1HO2fug=
=7ySY
-----END PGP SIGNATURE-----

[Lev Serebryakov]

Hello, Xin.

You wrote 21 сентября 2011 г., 2:34:09:

> That's true but is there any very compelling reason to do that (not
> say no if someone really want to invest time on this and maintain it)
> instead of just using an actively maintained codebase? The OpenLDAP
> license is pretty similar to a BSD license:

My point is not a license. I don't know, what is simpler:
(a) strip-down and rename API for OpenLDAP and later import new releases,
with new strip-downs and renames (IMHO, it is harder, than import and
support almost-intact code, like sendmail or bind),
or
(b) maintain local code, most of which is auto-generated from standard
by very mature and stable tool, as Lev's asn1c is. I know Lev
personally, and he says, that this tool is used by many Telco
operators and other Big Companies and he is not aware about any
outstanding bugs (from year 2007!) even when very complex (much more
complex than LDAPv3) ASN.1 rules are processed. Sometimes he is
contacted for support, but always it is not bugs in compiler, but some
other problems.

Maybe, import and maintaining of hacked OpenLDAP is simpler in
long-standing perspective. Maybe not. I only want to point, that if we
want our own LDAP client library, we don't need to write tons of
non-obvious, error-prone and security-sensitive code by hands.

--
// Black Lion AKA Lev Serebryakov <l...@FreeBSD.org>

[Kostik Belousov]

On Wed, Sep 21, 2011 at 02:43:47AM +0400, Lev Serebryakov wrote:
> Hello, Xin.
> You wrote 21 сентября 2011 г., 2:34:09:
>
> > That's true but is there any very compelling reason to do that (not
> > say no if someone really want to invest time on this and maintain it)
> > instead of just using an actively maintained codebase? The OpenLDAP
> > license is pretty similar to a BSD license:
> My point is not a license. I don't know, what is simpler:
> (a) strip-down and rename API for OpenLDAP and later import new releases,
> with new strip-downs and renames (IMHO, it is harder, than import and
> support almost-intact code, like sendmail or bind),
> or
> (b) maintain local code, most of which is auto-generated from standard
> by very mature and stable tool, as Lev's asn1c is. I know Lev
> personally, and he says, that this tool is used by many Telco
> operators and other Big Companies and he is not aware about any
> outstanding bugs (from year 2007!) even when very complex (much more
> complex than LDAPv3) ASN.1 rules are processed. Sometimes he is
> contacted for support, but always it is not bugs in compiler, but some
> other problems.
>
> Maybe, import and maintaining of hacked OpenLDAP is simpler in
> long-standing perspective. Maybe not. I only want to point, that if we
> want our own LDAP client library, we don't need to write tons of
> non-obvious, error-prone and security-sensitive code by hands.
>

Yes, the question of maintanence of the OpenLDAP code in the base
is not trivial by any means. I remember that openldap once broke
the ABI on its stable-like branch.

Having API renamed during the import for the actively-developed third-party
component is probably a stopper. I am aware of the rename done for ssh
import in ssh_namespace.h, but I do not think such approach scale.

Would the import of openldap and nss + pam ldap modules in src/ give any
benefits over having openldap and ldap nss + pam modules on the dvd1 ?

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/20/11 15:51, Kostik Belousov wrote:
[...]

> Yes, the question of maintanence of the OpenLDAP code in the base
> is not trivial by any means. I remember that openldap once broke
> the ABI on its stable-like branch.

That happen a few times however these are either not essential client
library (libldap and liblber) API or it's not changing parameters or
removing interfaces. Moreover, like the base libbsdxml.so, it's only
intended to be used by base system only so it's relatively easier to
maintain ABI stability, e.g. we can probably just expose only symbols
that we use, etc.

> Having API renamed during the import for the actively-developed
> third-party component is probably a stopper. I am aware of the
> rename done for ssh import in ssh_namespace.h, but I do not think
> such approach scale.

That's right. We did use a similar approach but again, if it's just
libldap and liblber, the change would be quite slow over years. We do
need to patch files.

> Would the import of openldap and nss + pam ldap modules in src/
> give any benefits over having openldap and ldap nss + pam modules
> on the dvd1 ?

Well, for ldap nss + pam models, people usually want them to "just
work" rather than wanting new features provided by a port installed
OpenLDAP. That's said, the user expects he can update any port
without risking into being locked out from the system plus these
modules can be upgraded or updated with existing binary update mechanisms.

The proposed approach would not be a whole OpenLDAP import (selected
client libraries only) nor would replace the port by the way.

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOeS3vAAoJEATO+BI/yjfB7K4H/jumiosXs6OWZ02l5ntDb06k
MySle3NfvRBPIc0NL3FQUToJ2k1VzBJce53nAwXev/+YMOlbMjGcGlSuEzKSkQdE
j+Iwop+Od8/3sF4rIl7kBREMYzhZEiyT+Wf6LUxqVYqepso0PEoMlc5AoUZt1ghy
V1fdKrU7imhIM0IPgJJEi0LjK3z31CoujciuU8arnuBMbKNi5gZpJLRgB/L1s4jo
pSdNH95fCF487OsXu6sQZW0jdutaKxOsUiL1HFlwlFMzi8vCEFaG+TkwedmSeP7p
Ng4hTVTLM8JSmImVVTjF6qdQpZS8omVzt1MB4lE7gn/YwsUbLkSI+e8ejn1FP34=
=DQuu
-----END PGP SIGNATURE-----

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/20/11 14:19, Dag-Erling Smørgrav wrote:
> Xin LI <del...@delphij.net> writes:
>> The main concern I have is that users might want to stay on an
>> older FreeBSD release, while wanting features of a new OpenLDAP.
>> That's why I would prefer a libxml style import -- users always
>> have choice to install a new OpenLDAP without any concern of
>> breaking their system and we can always deliver security fixes
>> with freebsd-update. Would that make the trimmed down and
>> renamed OpenLDAP import sound sensible?
>
> Yes, you have a point. So you're saying:
>
> - client side only (for nss_ldap, pam_ldap etc) - namespace hacks
> to avoid colliding with the port
>
> right? I would definitely support that.

Yes exactly, the current version is just library to support these nss
and pam modules and have namespace hacks (so programs linking against
port OpenLDAP library will not see conflicts as well).

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOeTUGAAoJEATO+BI/yjfBRCAIAKQzG1dJhrLyKyYxJEH5qfXS
pm11L5cuQQto9yqm1TeMeT3qNMuNBo+bWt2QPJ0ef6qaOiL1oYIHdDyAkHqlDh1Z
q5zuwxZFzNAaBYF+QZLE0jSJpV05YpuN5bdkM5GilYw/xzbI4QmOstgJMyPS92WD
//oFfz9jHdQxJ0jZdp8dTDKMbgpOfUDfm/82zdDJPRnoK4dbJyn1xNFOB2H7KQyI
l246YN/W4/yR1wUDZlgjQ6zVoG4I6WvK1Lv7MU3YD2sNqfsnxoC+928U4Swd05Di
A1KXRWLsSB+2ZFnCXbGq3D22KhnmD4GQqxEZn5PZj0p2mDF3kjYDf3zlsUoofmw=
=DG1c
-----END PGP SIGNATURE-----

[Dag-Erling Smørgrav]

Kostik Belousov <kost...@gmail.com> writes:
> Yes, the question of maintanence of the OpenLDAP code in the base
> is not trivial by any means. I remember that openldap once broke
> the ABI on its stable-like branch.

That's irrelevant. Our own renamed subset of OpenLDAP would only be
used by our own code, primarily nss_ldap and pam_ldap, and would be
updated when and only when we decided that it needed updating, not every
time a new OpenLDAP release shipped. We did this successfully with
expat (libbsdxml), and there's no reason why it wouldn't work with
OpenLDAP.

> Having API renamed during the import for the actively-developed
> third-party component is probably a stopper. I am aware of the rename
> done for ssh import in ssh_namespace.h, but I do not think such
> approach scale.

The entire point of ssh_namespace.h is to minimize the amount of changes
required. Actually, when I say minimize, I mean "reduce to zero", and
the file itself is autogenerated, except for lining up the columns,
which I do manually. I don't know why you think it doesn't scale.

I don't think we have anything to gain by writing our own LDAP library.
Firstly, new code means new bugs, and this is security-critical code.
Secondly, any LDAP client library we wrote would have to have an API
that closely paralells OpenLDAP's; otherwise, we would also have to
rewrite nss_ldap and pam_ldap.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Kostik Belousov]

On Wed, Sep 21, 2011 at 11:29:49AM +0200, Dag-Erling Sm??rgrav wrote:
> Kostik Belousov <kost...@gmail.com> writes:
> > Yes, the question of maintanence of the OpenLDAP code in the base
> > is not trivial by any means. I remember that openldap once broke
> > the ABI on its stable-like branch.
>
> That's irrelevant. Our own renamed subset of OpenLDAP would only be
> used by our own code, primarily nss_ldap and pam_ldap, and would be
> updated when and only when we decided that it needed updating, not every
> time a new OpenLDAP release shipped. We did this successfully with
> expat (libbsdxml), and there's no reason why it wouldn't work with
> OpenLDAP.
>
> > Having API renamed during the import for the actively-developed
> > third-party component is probably a stopper. I am aware of the rename
> > done for ssh import in ssh_namespace.h, but I do not think such
> > approach scale.
>
> The entire point of ssh_namespace.h is to minimize the amount of changes
> required. Actually, when I say minimize, I mean "reduce to zero", and
> the file itself is autogenerated, except for lining up the columns,
> which I do manually. I don't know why you think it doesn't scale.
>
> I don't think we have anything to gain by writing our own LDAP library.
> Firstly, new code means new bugs, and this is security-critical code.
> Secondly, any LDAP client library we wrote would have to have an API
> that closely paralells OpenLDAP's; otherwise, we would also have to
> rewrite nss_ldap and pam_ldap.

I do not think that we would benefit from writing our own LDAP library
either. But I also doubt that importing ldap support in base would offer
any advantages in sum.

[Mike Tancsa]

On 9/20/2011 5:39 PM, Corey Smith wrote:

> On Tue, Sep 20, 2011 at 4:08 PM, Mike Tancsa <mi...@sentex.net> wrote:
>> Seems to die in the function policy_check in sudo.c
>

> I am able to reproduce it as well on 8.2-RELEASE amd64,
> pam_ssh_agent_auth-0.9.3 and sudo-1.8.2.
>

I posted the question on the sudo list and there seems to be a work
around posted there!

http://www.sudo.ws/pipermail/sudo-users/2011-September/004831.html

[Brooks Davis]

This is certainly the largest benefit. I used a variant of pam_ldap for
authentication at $WORK for many years and the instability of the
OpenLDAP API was a constant headache.

That isn't to say that importing it into base is the only possible
solution. It is likely the most straightforward.

-- Brooks

[Jason Hellenthal]

Base package system that comes pre-installed ? or just ships with the
discs ?

> -- Brooks

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Well first and most important, someone will need to implement that,
but to be more specific there are a lot of issues that needs to be
solved like:

- How to update your system? LPK patchset for instance needs to be a
part of OpenSSH (not a loadable module) so we end up with a modified
sshd binary. "make installworld" need to know and don't patch it;
- How to patch your system? A mechanism like freebsd-update needs to
be implemented for these essential security services;
- How to update these "base packages"? There need to be a way that
is no harder than 'make installworld' in my opinion.

That's said, all these are not impossible without direct base system
integration, but integration is the most straightforward way at this
moment.

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOeiCgAAoJEATO+BI/yjfB0gUH/2Sv52kW8GEACIisgkA+qfcS
eVjViqR5f4JE8JmSEnblHX5RWw96MEi9rsdgHiHFAmBed4CxG/SLr4Xjc5Ozv9EV
0zwThyAan5V0AuJjvAd9/pO/FkilzlQG4N2+wrzjB46FdH8YpBLcV57eSKUVpHO1
SA2t27qTC5Mo6ysQUutwQV00ujEtXL1KtsXl6iJLPKuKe9wdeJNBXQ3lkeCOsG/H
nBCPsAbb17H+RseSePCXTox4za5hLHCD2wsaqtydD08WO1bUf4hhYkQoy0IZ+q4z
DteS4qtDYzpoP5sbX/iY5vkXGHglOWpZzWcsfuHR5ZgIaXeEuk47UDHf0H632BE=
=BuI/
-----END PGP SIGNATURE-----

[Gleb Kurtsou]

On (20/09/2011 17:51), Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 09/20/11 14:19, Dag-Erling Smørgrav wrote:
> > Xin LI <del...@delphij.net> writes:
> >> The main concern I have is that users might want to stay on an
> >> older FreeBSD release, while wanting features of a new OpenLDAP.
> >> That's why I would prefer a libxml style import -- users always
> >> have choice to install a new OpenLDAP without any concern of
> >> breaking their system and we can always deliver security fixes
> >> with freebsd-update. Would that make the trimmed down and
> >> renamed OpenLDAP import sound sensible?
> >
> > Yes, you have a point. So you're saying:
> >
> > - client side only (for nss_ldap, pam_ldap etc) - namespace hacks
> > to avoid colliding with the port
> >
> > right? I would definitely support that.
>
> Yes exactly, the current version is just library to support these nss
> and pam modules and have namespace hacks (so programs linking against
> port OpenLDAP library will not see conflicts as well).

It wasn't explicitly mentioned, but instead of adding ssh-namespace.h
like hacks we could add local symbol versions to ldap shared libraries.
That would make impact on OpenLDAP from ports and its users minimal.
Binary could be linked against both OpenLDAP and ldap from base in case
when libbsdldap.so is indirect dependency used by another library from
base. That is not the case with libbsdxml.so

Thanks,
Gleb.

[Doug Barton]

On 09/16/2011 08:05, Dag-Erling Smørgrav wrote:
> We currently have a number of PAM modules in ports, and while some of
> them are specific to certain third-party software, many aren't. I
> believe we would benefit from importing at least some of these into

> base. My question is: which ones?

For the sake of having the opposing viewpoint represented, I'm opposed
to importing more of this stuff into the base. Given that it works just
fine as it is, the benefits of importing it would have to overwhelmingly
compensate for the negatives of having to keep them up to date in the base.

Taking ldap as an example, the subset of our users who need this
functionality are already able to get it from the ports tree, where it
is easier to keep up to date across multiple FreeBSD versions.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

[Benjamin Kaduk]

On Tue, 20 Sep 2011, Xin LI wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 09/20/11 15:51, Kostik Belousov wrote:
> [...]
>> Yes, the question of maintanence of the OpenLDAP code in the base
>> is not trivial by any means. I remember that openldap once broke
>> the ABI on its stable-like branch.
>
> That happen a few times however these are either not essential client
> library (libldap and liblber) API or it's not changing parameters or
> removing interfaces. Moreover, like the base libbsdxml.so, it's only
> intended to be used by base system only so it's relatively easier to
> maintain ABI stability, e.g. we can probably just expose only symbols
> that we use, etc.

This is not without its own failures. For example, I sometimes find
myself wanting a kgetcred(1) from heimdal, but we do not build it as part
of our base heimdal. As a separate utility, this is not so bad; for a
library, things can get much more annoying.
Only exposing a limited set of symbols can make third-party tools that
want extra symbols very sad, unless it is easy to drop in a full version
from ports and still have all of base "just work". I do not quite think
that the current state of ports for ldap would "just work" without some
extra configuration (though, nor have I tried something like it).

-Ben Kaduk

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/22/11 19:19, Benjamin Kaduk wrote:
> On Tue, 20 Sep 2011, Xin LI wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> On 09/20/11 15:51, Kostik Belousov wrote: [...]
>>> Yes, the question of maintanence of the OpenLDAP code in the
>>> base is not trivial by any means. I remember that openldap once
>>> broke the ABI on its stable-like branch.
>>
>> That happen a few times however these are either not essential
>> client library (libldap and liblber) API or it's not changing
>> parameters or removing interfaces. Moreover, like the base
>> libbsdxml.so, it's only intended to be used by base system only
>> so it's relatively easier to maintain ABI stability, e.g. we can
>> probably just expose only symbols that we use, etc.
>
> This is not without its own failures. For example, I sometimes
> find myself wanting a kgetcred(1) from heimdal, but we do not build
> it as part of our base heimdal. As a separate utility, this is not
> so bad; for a library, things can get much more annoying. Only
> exposing a limited set of symbols can make third-party tools that
> want extra symbols very sad, unless it is easy to drop in a full
> version from ports and still have all of base "just work". I do
> not quite think that the current state of ports for ldap would
> "just work" without some extra configuration (though, nor have I
> tried something like it).

Third party utilities should use symbols provided by port OpenLDAP
library because base system symbols are namespaced and third party
application have no chance to reference them (e.g. no header
installed, etc) unless they are part of base system and be built with it.

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOfFpHAAoJEATO+BI/yjfBjxwH/iKLFZkvzkowW50FyuxnesmQ
r4f9bvOLAH8iRva8GJEJDJaTqQHKWVJ8yIkT49WC8VgoNAcpkvzkOXm2Xe658yuz
Ca5TNIFvJccw6MtH6nicE4REy+YEOwcnSQTLHqcPBKiSLH3RFrklOZ3YjGrR8qgX
9WmVI6rZ9CbHwUVsWyJUOUYrCsAPsLpraqyfhwM1/ZXnr3mGNKayb8KMjgmy0gGI
V2J9bIjPd2E6vDLl8vYJxQZ+pPrUcuPJ06v+SFN9vmbC7UadRWZr37DsX1Kba4pN
3qRKemze61qMPi39Xd8Wt7Og6+GAIKnMV2cX2+a+3gExO0haMl4E/V9BU6UpVUA=
=t3Ti
-----END PGP SIGNATURE-----

[Ryan Steinmetz]

On (09/17/11 14:30), Hartmann, O. wrote:
> On 09/16/11 23:36, Mike Carlson wrote:

> > On 09/16/2011 08:05 AM, Dag-Erling Sm??rgrav wrote:
> >> We currently have a number of PAM modules in ports, and while some of
> >> them are specific to certain third-party software, many aren't. I
> >> believe we would benefit from importing at least some of these into
> >> base. My question is: which ones?
> >>

> >> DES
> > LDAP support out of the box would be fantastic.
> >
> > Mike C

> > _______________________________________________
> > freebsd-...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-security
> > To unsubscribe, send any mail to
> > "freebsd-securi...@freebsd.org"
>

> Also a strong vote for LDAP support. LDAP is our backend for several
> server systems and it is a kind of pain
> having to think first for the ports to be installed. Also I suspect and
> hope a better integration if LDAP gets
> part of the core system.
>
> Regards,
> Oliver

> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

I think some caution should be used whenever we discuss merging things
into the base system. There may be other ways of achieving the same
functionality, without the challenges that come with merging things
directly into the base system. Ports tend to be easier to update (in
terms of version bumps/features additions) when compared to things that
become part of base.

I think an interesting concept would be something that gave us the
ability to (easily) tie certain ports into software from the base system.
Something that would allow the software to be more easily kept current.
Perhaps this could be done via some sort of base-integrated ports
category that require extra-special care/controls when being updated.

Using the above idea, perhaps we could have ISOs or the like available
that include these 'base-integrated' ports pre-installed, thus giving
users the ability to (effectively) have an out-of-the-box solution that
included LDAP support, etc., while still having these 'base-integrated'
ports loosely coupled with the base OS. The concept could keep the base
system lean, but provide the flexibility that users desire.

Obviously there are some complexities associated with implementing the
framework and details that would need to be worked out, but this could
address:
-The desire to keep the base system lean
-The desire to provide certain features out-of-the-box
-The ability to keep these 'base-integrated' ports more current in terms
of features/functionality

-r


--
Ryan Steinmetz
PGP: EF36 D45A 5CA9 28B1 A550 18CD A43C D111 7AD7 FAF2

[Benjamin Kaduk]

On Sat, 24 Sep 2011, Ryan Steinmetz wrote:

>
> I think an interesting concept would be something that gave us the
> ability to (easily) tie certain ports into software from the base system.
> Something that would allow the software to be more easily kept current.
> Perhaps this could be done via some sort of base-integrated ports
> category that require extra-special care/controls when being updated.

I would very much love a way to tie certain ports into the base system, by
which I mean have the base system utilities link against libraries
provided by a port. (My particular example at hand would be to link ssh
and friends against MIT kerberos from ports, but there are a goodly number
of other examples.) Yet, in order for the benefits of ports to work,
there would need to be a way to hook into the base system to get these
utilities updated with port updates, and probably a way to disable the
base system version of the libraries but still have utilities link against
them (from ports).
I do not think this is possible without a great deal of build
infrastructure work; certainly just a special category of port is
insufficient, as it sould still have the update problem.
Though perhaps my vision is not exactly what you are aiming for ...

>
> Using the above idea, perhaps we could have ISOs or the like available
> that include these 'base-integrated' ports pre-installed, thus giving
> users the ability to (effectively) have an out-of-the-box solution that
> included LDAP support, etc., while still having these 'base-integrated'
> ports loosely coupled with the base OS. The concept could keep the base
> system lean, but provide the flexibility that users desire.

People seem to have concerns about the ability of (some) mirrors to cope
with huge piles of data, particularly in the context of regularly updated
package sets from ports. Those concerns would seem to apply to this as
well, as it would apply a scaling factor to the number of isos involved.
Now, having an extra option in the installer "Do you want to install the
LDAP package? (y/n)" is another matter, and potentially doable. (Though
given that perl was pulled *out* of this near-base status in the fairly
recent past does give one pause ...)

>
> Obviously there are some complexities associated with implementing the
> framework and details that would need to be worked out, but this could
> address:
> -The desire to keep the base system lean
> -The desire to provide certain features out-of-the-box
> -The ability to keep these 'base-integrated' ports more current in terms
> of features/functionality

My main concern is with respect to the third point, in making sure that
there do not creep in interdependencies that make updating the port
components complicated or fragile.

-Ben Kaduk