[Date Prev][Date Next]
Re: Incompatable crypt? (ITS#970)
At 02:48 AM 1/19/01 +0000, email@example.com 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
>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
>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