Bug 1992607 - libpwquality: regression in minimal image size because of hard dependency on cracklib-dicts
Summary: libpwquality: regression in minimal image size because of hard dependency on ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libpwquality
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Paul Wouters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-08-11 12:21 UTC by Zbigniew Jędrzejewski-Szmek
Modified: 2021-09-20 19:18 UTC (History)
6 users (show)

Fixed In Version: libpwquality-1.4.4-6.fc36 libpwquality-1.4.4-6.fc34 libpwquality-1.4.4-6.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-11 13:35:12 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1919026 1 None None None 2021-08-11 12:22:27 UTC
Red Hat Issue Tracker FC-262 0 None None None 2021-08-12 01:22:17 UTC

Description Zbigniew Jędrzejewski-Szmek 2021-08-11 12:21:10 UTC
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

Comment 1 Fedora Update System 2021-08-11 13:32:08 UTC
FEDORA-2021-5c76d6d666 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2021-5c76d6d666

Comment 2 Fedora Update System 2021-08-11 13:35:12 UTC
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.

Comment 3 Fedora Update System 2021-08-11 13:42:33 UTC
FEDORA-2021-aee002b8f3 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-aee002b8f3

Comment 4 Fedora Update System 2021-08-12 01:20:45 UTC
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.

Comment 5 Zbigniew Jędrzejewski-Szmek 2021-08-12 08:32:08 UTC
Thanks!

Comment 6 Fedora Update System 2021-08-17 01:22:18 UTC
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.

Comment 7 Fedora Update System 2021-08-21 14:00:34 UTC
FEDORA-2021-813e88bc3c has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-813e88bc3c

Comment 8 Fedora Update System 2021-08-21 14:01:47 UTC
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.

Comment 9 Jonathan Lebon 2021-09-09 15:23:29 UTC
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.

Comment 10 Paul Wouters 2021-09-14 01:58:12 UTC
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?

Comment 11 Zbigniew Jędrzejewski-Szmek 2021-09-14 05:46:26 UTC
> 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.

Comment 12 Jonathan Lebon 2021-09-20 19:18:30 UTC
I filed https://bugzilla.redhat.com/show_bug.cgi?id=2006063 for the RFE to make sure it's tracked in an open RHBZ. :)


Note You need to log in before you can comment on or make changes to this bug.