Description of problem: In #1919026 the dependency on cracklib-dicts was changed to Requires. This fixes the bug, but creates a significant size regression for images where libpwquality is pulled in through dependencies, but which never need to change any passwords or even don't have any users. (libpwquality is used by cryptsetup, etc.) Please change the dependency to only pull in cracklib-dicts if /usr/bin/passwd is present: - Requires: cracklib-dicts >= 2.8 + Requires: (cracklib-dicts >= 2.8 if passwd) + Requires: (cracklib-dicts >= 2.8 if cryptsetup) (An alternative solution would be to fix libpwquality to gracefully skip the check if the file is missing: after all, the admin decided not to install the file, and the library shouldn't try to outsmart them. If that is done, then the patch above should be changed to use Recommends instead.) Version-Release number of selected component (if applicable): libpwquality-1.4.4-5.fc35 How reproducible: deterministic Steps to Reproduce: 1. install a basic container which pulls in libpwquality through deps 2. installation changes between F34 and rawhide: -SourcePackage: cracklib-2.9.6-25.fc34.src.rpm -Packages: cracklib -Size: 251906 +SourcePackage: cracklib-2.9.6-26.fc35.src.rpm +Packages: cracklib cracklib-dicts +Size: 10066620 Expected results: minimal containers don't grow in size unexpectedly
FEDORA-2021-5c76d6d666 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2021-5c76d6d666
FEDORA-2021-5c76d6d666 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-aee002b8f3 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-aee002b8f3
FEDORA-2021-aee002b8f3 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-aee002b8f3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-aee002b8f3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Thanks!
FEDORA-2021-aee002b8f3 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-813e88bc3c has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-813e88bc3c
FEDORA-2021-813e88bc3c has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
Sorry for not noticing this earlier, though this is also relevant for FCOS. We previously didn't ship cracklib-dicts and disabled password quality checking since the focus is on a minimal footprint and automation (see https://github.com/coreos/fedora-coreos-config/pull/221). But in f35, we do ship it again (https://github.com/coreos/fedora-coreos-config/pull/1206#discussion_r705425869). The new conditionals don't help FCOS because we do ship both passwd and cryptsetup. How hard would it be to implement the alternative solution suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1992607#c0? To be clear, this isn't something that needs to happen for GA. We can ship cracklib-dicts for now, though it'd be great if we could shed the dependency again eventually. If you're open to it, let me know if you'd like me to file a separate RHBZ and/or in some other upstream tracker.
I'm still a but confused about the comment: An alternative solution would be to fix libpwquality to gracefully skip the check if the file is missing: after all, the admin decided not to install the file, and the library shouldn't try to outsmart them. It is not so much outsmarting the admin, as it is not delivering a non-functional promise. What gains does one get with libpwquality without cracklib-dicts ? Wouldn't it make more sense to create a cracklib-dict-minimal or something that offers the same Provides: as cracklib-dict, but doesn't contain any (or very few) words?
> It is not so much outsmarting the admin, as it is not delivering a non-functional promise. What gains does one get with libpwquality without cracklib-dicts? It depends what you are doing. In my case, I don't *use* libpwquality at all — no passwords can be set by a user, so there is nothing to check, and libpwquality is only pulled in as a automatically generated dependency because of linking. Mode widely though, I think libpwquality *could* return a useful answer even without the dictionaries: after all, it measures other aspects of the password, such as length and charset which don't use a dictionary. But that'd require some changes to the code AFAIU.
I filed https://bugzilla.redhat.com/show_bug.cgi?id=2006063 for the RFE to make sure it's tracked in an open RHBZ. :)