I think of this as an accomplishment somehow, even though it’s not exactly the best thing in the world, but for the first time since I joined Gentoo, the current stable (or going-to-stable-soon) version of PAM is actually the last one released, just a few days ago. Now, of course to get this, there had to be not one but two security issues in PAM’s code, still it’s something nice.
Also, thanks to the fact that the mips team dropped the stable tree, the only versions in the tree are already using the pambase package which is a very good news. This does not really solve the whole PAM hell, but it at least helps a bit. It actually slightly motivated me into looking at the current state of the things again.
One of my entries in the list of things to handle with PAM has been since I joined the team renaming it; the reason for this is because the package we refer to as sys-libs/pam is actually Linux-PAM, one of the possible implementations of the PAM interface. Sure it’s a common one but not the only one, we also provide sys-auth/openpam for Gentoo/FreeBSD (and it works to some extents on Gentoo/Linux thanks to Seraphim and last year’s Summer of Code), and thus I’d sincerely rather call it sys-auth/linux-pam to show exactly which package it is.
Now, package moves aren’t really a nice thing, and indeed it’s going to be something quite controversial and I’m sure I’m going to be angrily addressed by lots of people for even thinking about that. I don’t care, this has been a long time mistake and I want it to be solved, maybe it’s because I just dislike the package, maybe it’s because I hate an upstream that rejects patches as soon as a comma is out of place, maybe I have some problems with entrusting my system’s login to a package whose authors write a new test without considering the fact that the size of a pointer might not be 8 bytes.
Before I can go on with that, though, I need the security side to settle down properly, so this is not going to happen before this summer no matter what; before that, I could be trying to reduce the hard deps on sys-libs/pam for instance. Or I could be looking into packages installing strange or broken PAM modules, since I’ve seen a few in my tinderbox.
For those packages that do depend on sys-libs/pam there is also the need to identify whether the problem is the use of misc_conv (which can be fixed, just like Seraphim did for shadow), or some other non-standard interface. Only those that hit the latter case should depend on sys-libs/pam, the rest should use virtual/pam.
At any rate, I’ll start filing some bugs for packages with broken PAM setups for now, all the rest will come later, I guess.
