Description of problem: Background for this in https://bugzilla.redhat.com/show_bug.cgi?id=1992607. Before f35, libpwquality didn't require cracklib-dicts. This was changed in f35 to conditionally requiring it if `passwd` or `cryptsetup` is installed. It would be nice if this could be loosened to go back to the f34 semantics of not requiring cracklib-dicts at all, or at least making it a weak dependency only. In Fedora CoreOS at least, we focus on automation and minimalism. And while we do ship passwd and cryptsetup, in general we don't expect users to create passwords at the prompt: - for `passwd`, we strongly encourage SSH, but even if not, password setting is done upfront via Butane and not interactively: https://docs.fedoraproject.org/en-US/fedora-coreos/authentication/#_using_password_authentication - for `cryptsetup`, we strongly encourage Clevis for automated unlocking via TPM2 or a Tang server: https://docs.fedoraproject.org/en-US/fedora-coreos/storage/#_encrypted_storage_luks Version-Release number of selected component (if applicable): libpwquality-1.4.4-6.fc35.x86_64 How reproducible: 100% Steps to Reproduce: 1. Install libpwquality while having passwd or cryptsetup installed or 1. Do an rpm-ostree compose which pulls in libpwquality Actual results: cracklib-dicts gets pulled in Expected results: cracklib-dicts doesn't get pulled in
As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1992607#c11, rather than trying to extricate the libpwquality dep from pam and cryptsetup, it'd be nice to keep it around still and to at least check the things that it can in the absence of cracklib-dicts.
Do I correctly understand that libpwquality behavior should be changed to correctly process the lack of dicts? (See https://bugzilla.redhat.com/show_bug.cgi?id=1992607 and https://bugzilla.redhat.com/show_bug.cgi?id=1992607#c9 for more details).
(In reply to Dmitry Belyavskiy from comment #2) > Do I correctly understand that libpwquality behavior should be changed to > correctly process the lack of dicts? > > (See https://bugzilla.redhat.com/show_bug.cgi?id=1992607 and > https://bugzilla.redhat.com/show_bug.cgi?id=1992607#c9 for more details). Yes, that's what I'd like to suggest. In FCOS, we actively disable dictcheck: https://github.com/coreos/fedora-coreos-config/blob/testing-devel/overlay.d/05core/etc/security/pwquality.conf.d/20-disable-dict.conf so cracklib-dicts already isn't queried, but ideally libpwquality would stop hard requiring cracklib-dicts and detect its absence dynamically without requiring upfront configuration. That way we can drop that dropin, as well as stop shipping cracklib-dicts.
Many thanks! If so, I think it's a future feature.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This is still relevant and would be nice to tackle.
FEDORA-2022-8595ad93db has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-8595ad93db
FEDORA-2022-8595ad93db has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-edda4c3b97 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-edda4c3b97
FEDORA-2022-edda4c3b97 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-edda4c3b97` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-edda4c3b97 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-edda4c3b97 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
This caused multiple problems: https://bugzilla.redhat.com/show_bug.cgi?id=2158891 I am going to change the Suggests to Recommends.