| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with glibc 2.17 (eglibc 2.17), crypt() fails with
EINVAL (w/ NULL return) if the salt violates specifications.
Additionally, on FIPS-140 enabled Linux systems, DES or MD5
encrypted passwords passed to crypt() fail with EPERM (w/
NULL return).
Slackware-current has transitioned to glibc 2.17 and as you
might be aware from reading my posts on LQ, I have dedicated
time to fixing userland which does not adequately handle
crypt() returns given the new behavior.
gdm is negatively affected and my attached patch (against
gdm 2.20.11) addresses this.
This is in anticipation of a new Slackware release but can
be applied to the SBo package for Slackware 14.0 since it is
backwards compatible and should not affect behavior on glibc
2.15. It would be good if my assertion were tested.
[rworkman] Yeah, it seems to work here :-)
Signed-off-by: Robby Workman <rworkman@slackbuilds.org>
|
