Pambase is not that free

You probably know that I’m the PAM maintainer of Gentoo Linux, for good or bad (mostly bad, given that I don’t use most of its features, which I have to maintain nonetheless,). To ease my own work when trying to track down what users have been up to during bug triage, I created a package called pambase providing USE flags to enable standard configurations for particular, commonly used, modules.

This package got even more useful when we started having the need for particular features to integrate with our default stacks, for the users to be able to properly use them, like ConsoleKit and Gnome-Keyring, and to upgrade the hashing function to something less broken than MD5.

Now, all in all, I’m pretty happy to how pambase shaped up, it’s quite usable and I can easily make use of it to handle things like blowfish via xcrypt if wanted. Today I, indeed, received a request for pam_abl integration — well, the request was misdirected toward OpenSSH and the provided patch was totally bogus as it only added a nasty dependency, but the idea behind it is quite reasonable.

Now, we get back to the title: “pambase is not that free” does not have to do with the licenses related to pambase (which as far as I know are all well compatible) but rather with the work that goes behind it, for me and – much more – for the arch teams.

Adding support for a new (optional) module into the pambase package makes that module enter the system set; this is why, for instance, a good part of GNOME can now be considered part of the system set. You have to understand that even if it might not be in your system set, or in the default system set for what matters, the packages have to be carefully considered to not break if they are part of the possible system set, via optional USE flags as well. Adding gnome-keyring to that possible system set added a whole lot of branches in there.

Packages in the possible system set tree have to be paid special attention to: you cannot assume the presence of the entire system set for them, so things like zlib and bison have to be added to the dependencies of the ebuild (this is needed for the depgraph to be drawn correctly). Also, packages that are added to pambase need to be ready to go stable: if I were to add xcrypt or pam_abl to the possible dependencies of pambase, we got to be able to mark those two stable at some point in time.

This also adds quite a bit of burden to the maintainers of those packages, as the package will now be scrutinized much more deeply, and used by many more users (since they won’t need to know how to configure PAM to enable them).

Am I just ranting here? No I don’t think so; I just think I might have taken the wrong approach with pambase, and I’d like to see if other users have suggestion on which alternatives we could have. I guess something similar to what is done to fontconfig could be useful: get each module to provide some configuration files in, say, /usr/share/pambase/ and then have an eselect module to turn on and off the configurations.

The problem with this approach is that you have to cope with quite a few situations, which should probably be identified, modeled, considered and designed before implementation:

Given there is so much stuff to be considered, I ask everybody who has a non-default PAM setup to please let me know about it, explain me how you use PAM in Gentoo so I can judge how to proceed in the future! Either comment here or, if you have privacy concern regarding your setup, send me an email: CC pam-bugs@g.o (g.o being our distribution’s domain, obviously!) if you care or, if you really don’t want details about your setup to be read by anyone else, send it directly to me and encode it so only I can read it.

Again, thanks, and please try to get this post around so I can gather as much details as possible on what we need.

Exit mobile version