Re: Incompatable crypt? (ITS#970)

[Kurt@OpenLDAP.org]

At 02:48 AM 1/19/01 +0000, brad@mrunix.net wrote:
>Unfortunately it turns out to be a bit more complicated than that.. the
>ufc-crypt library that is included with glibc on Slack-7.1 refuses to
>generate hashed passwords if you use a 2 character salt, and if you do,
>it just returns back a NULL.

What if you provide 8 characters of salt?  I made a change
to lutil/passwd.c based upon FreeBSD's passwd(1) code.  Haven't
a clue whether it will have any impact on other systems, just
curious.

>To solve it, a quick hack was made to the passwd.c file in the
>liblutil library, making it use the MD5 salt (actually, I've got
>it inside a #ifdef/endif pair), and putting -lcrypt in front of the
>-lcrypto declaration in config.status (just so I didn't have to hack
>the SSL code for now). 

Note that moving -lcrypt forward will not only mask the crypt(3)
routine found in OpenSSL, but any other routine contained in
both -lcrypt and OpenSSL libraries.  In particular, one must
be very careful in regards to various hash functions.

I also note you must be careful when using Kerberos and Cyrus
SASL as they provide various routines as well.

I use a version of Heimdal Kerberos hacked to use OpenSSL
instead of its own routines.  You can also build Cyrus SASL
to use OpenSSL.

Note that OpenLDAP uses MD5/SHA1 directly as well but provides
its own version of hash routines using symbols which shouldn't
clash.

>All is well with the world again and it now uses
>the same crypt function that the OS uses.  When I get some free time,
>I'll do a real test/fix for the UFC stuff and send in a diff.

That would be fine.  I'd suggest the fix not reorder libraries
(but rely on patches to OpenSSL... which should be submitted
to OpenSSL).