This Time Self-Hosted
dark mode light mode Search

You can finally ditch cracklib

Some time ago there were discussions about moving cracklib out of the system packages set, as it’s far from being a necessary package. Indeed, cracklib is no more in system, although up to now if you used PAM you couldn’t actually remove it, as sys-libs/pam itself required it.

Not any more. Today I committed a revision bump for sys-libs/pam that makes cracklib optional, controlled by the cracklib USE flag. This is easily possible thanks to the epam “syntax”, that I described previously . Now it’s just a matter of documenting it in my guides, and then I can actually start make use of it, for instance ftpbase will certainly get some tweak so that when it’s installed in FBSD it uses pam_ftpusers rather than pam_listfiles.

More stuff to document, but more flexibility for the future, hopefully, so that future transitions will be painless. Or at least less painful than the one we’re going to have.

By the way I want to thank everybody for the feedback about the upgrading guide; I’ve made it a bit more explicit about what has to be done and when: things that might be pretty much obvious to me and others who have seen PAM at least remotely before might not be obvious nor easy to guess to others who never looked up what PAM is at all.

Anyway, more documentation ahead… sponsoring options still open 😛

Comments 4
  1. Why is cracklib good or bad? This is not a critique of your work, to be clear. I am curious about the software I am running.

  2. Well, it’s not a problem of good or bad, but of it being a requirement or not. What cracklib does for pam is to provide a way to estimate the quality of a password during password change, telling you if it’s a word present in a dictionary, if it’s a palindrome of the previous password, and so on.It is useful if you got to administer a server with many different users who has to change their password frequently. It’s mostly useless for desktop-class systems, and totally useless for embedded systems.Being able to disable cracklib allows to remove a library that might just be brought in by pam (that was my case at least), and one less library is always good when it’s not needed :)Besides, there’s pam_passwdqc as an alternative to pam_cracklib, this way you can have just one of the two installed if you want 🙂

  3. If you are going to split out cracklib (as it appears you have done) I think you should of put it in base profiles as this is the expected gentoo behavior of pam. What you done is lowered the security bar that we were enforcing by default for everybody.

  4. Well, default-linux enables cracklib by default, base doesn’t; the problem here is not limited to PAM, but also to shadow with PAM disabled.Of course it makes sense to move cracklib to be enabled in base, I wonder why it was done on default-linux only :/

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.