etc/, lib/, man/, src/, tests/: Remove support for MD5 #1457
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is necessary for later changing the fallback from the insecure DES to something secure such as SHA512. Link: <shadow-maint#1278> Cc: Andre Boscatto <andreboscatto@gmail.com> Cc: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Fix style. Signed-off-by: Alejandro Colomar <alx@kernel.org>
DES is insecure; use it only if explicitly requested. Closes: <shadow-maint#1278> Reported-by: Andre Boscatto <andreboscatto@gmail.com> Cc: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
It has been deprecated for a very long time. In fact, the first commit that documented MD5_CRYPT_ENAB already documented it as deprecated. 6e3ad7a (2007-11-20). Signed-off-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
This was the command-line equivalent of MD5_CRYPT_ENAB. It deserves the same fate. Signed-off-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
In the last commit, PASS_MAX_LEN became unused. As a consequence, obscure_get_range()'s $2 is unconditionally set to -1. Remove all code that depends on this value. Signed-off-by: Alejandro Colomar <alx@kernel.org>
Transform obscure_get_range() into a simpler function that returns just the minimum password lenght, and propagate the simplification at call site. Signed-off-by: Alejandro Colomar <alx@kernel.org>
It was being ignored, as DES was the only algorithm that used it, and we removed DES support. Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
changed the title
27 corresponds to the minimum MD5 hash length. Signed-off-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
48 corresponds to the minimum SHA256 hash length. Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
force-pushed
the
nomd5
branch
from
71945a5 to
063be14
Compare
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 29, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. - Some user names and group names are too dangerous and are rejected, even with --badname. Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - Password aging The ability to periodically expire passwords is detrimental to safety, and will be removed eventually. See also: <shadow-maint#1432> <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact Because removing all of these suddently would be too disruptive (mainly, because of contracts in regulated environments, with contracts that enforce outdated policies), we'll continue providing most of these features for a relatively long time. However, you should consider not using them, and if it doesn't depend on you, you should consider contacting whoever is responsible for it. We'll eventually and gradually remove them. Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 29, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. - Some user names and group names are too dangerous and are rejected, even with --badname. Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - Password aging Security research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible. <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See <shadow-maint#1432>. This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact We recognize that many users operate in environments with regulatory or contractual requirements that still mandate password aging. To minimize disruption, these features will remain functional for a significant period. However, we encourage administrators to review their internal policies, talk to their regulators if appropriate, and participate in the roadmap discussion linked above. Co-authored-by: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 29, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. b0a7ce5 (2025-12-05; "lib/, po/: Remove fgetsx() and fputsx()") - Some user names and group names are too dangerous and are rejected, even with --badname. 25aea74 (2025-12-25; "lib/chkname.c, src/: Strictly disallow really bad names") Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - Password aging Security research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible. <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See <shadow-maint#1432>. This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact We recognize that many users operate in environments with regulatory or contractual requirements that still mandate password aging. To minimize disruption, these features will remain functional for a significant period. However, we encourage administrators to review their internal policies, talk to their regulators if appropriate, and participate in the roadmap discussion linked above. Co-authored-by: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 29, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. b0a7ce5 (2025-12-05; "lib/, po/: Remove fgetsx() and fputsx()") - Some user names and group names are too dangerous and are rejected, even with --badname. 25aea74 (2025-12-25; "lib/chkname.c, src/: Strictly disallow really bad names") Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - login.defs(5): PASS_MAX_LEN This feature is ignored except for DES. Once DES is removed, it makes no sense keeping it. It may be removed in a future release. - Password aging Security research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible. <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See <shadow-maint#1432>. This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact We recognize that many users operate in environments with regulatory or contractual requirements that still mandate password aging. To minimize disruption, these features will remain functional for a significant period. However, we encourage administrators to review their internal policies, talk to their regulators if appropriate, and participate in the roadmap discussion linked above. Co-authored-by: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 29, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. b0a7ce5 (2025-12-05; "lib/, po/: Remove fgetsx() and fputsx()") - Some user names and group names are too dangerous and are rejected, even with --badname. 25aea74 (2025-12-25; "lib/chkname.c, src/: Strictly disallow really bad names") Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - login.defs(5): PASS_MAX_LEN This feature is ignored except for DES. Once DES is removed, it makes no sense keeping it. It may be removed in a future release. - Password aging Scientific research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible. <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See <shadow-maint#1432>. This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact We recognize that many users operate in environments with regulatory or contractual requirements that still mandate password aging. To minimize disruption, these features will remain functional for a significant period. However, we encourage administrators to review their internal policies, talk to their regulators if appropriate, and participate in the roadmap discussion linked above. Co-authored-by: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 29, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. b0a7ce5 (2025-12-05; "lib/, po/: Remove fgetsx() and fputsx()") - Some user names and group names are too dangerous and are rejected, even with --badname. 25aea74 (2025-12-25; "lib/chkname.c, src/: Strictly disallow really bad names") Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - login.defs(5): PASS_MAX_LEN This feature is ignored except for DES. Once DES is removed, it makes no sense keeping it. It may be removed in a future release. - Password aging Scientific research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible. <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See <shadow-maint#1432>. This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact We recognize that many users operate in environments with regulatory or contractual requirements that still mandate password aging. To minimize disruption, these features will remain functional for a significant period. However, we encourage administrators to review their internal policies, talk to their regulators if appropriate, and participate in the roadmap discussion linked above. Co-authored-by: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 29, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. b0a7ce5 (2025-12-05; "lib/, po/: Remove fgetsx() and fputsx()") - Some user names and group names are too dangerous and are rejected, even with --badname. 25aea74 (2025-12-25; "lib/chkname.c, src/: Strictly disallow really bad names") Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - login.defs(5): PASS_MAX_LEN This feature is ignored except for DES. Once DES is removed, it makes no sense keeping it. It may be removed in a future release. - Password aging Scientific research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible. <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See <shadow-maint#1432>. This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact We recognize that many users operate in environments with regulatory or contractual requirements that still mandate password aging. To minimize disruption, these features will remain functional for a significant period. However, we encourage administrators to review their internal policies, talk to their regulators if appropriate, and participate in the roadmap discussion linked above. Co-authored-by: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 30, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. b0a7ce5 (2025-12-05; "lib/, po/: Remove fgetsx() and fputsx()") - Some user names and group names are too dangerous and are rejected, even with --badname. 25aea74 (2025-12-25; "lib/chkname.c, src/: Strictly disallow really bad names") Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - login.defs(5): PASS_MAX_LEN This feature is ignored except for DES. Once DES is removed, it makes no sense keeping it. It may be removed in a future release. - Password aging Scientific research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible. <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See <shadow-maint#1432>. This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact We recognize that many users operate in environments with regulatory or contractual requirements that still mandate password aging. To minimize disruption, these features will remain functional for a significant period. However, we encourage administrators to review their internal policies, talk to their regulators if appropriate, and participate in the roadmap discussion linked above. Co-authored-by: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 30, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. b0a7ce5 (2025-12-05; "lib/, po/: Remove fgetsx() and fputsx()") - Some user names and group names are too dangerous and are rejected, even with --badname. 25aea74 (2025-12-25; "lib/chkname.c, src/: Strictly disallow really bad names") Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - login.defs(5): PASS_MAX_LEN This feature is ignored except for DES. Once DES is removed, it makes no sense keeping it. It may be removed in a future release. - Password aging Scientific research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible. <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See <shadow-maint#1432>. This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact We recognize that many users operate in environments with regulatory or contractual requirements that still mandate password aging. To minimize disruption, these features will remain functional for a significant period. However, we encourage administrators to review their internal policies, talk to their regulators if appropriate, and participate in the roadmap discussion linked above. Co-authored-by: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 30, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. b0a7ce5 (2025-12-05; "lib/, po/: Remove fgetsx() and fputsx()") - Some user names and group names are too dangerous and are rejected, even with --badname. 25aea74 (2025-12-25; "lib/chkname.c, src/: Strictly disallow really bad names") Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Support: - Several years ago, there were talks about deprecating su(1) and login(1), back when this project was maintained as part of Debian. However, nothing was clearly stated, and there was doubt about the status of these programs. Let's clarify them now. Our implementations pf su(1) and login(1) are fully supported, and we don't have any plans to remove them. They are NOT deprecated. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - login.defs(5): PASS_MAX_LEN This feature is ignored except for DES. Once DES is removed, it makes no sense keeping it. It may be removed in a future release. - Password aging Scientific research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible. <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See <shadow-maint#1432>. This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact We recognize that many users operate in environments with regulatory or contractual requirements that still mandate password aging. To minimize disruption, these features will remain functional for a significant period. However, we encourage administrators to review their internal policies, talk to their regulators if appropriate, and participate in the roadmap discussion linked above. Co-authored-by: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 30, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. b0a7ce5 (2025-12-05; "lib/, po/: Remove fgetsx() and fputsx()") - Some user names and group names are too dangerous and are rejected, even with --badname. 25aea74 (2025-12-25; "lib/chkname.c, src/: Strictly disallow really bad names") Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Support: - Several years ago, there were talks about deprecating su(1) and login(1), back when this project was maintained as part of Debian. However, nothing was clearly stated, and there was doubt about the status of these programs. Let's clarify them now. Our implementations pf su(1) and login(1) are fully supported, and we don't have any plans to remove them. They are NOT deprecated. See <shadow-maint#464>. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - login.defs(5): PASS_MAX_LEN This feature is ignored except for DES. Once DES is removed, it makes no sense keeping it. It may be removed in a future release. - Password aging Scientific research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible. <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See <shadow-maint#1432>. This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact We recognize that many users operate in environments with regulatory or contractual requirements that still mandate password aging. To minimize disruption, these features will remain functional for a significant period. However, we encourage administrators to review their internal policies, talk to their regulators if appropriate, and participate in the roadmap discussion linked above. Co-authored-by: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 30, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. b0a7ce5 (2025-12-05; "lib/, po/: Remove fgetsx() and fputsx()") - Some user names and group names are too dangerous and are rejected, even with --badname. 25aea74 (2025-12-25; "lib/chkname.c, src/: Strictly disallow really bad names") Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Support: - Several years ago, there were talks about deprecating su(1) and login(1), back when this project was maintained as part of Debian. However, nothing was clearly stated, and there were doubts about the status of these programs. Let's clarify them now. Our implementations of su(1) and login(1) are fully supported, and we don't have any plans to remove them. They are NOT deprecated. See <shadow-maint#464>. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - login.defs(5): PASS_MAX_LEN This feature is ignored except for DES. Once DES is removed, it makes no sense keeping it. It may be removed in a future release. - Password aging Scientific research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible. <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See <shadow-maint#1432>. This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact We recognize that many users operate in environments with regulatory or contractual requirements that still mandate password aging. To minimize disruption, these features will remain functional for a significant period. However, we encourage administrators to review their internal policies, talk to their regulators if appropriate, and participate in the roadmap discussion linked above. Co-authored-by: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
added a commit
to alejandro-colomar/shadow
that referenced
this pull request
Dec 30, 2025
Breaking changes: - Remove support for escaped newlines in configuration files. It never worked correctly. b0a7ce5 (2025-12-05; "lib/, po/: Remove fgetsx() and fputsx()") - Some user names and group names are too dangerous and are rejected, even with --badname. 25aea74 (2025-12-25; "lib/chkname.c, src/: Strictly disallow really bad names") Future breaking changes: - SHA512 and SHA256 will be supported unconditionally in the next release. The build-time flag '--with-sha-crypt' will be removed. See <shadow-maint#1452>. Support: - Several years ago, there were talks about deprecating su(1) and login(1), back when this project was maintained as part of Debian. However, nothing was clearly stated, and there were doubts about the status of these programs. Let's clarify them now. Our implementations of su(1) and login(1) are fully supported, and we don't have any plans to remove them. They are NOT deprecated. See <shadow-maint#464>. Deprecations: - groupmems(8) The program will be removed in a future release. See <shadow-maint#1343>. - logoutd(8) The program will be removed in the next release. See <shadow-maint#999>, and <shadow-maint#1344>. - DES This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1456> - MD5 This hashing algorithm has been deprecated for a long time, and support for it will be removed in a future release. See <shadow-maint#1457> - login.defs(5): MD_CRYPT_ENAB This feature had been deprecated for decades. It will be removed in a future release. The command-line equivalents (-m, --md5) of this feature in chpasswd(8) and chgpasswd(8) will also be removed in a future release. See <shadow-maint#1455>. - login.defs(5): PASS_MAX_LEN This feature is ignored except for DES. Once DES is removed, it makes no sense keeping it. It may be removed in a future release. - Password aging Scientific research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible. <https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf> Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver> <https://pages.nist.gov/800-63-FAQ/#q-b05> <https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See <shadow-maint#1432>. This deprecation includes the following programs and features: expiry(1) chage(1): -I,--inactive (also the interactive version) -m,--mindays (also the interactive version) -M,--maxdays (also the interactive version) -W,--warndays (also the interactive version) passwd(1): -k,--keep-tokens -n,--mindays -x,--maxdays -i,--inactive -w,--warndays useradd(8): -f,--inactive usermod(8): -f,--inactive login.defs(5): PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE /etc/default/useradd: INACTIVE shadow(5): sp_lstchg: Restrict to just the values 0 and empty. sp_min sp_max sp_warn sp_inact We recognize that many users operate in environments with regulatory or contractual requirements that still mandate password aging. To minimize disruption, these features will remain functional for a significant period. However, we encourage administrators to review their internal policies, talk to their regulators if appropriate, and participate in the roadmap discussion linked above. Co-authored-by: Iker Pedrosa <ipedrosa@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Contributor
|
Does this affect validation of existing MD5 hashes? (in login for example) I assume this would only prevent new MD5 hashes from being generated, but I want to double-check. |
Collaborator
Author
As far as I can see, yes. It is up to crypt(3) to decide whether MD5 is accepted for verifying existing hashes; we have no say in it. This logic is in Do you want to preserve the ability to verify MD5 passwords, or is it just curiosity? |
Contributor
Yeah, that's what I figured.
I think it would be good maintain compatibility when there's very little maintenance cost. If we break existing passwords that might require some communication with end users to warn them. |
Collaborator
Author
I think we should still communicate with end users to warn them. And they should consider moving away from MD5, as it might eventually stop working. |
Contributor
I suspect most users have already migrated away from a settings perspective. However, I believe this is only effective if all users change their password after the hash setting has been changed. A more robust approach would be to rehash the password on successful login when the existing hash is using an obsolete method like MD5. I don't think shadow or PAM currently do that, but I could be mistaken. |
Contributor
Write a small script which checks which hash a password is using, and if the hash is weak, run |
Contributor
|
Would be nice to have it happen automatically, without forcing a password change. |
Collaborator
Author
Agree. Having more complexity in shadow utils would be dangerous. I'd favour an approach with a script that checks weak passwords, and expires them immediately, keeping the usual shadow utils simple. |
Collaborator
Author
Would you trust a password that has been hashed with MD5? I think we shouldn't silently hide the fact that a password was less safe in the past, and thus might have been exposed. A user would be able to re-enter the same password, anyway, because having different hashing algorithms, passwd(1) wouldn't be able to detect that they're the same. |
Contributor
Fair enough.
Not true: passwd could hash the new password using MD5 to check it against the old one. In fact, it usually asks the user to enter their old password before being allowed to enter a new password. |
Contributor
Yeah, I guess it makes sense to keep the shadow implementation simple. Might be a better fit for PAM. |
Collaborator
Author
Yup, we could if we wanted to. However, we don't (and I don't want to do it). :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cc: @andreboscatto, @ikerexxe , @thkukuk