[Date Prev][Date Next] [Chronological] [Thread] [Top]


"Kurt D. Zeilenga" wrote:
> At 12:32 PM 3/14/00 +0100, Lars Uffmann wrote:
> >Would you mind to backport BINDDN to 1.2.X ?
> We trying hard to limit changes to 1.2 to bug fixes only.
> I suggest submitting an ITS with your patch so that others
> may benefit from your efforts.

I do not have the feeling that 2.0 is comming soon. And I hate it to
maintain private patches to third party software, specially when there
are frequent releases (as with OpenLDAP) which might fix serious bugs. 
IMHO you schould allow minor improovments to be incooperated into 1.2.

> >
> >In the meantime, if the IETF LDAP C API draft says 'discouraged', could
> >the BINDPW feature be implemented inside the ldap client tools only?
> Well, as I noted above, a similiar security consideration should be
> placed upon applications.
> >I would prefer using the environment only (LDAPBINDPW), so I could allways
> >override with -w or -W.
> You do realize that the environment of applications is world
> readable on many operating systems?

In my patch, LDAPBINDPW's value is the name of a file containing the password.
The file is read only if certain conditions apply (not world or group readable, etc)
In fact, I made the effort of writing the patch to get the password out of the
scripts ARGV. Why schould I place it into it's ENVP?

> Also, note, that we'll likely start prompting for "secrets"
> as the default.  In a SASL world, the application shouldn't
> handle "secrets".  It should just provide a mechanism to
> allow the user to interact (ie: prompting or other) with the
> underlying authentication services.

My primary concern are automated tasks like cronjobs using the ldap
command line tools, ie ldapsearch, ldapadd, ldapmodify and friends.

Lars Uffmann, <lars.uffmann@mediaways.net>, fon: +49 5241 80 40330