Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#67393 - [shadow][pambase] Stop overriding the specified ENCRYPT_METHOD in /etc/login.defs
Attached to Project:
Arch Linux
Opened by loqs (loqs) - Saturday, 25 July 2020, 17:25 GMT
Last edited by David Runge (dvzrv) - Wednesday, 18 November 2020, 09:47 GMT
Opened by loqs (loqs) - Saturday, 25 July 2020, 17:25 GMT
Last edited by David Runge (dvzrv) - Wednesday, 18 November 2020, 09:47 GMT
|
DetailsDescription:
The method is currently overridden in all its uses meaning the actual value specified in /etc/login.defs has no effect. This could cause confusion. Also synchronizing a setting in multiple locations can introduce errors. It is used in at least: * /etc/pam.d/chpasswd * /etc/pam.d/newusers * /etc/pam.d/passwd * /etc/pam.d/system-auth PKGBUILD.diff.shadow removed all uses of sha512. Changed dropped module pam_cracklib.so to pam_pwquality.so, man page lists parameters as being the same but I have not checked this. PKGBUILD.diff.pambase removed use of sha512. Additional info: * shadow 4.8.1-3 * pambase 20190105.1-2 |
This task depends upon
pam_unix(8) supports more algorithms, like yescrypt.
https://github.com/linux-pam/linux-pam/pull/84
Should this be closed as Won't Fix?
You could also standardize the use of nullok. You could also consider changing physlock and kbd to using upstreams pam configs that use system-auth rather directly using pam_unix.
Edit:
man 5 crypt notes 5000 rounds is too low for modern hardware for sha512/sha256 but does not provide a recommended number of rounds.
Does the libxcrypt project have a recommendation for the number of rounds that currently could be used? That could then be set in upstream shadows login.defs.
Or patch shadow with yescrypt support [1] and add the option there?
[1] https://github.com/shadow-maint/shadow/commit/5cd04d03f94622c12220d4a6352824af081b8531