The "cracklib" USE flag is enabled by default for all profiles in base/make.defaults: # 2006/10/17 - Daniel Drake <dsd@gentoo.org> # cracklib is becoming optional in shadow (and removed from system) as of # today. However, cracklib is very standard across the Linux world so we # enable it by default. # # Diego Pettenò <flameeyes@gentoo.org> (14 Jul 2007) # Moved to base/ profile from default-linux/ so that it also applies to # embedded and hardened profiles. USE="cracklib" The flag does not look critical for any of its consumers. I suggest we remove it -- I'll eventually remove it myself if no one objects after a long enough period of time. I'm CCing the maintainers of all affected packages. If anyone would like us to wait until they've set "+cracklib" in their ebuilds, please just file a blocker bug against this. I've also CCed the hardened project, because having USE=cracklib enabled there would make a little more sense (but I would still advise against it, personally). Affected packages: * app-admin/apg * dev-db/mariadb * net-fs/netatalk * net-irc/atheme-services * net-mail/poppassd_ceti * sys-apps/shadow * sys-auth/pambase * sys-libs/pam
Created attachment 511398 [details, diff] 0001-profiles-drop-USE-cracklib-from-base-make.defaults.patch I'm sending this patch to the dev list, and will commit it after a few days if there are no complaints.
(In reply to Michael Orlitzky from comment #0) > The flag does not look critical for any of its consumers. I suggest we > remove it -- I'll eventually remove it myself if no one objects after a long > enough period of time. So as to recap that lengthy discussion of the pros and cons of having cracklib protect people from using bad passwords by default, to you it does "not look critical". I can't even tell what you mean by that. I guess you were picking low hanging fruits and thought you might start some spring cleaning? Because that's the only thing I can make of this change: it's old so it's probably useless. Let me (easily) counter that by stating that having cracklib in place makes people pick better passwords. Especially the brand new Linux users we see so many of might benefit from a default mechanism that helps them make better security choices, but I am sure even advanced users and systems administrators might set a "temporary" POC password "quickly" and then later see their systems go into production without a second thought about using stronger passwords.
IMO, it's probably better to leave cracklib on by default. Is there some benefit to moving it to IUSE defaults? I can't really see one.
(In reply to Jeroen Roovers from comment #2) > > So as to recap that lengthy discussion of the pros and cons of having > cracklib protect people from using bad passwords by default, to you it does > "not look critical". I can't even tell what you mean by that. All of the packages that use "cracklib" can function without it. > Let me (easily) counter that by stating that having cracklib in place makes > people pick better passwords. Especially the brand new Linux users we see so > many of might benefit from a default mechanism that helps them make better > security choices, but I am sure even advanced users and systems > administrators might set a "temporary" POC password "quickly" and then later > see their systems go into production without a second thought about using > stronger passwords. Certainly some people will find it useful, but the flags in base/make.defaults should be useful to everyone. The cool thing about USE flags is that you can set them if you want them set. This isn't exactly a "my personal preference versus yours" thing. The two settings USE="" and USE="cracklib -cracklib" have different behavior, and the latter will clobber the per-package defaults that maintainers have tried to set. In other words, it's more annoying for me to undo your personal preference than it is for you to undo mine =)
(In reply to Mike Gilbert from comment #3) > IMO, it's probably better to leave cracklib on by default. > > Is there some benefit to moving it to IUSE defaults? I can't really see one. It's less annoying to override, and probably won't have to be overridden in the first place (if the maintainers don't enable it for no reason).
(In reply to Michael Orlitzky from comment #5) > It's less annoying to override How so? As a user, if you want it disabled globally, you'll set USE="-cracklib" in make.conf. If you want to disable it for specific packages, you'll add it to package.use. As an ebuild maintainer, you would need to disable it via profiles/base/package.use. I guess that's slightly harder than changing 1 byte in your ebuild, but it does leave the door open for other profiles to set a different default value.
(In reply to Mike Gilbert from comment #6) > (In reply to Michael Orlitzky from comment #5) > > It's less annoying to override > > How so? > For a recent example, take bug 640226. 1. Somebody adds USE=berkdb to default/linux/make.defaults. (This was excusable before per-package defaults were a thing.) 2. Actually, USE=berkdb isn't necessary, and it generally pulls in junk you don't need and enables features that you don't want. So, the hardened profile sets USE="-berkdb". 3. Now we have USE="berkdb -berkdb" when what we really want is USE="". 4. Postfix sets IUSE="+berkdb", because berkdb is actually critical for postfix (you can run without it, but... you don't.) 5. Everyone on hardened gets a broken postfix, because the maintainer's default is overridden. This would not have happened with USE="". What I want to say in most cases is "I don't want this unless the maintainer says I should have it," but that becomes impossible when a flag is enabled at the top of the profile tree.
If no one has a good reason to keep this enabled **in the base profile**, I'm still going to commit this. Anywhere else is more appropriate: * per package IUSE defaults * in the linux desktop (for new users) or hardened profile's package.use * in the linux desktop (for new users) or hardened profile's make.defaults * your own make.conf (come on, this is gentoo, it takes 2 days to compile the internet before you even enter a password)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7c47a6981f3ceee10a3645405938f4f44e2c6495 commit 7c47a6981f3ceee10a3645405938f4f44e2c6495 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2017-12-21 14:55:25 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2017-12-26 17:57:25 +0000 profiles: drop USE=cracklib from base/make.defaults. The "cracklib" USE flag has long (since 2007ish) been enabled by default for all profiles. But, the features that it provides are not critical for any of the packages that use it: typically, the library is used to evaluate a candidate password and to prevent the user from choosing a weak one. Since the flag is not critical, and because we now have per-package USE defaults, this commit removes it from base/make.defaults. Closes: https://bugs.gentoo.org/635698 profiles/base/make.defaults | 10 ---------- 1 file changed, 10 deletions(-)
(In reply to Michael Orlitzky from comment #7) > (In reply to Mike Gilbert from comment #6) > > (In reply to Michael Orlitzky from comment #5) > > > It's less annoying to override > > > > How so? > > > > For a recent example, take bug 640226. > > 1. Somebody adds USE=berkdb to default/linux/make.defaults. > (This was excusable before per-package defaults were a thing.) You still didn't address USE=cracklib being generally useful. > What I want to say in most cases is "I don't want this unless the maintainer > says I should have it," but that becomes impossible when a flag is enabled > at the top of the profile tree. Set USE=-cracklib in make.conf. Now please address these, preferably on the gentoo-dev@ mailing list where it belonged all along: 1) Why you think having USE=cracklib enabled by default is a *problem* which needs to be addressed by way of its removal. My original response questioned that, but you didn't actually answer it. 2) What you plan to do to have USE=cracklib enabled by default. Two people suggested you should keep this (one way or another) but instead everyone is now without it enabled by default. 3) This bug report sat here for two months without notice to gentoo-dev@ (and largely immaterial, without even a response from the teams you CC'd). There was no proper discussion about a change that affects not just developers, but all users, and hardly anyone knew about it until you posted your patch.
commit 33c557d89ec3d6849ac9e8da3fe3bfaa940a1e1a (HEAD -> master, origin/master, origin/HEAD) Author: Jeroen Roovers <jer@gentoo.org> Date: Wed Dec 27 11:36:58 2017 +0100 Revert "profiles: drop USE=cracklib from base/make.defaults." This reverts commit 7c47a6981f3ceee10a3645405938f4f44e2c6495. No proper discussion took place and nobody OK'd this. See https://bugs.gentoo.org/635698
(In reply to Mike Gilbert from comment #3) > IMO, it's probably better to leave cracklib on by default. > > Is there some benefit to moving it to IUSE defaults? I can't really see one. +1
After thinking about it for a bit, I can see some value in keeping the "base" profile as minimal as possible. It seems logical that other profiles would typically add onto base, rather than removing/negating settings. Removing USE="cracklib" from base/make.defaults would be in line with that motive.
(In reply to Mike Gilbert from comment #13) > After thinking about it for a bit, I can see some value in keeping the > "base" profile as minimal as possible. It seems logical that other profiles > would typically add onto base, rather than removing/negating settings. > > Removing USE="cracklib" from base/make.defaults would be in line with that > motive. Then maybe the flag should be enabled in targets/desktop instead. There seem to be valid arguments for not disabling it entirely.
(In reply to Ulrich Müller from comment #14) > > Then maybe the flag should be enabled in targets/desktop instead. There seem > to be valid arguments for not disabling it entirely. leio seems to be for it, so that's probably a viable option. I think the main value of cracklib is on a multi-user system (not your typical desktop), but I would be prefer any solution that makes everyone happy.
In my GNOME desktop world, libpwquality does this password strength stuff, but cracklib in stage3's would ensure no too bad root/first user passwords, as with Gentoo installs, those are often set before you even install a desktop. I would in your shoes just try to reach out to pam-bugs@ and mysql-bugs@ outside bugzilla (e.g, ping robbat on IRC) to get an opinion from the main consumers that matter (well, in my eyes).
For the record, in IRC yesterday, the comrel lead stated that mjo's original actions on this issue were correct.
I think everyone is happy now that we have IUSE defaults in pam, pambase, and shadow. I'll try this again soon unless somebody speaks up against it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b2701d56d58a5dd638150ad99cfc0d1139ed34d4 commit b2701d56d58a5dd638150ad99cfc0d1139ed34d4 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2018-01-03 13:15:05 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2018-01-03 13:15:05 +0000 Revert "Revert "profiles: drop USE=cracklib from base/make.defaults."" This reverts commit 33c557d89ec3d6849ac9e8da3fe3bfaa940a1e1a. Now that there are IUSE defaults for sys-apps/shadow, sys-auth/pambase, and sys-libs/pam, I think everyone is happy. Closes: https://bugs.gentoo.org/635698 profiles/base/make.defaults | 10 ---------- 1 file changed, 10 deletions(-)