Arch Linux

Please read this before reporting a bug:

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
Task Type Feature Request
Category Packages: Testing
Status Assigned
Assigned To David Runge (dvzrv)
Levente Polyak (anthraxx)
Giancarlo Razzolini (grazzolini)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 5
Private No


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 to, 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

Comment by Tobias Powalowski (tpowa) - Wednesday, 12 August 2020, 19:40 GMT
pambase-20200721.1-2 should fix this, shadow is pending.
Comment by Giancarlo Razzolini (grazzolini) - Monday, 14 September 2020, 19:14 GMT
Will make the suggested changes to shadow later this week
Comment by Geert Hendrickx (ghen) - Thursday, 10 December 2020, 10:04 GMT
The direct pam config allows more choices than ENCRYPT_METHOD in /etc/login.defs though, which can only be set to DES, MD5, SHA256, SHA512 or (undocumented) BCRYPT.
pam_unix(8) supports more algorithms, like yescrypt.
Comment by Geert Hendrickx (ghen) - Thursday, 10 December 2020, 19:17 GMT
Btw, upstream is planning to handle this differently in the future, and rely on libxcrypt's crypt_preferred_method() instead of a (potentially dated) system preference:
Comment by loqs (loqs) - Saturday, 05 June 2021, 22:19 GMT
The pambase-20200721.1-2 change was reverted by pambase 20210605-1: hash with sha512 by default.

Should this be closed as Won't Fix?
Comment by Geert Hendrickx (ghen) - Sunday, 06 June 2021, 19:47 GMT
The crypt(5) manpage lists sha512crypt as "acceptable" (if properly configured, not by default), but recommends yescrypt for new hashes.
Comment by loqs (loqs) - Sunday, 06 June 2021, 21:00 GMT
@ghen you want to submit a patch changing all use of sha512 in pam files to yescrypt, adding it to pam_unix password entries that do not specify an encryption method and removing it from /etc/login.defs?
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.
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?

Comment by David Runge (dvzrv) - Sunday, 16 October 2022, 16:23 GMT
I've added the options to build with bcrypt and yescrypt support in SVN (
Comment by David Runge (dvzrv) - Thursday, 20 October 2022, 08:43 GMT
FWIW, it appears that Fedora builds shadow without libpam support (
I wonder why that is and how they configure PAM instead.
Comment by lukpod (lukpod) - Friday, 28 October 2022, 12:47 GMT Comment by loqs (loqs) - Monday, 31 October 2022, 23:20 GMT
With pam, uses ENCRYPT_METHOD from longin.defs [1] overridden by des md5 bigcrypt sha256 sha512 blowfish gost_yescrypt yescrypt [2] and SHA_CRYPT_MAX_ROUNDS [3] overridden by rounds=n. The rest of the pam stack is used.

Without pam ENCRYPT_METHOD supported values des md5 sha256 sha512 bcrypt yescrypt, SHA_CRYPT_MIN_ROUNDS SHA_CRYPT_MAX_ROUNDS BCRYPT_MIN_ROUNDS BCRYPT_MAX_ROUNDS YESCRYPT_COST_FACTOR [4] may be used.

des md5 sha256 sha512 bcrypt yescrypt intersection with des md5 bigcrypt sha256 sha512 blowfish gost_yescrypt yescrypt is des md5 sha256 sha512 yescrypt eliminating des and md5 leaves sha256 sha612 yescrypt.
scrypt bcrypt sha1crypt SunMD5 bsdicrypt NT are supported by libxcrypt [5] but not by pam_unix [2].

[6] Changes the ENCRYPT_METHOD documentation in login.defs to list the methods supported by pam_unix and removes the per method rounds settings.
[7] and [8] Adds a ROUNDS option to login.defs and changes pam_unix's undocumented support for SHA_CRYPT_MAX_ROUNDS to support it mirroring the rounds option pam_unix already supports.

pam_unix min 1000 max 9999999 default 5000

pam_unix min 3 max 11 default 5

How does Fedora avoid a different number of rounds and or encryption method being used between tools that use pam such login when a password change is forced due to it being expired compared to passwd which Fedora builds without pam?

[6] shadow-encrypt-methods-supported-by-pam-unix.patch
[7] shadow-rounds.patch
[8] pam-rounds.patch