Re: Marginally related thought on glibc's crypt problem
Galen Hazelwood:
> Yes, I'm afraid I have to confirm that the crypt stuff is unexportable
> from the US. The standard unix crypt function uses DES, and DES is
> a munition in the eyes of the government. So, technically, the libc
> package just about every linux distribution uses is unexportable.
Yeah, and just about every other unix system ever made is unexportable
too... But crypt() is used for authentication only, not encryption.
> The reason I ask is that the pam_unix_foo modules don't use crypt.
> They have their own replacement built on MD5, which _is_ exportable.
Actually, this replacement crypt() could simply be made part of libc
- or a separate small shared library that can easily be replaced.
So we can do that even now, without PAM.
> I saw something similar in the glibc source tree when I was looking
> at it, under glibc-1.99/crypt.
Yes, if you build it without the des-crypt plugin, it will include
the MD5-only crypt(). Only problem is that it is incompatible with
existing password files, so you can't share them with other systems,
except those few that support the MD5 crypt too, such as FreeBSD.
The MD5 crypt() code in FreeBSD is totally free (not GPLed), so there
is some hope that unix vendors will start using it, thus making it
a real standard - but it might take another few years. Exportability
is not the only advantage, it also supports passwords of any length.
Wouldn't it be better to start looking for a non-US site to move the
whole distribution there? No munitions export restrictions, no US
software patents...
Marek
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: