Re: Incompatable crypt? (ITS#970)

[brad@mrunix.net]

On Thu, 18 Jan 2001, Kurt D. Zeilenga wrote:

> Multiple libraries provide a crypt(3) implementation including
> OpenSSL and your system libraries.  The best way to avoid this
> problem is to hack OpenSSL not to provide a crypt(3).  If your
> system supplies crypt(3) in -lcrypt or -lutil, you might try
> reordering of the libraries (by editing config.status and
> then runnng it to generate new make files).  However, if
> crypt(3) is in -lc, adding an explicit -lc early in the
> library set is NOT recommended.
>
> Personally, I recommend hacking OpenSSL.

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.  So if you turn off crypt(3) in OpenSSL
and fall back to the one in libcrypt (which cyrus-sasl uses also),
slapd and slappasswd both break..  You _must_ use the MD5 type salt
of "$1$xxxxxxxx" in order to generate valid hashes.

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).  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.

Thanks to everyone who pointed me in the right direction..

--
Bradford L. Barrett                      brad@mrunix.net
A free electron in a sea of neutrons     DoD#1750 KD4NAW

Any GUI that doesn't allow full customization - or does not
allow you to make it operate and look like any other GUI...
should be considerd broken. Jim Gettys, X-windows co-author