Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionBjörn Esser (besser82)
2020-06-27 20:48:18 UTC
Description of problem:
libxcrypt validates permissible salt strings stricter than libcrypt provided by glibc.
So, on a glibc-2.17 based RHEL 7 system the following happens:
$ perl -E 'say crypt($ARGV[0], $ARGV[1])' 'foo' '$1$OiaynUa_$AEUnQiyEzpgFp42qhmUlX1'
(stdout) $1$OiaynUa_$UKu.5CDrnTktg39GKrZpP0
Note the underscore in the salt…
On a RHEL 8 system:
$ perl -E 'say crypt($ARGV[0], $ARGV[1])' 'foo' '$1$OiaynUa_$AEUnQiyEzpgFp42qhmUlX1'
(stdout) (NULL)
***
With libxcrypt we should have a fully backwards compatible replacement for glibc's libcrypt
in RHEL 8. This difference in behaviour might be a big problem for users of cPanel, as soon
as they can start to migrate their servers and setups to RHEL8.
As the libxcrypt upstream I've come up with a solution in this PR:
https://github.com/besser82/libxcrypt/pull/106
Shall I backport this for libxcrypt-4.1.1 or do we want to update libxcrypt to the latest
release, which fixes several other things not yet noticed on RHEL as well?
Version-Release number of selected component (if applicable):
libxcrypt-4.1.1-4.el8
How reproducible:
100%
Steps to Reproduce:
see above.
Actual results:
no hash is computed, errno is set to EINVAL.
Expected results:
hash gets computed, errno equals 0.
(In reply to Björn 'besser82' Esser from comment #0)
> Shall I backport this for libxcrypt-4.1.1 or do we want to update
> libxcrypt to the latest
> release, which fixes several other things not yet noticed on RHEL as well?
Are there any potentially destabilising or invasive changes in the latest upstream in comparison to 4.1.1?
If the difference is mostly about bug fixes we might decide to update.
Comment 2Alexander Sosedkin
2020-09-14 10:56:21 UTC
My vote is for backporting as the need dictates; my (limited) understanding of the changelog is that there have been several corner-cases tightened over time + the maintainers of dependent packages might experience rebuild complications if we rebase past 4.4.15.
Would be good to have it in 8.4, thanks for bringing attention to it.