Sometimes you’re saved…

…and sometimes you’re not, this time it seems to me like I am finally. This night I woke up at 4am, couldn’t really sleep, and decided that there was one big TODO in my list that needed to be killed off before I could feel better; that TODO was the PAM bump.

As I wrote in the past, PAm is one f those packages for which the most irritating thing to handle during a bump is the build system, because they don’t use autotools a they are designed to be used. In this particular case, the makefiles were abusing the LDFLAGS variables to pass the libraries to link against, bad choice. Unfortunately there are a lot of modules to fix the makefile of, so it took me a very high amount of self control to actually get around to fix it.

I’ve spent the early morning fixing the makefiles from Intrepid, then when I got the final patch (about 34 KiB uncompressed), I tried the build.. oops, I forgot there was still the documentation problem to solve, too!

Basically, I was forcing DocBook as a dependency of PAM in the past, because it failed to build for me without those, and I never really had the time to get around looking for that to fix. I already got a report saying that PAM built fine without them, so I knew I had to do with some kind of automagic dependency (I hate them), that would have asked me again to look at PAM build system. This time I decided to fix that for good too, and now manpages and documentation won’t be rebuilt from sys-libs/pam package, instead the upstream-supplied documentation will be installed, nothing else. This hopefully will also cut the time needed for it to build, and will fix it crosscompiling, too.

I haven’t bumped pam_userdb because the buildsystem changes weren’t important for that single module, and there was no code change; I’ve decided to get a bump to pam_console though, even if I have no idea if RedHat changed the code or not, so that I could stick an extra warning on the ebuild. I «employed» already too much time to write that package once, I don’t intend maintaining it on long terms, every problem that it can cause, will be considered responsibility of the users, not mine; the pam.d files installed will collide with other packages (I hadn’t added them, I wouldn’t have added them in the first place), and pam_console useflag is evil and should be masked by default, leaving to the user to unmask it. Unfortunately it seems like Gentopia still likes using pam_console (and I can’t understand why as that code is broken by design and I’m just hoping RedHat is going to kill it off like they seem to be doing with pam_stack.so).

Anyway, with this bump I also cleaned up a few open bugs for PAM “team” (aka Robin for pam_ldap and me for the rest); luckily most of the bugs are simply requests to add new modules to Portage… I’d like to help my users with those, but I don’t have the time needed to maintain them alone, but if you want to add one particular module, I can handle a proxy maintainership I suppose.

One module that is already in portage and is giving quite a bit of trouble, thought is pam_krb5, so I’ll be looking forward to get a last rites for it unless I can find someone to maintain it, I cannot really do that myself, I have no clue about Kerberos and I don’t really want to have some.

Now, after asking for 0.78-r5 to go stable (it was waiting for a bit to be), I’m starting thinking about getting a 0.99 version stable someday, but there are problems with the upgrade, first of all the pam.d files that used pam_stack.so won’t work anymore, they absolutely need to be changed to include syntax (luckily, most of the newly installed pam.d files will just use include syntax already); then there are the two modules that got split out the main package, pam_userdb and pam_console… about the latter I already talked above, if it was for me, pam_console wouldn’t ever go stable, but there are packages that probably depend on it on stable tree too (sigh) and currently work because it’s built with pam package (next task for later on today: make sure that packages with pam_console useflag depend on pam_console); about pam_userdb, the problem is more complicated.

It’s complicated because there might be people using pam_userdb in production environments, so the fact that upgrading pam will remove the module is not really a good thing unless you actually get documented the fact that you need the other module. Also, pam_userdb right now is building its own copy of berkdb library, static with PIC, which makes it a problem from a security point of view if a vulnerability is found in berkdb library; the problem is that using berkdb library dynamically is a no-go (it’s installed in /usr/lib rather than /lib, moving it around is far from being a good idea), and berkdb static library is not built with PIC (by policy). I’ve asked Paul to think of a solution, because most of the possible solutions would ask for a change in berkdb before pam_userdb.

The bottom line is that PAM is something I can only see as a curse, I had the misfortune to have to fix the pam_stack situation for Gentoo/FreeBSD, and now I’m all the way in, without even needing it myself in the first place (most of home users shouldn’t really need PAM), neither for home nor for my jobs. And I’m alone taking care of it, which means that if I don’t consider investing some of my time in it on a regular basis, it’s easy for bugs to pile one over the other, and being PAM a central piece for the security of the systems where it is enabled, it’s not something you’d like to have unmaintained.

I suppose the only escape route I have to get 0.99 stable, anyway, is to write some upgrade documentation… but I don’t really feel like writing one right now; I could ask our documentation project for a monkey, but last time it seemed to me like only nightmorph is actually active, and I’d rather not ask him again, as he has already a lot of things to tae care of.