Why Ubuntu's PAM versioning failure matters

July 3, 2011

As I really should have expected, a number of people showed up in the Ubuntu bug for their PAM versioning failure to say that this was no big deal and other people should relax about it. I disagree.

This PAM ABI incompatibility was not introduced by the upstream package (in a patch or a minor version update); it was introduced by Ubuntu's own patching. Ubuntu makes a big deal out of doing only minimal changes in their LTS releases (so minimal that they generally will not fix bugs, only security issues, as far as I can tell). This means that Ubuntu should be carefully auditing the patches that they use.

(If Ubuntu is not carefully auditing patches but is still beating the 'minimal changes only' drum, they are either being lazy or are extremely short of resources. If it is the latter case, they should admit that Ubuntu and especially Ubuntu LTS receives minimal care and attention because they don't have the manpower to do any better.)

That an ABI change slipped through anyways reveals a process failure of Ubuntu's patch auditing. This failure is (probably) the real root cause issue in the PAM versioning failure, not the cron locked up due to a PAM update or even that PAM had an ABI change and it was not detected.

If Ubuntu has had a process failure in PAM patch auditing, it can have a process failure in patch auditing for other packages (and indeed it seems to have had in some cases). Failures in patch auditing are serious; just how serious is revealed by the Debian SSL debacle. If Ubuntu's patch auditing is flawed (or simply only superficial, or even absent entirely), applying Ubuntu package updates in general (not just PAM updates) may be significantly more dangerous than people thought.

Sadly, it's not encouraging that the only actions Ubuntu people talked about in the Ubuntu bug were surface level issues. And really, that's the final reason that this versioning failure matters; it may have exposed something important and disturbing about how Ubuntu people approach maintaining Ubuntu.

(Yes, I'm taking kind of an extreme case view here; the reality is likely to be less scary. But we don't know, and it really does irritate me that Ubuntu's public reaction was so superficial and that people were so accepting of it.)


Comments on this page:

By gsauthof at 2011-07-05 17:10:00:

Yes, interesting bug and interesting comments in the bug report.[1]

I guess a sales person would probably say something like 'you get what you pay for'. But of course, if you pay more you don't necessarily get a better product. Perhaps it is just for the marketing.

Do 'enterprise' linux distributions (e.g. RHEL) have better quality management processes (e.g. standardized testing) to avoid problems like this (or be more professional about it)?

[1] I can feel the pain: I have lost cron-jobs because of unannounced Solaris upgrades (cron-tabs were not restored by the admins) several times. I did not lose 'hundreds of $$$' but still.

By cks at 2011-07-11 12:06:07:

In theory enterprise distributions like RHEL have better quality control, but then in theory this shouldn't have happened in Ubuntu either. RHEL has fumbled updates before, although nothing this bad.

However, for me the big difference is that RHEL will update things to fix bugs, not just to apply security patches. Since Ubuntu is so excessively minimal in what they do patch, I get even more irritable when they can't even do that well.

Written on 03 July 2011.
« Dear Googlebot: SMTP is not HTTP
Our ZFS spares handling system (part 2) »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jul 3 00:55:11 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.