The open source software world has its fair share of stupid behaviour. Between 90 million idiots cut loose with PHP+MySQL and 10 million "superior" idiots with MySQL and Rails, I'm surprised the community is able to churn out anything useful at all. Nevertheless, we seem to have managed to build great big towering tributes to our anarchistic, disorganised behaviour, called "distributions". I want to vent a little bit about them because I think there's too few people sitting on the outside of distributions giving them feedback, and I think it's time that changed.
Firstly, I personally think distributions are quite a neat idea. They add some sembalance of order where where was none before, and are a realistic alternative to the "ideal" situation - which for me would be where software is fully distributed, and simply declares a list of capabilities it has, coupled with some kind of global search to allow you to find and install software matching the capabilities you require - but I digress [1].
The problem I have with them, as they stand, is that in being so big they are very powerful, compared to the average software that they package. They're this way because they have to be. Nobody wants to use distribution YetAnotherLinux if if doesn't even package xdinosaurs, I mean come on even Gentoo managed to kludge something together for it so why can't YALinux [2]?
So they package more and more software. And the YALinux maintainers are lazy, so they invent systems that means that one person can maintain more and more software packages. The maintainers are emboldened by this, and all take up more and more software, until of of them gets a real job, or a girlfriend [3], and then all of a sudden 10 packages are not being maintained.
Now the distribution has quality and security problems because xdinosaurs wasn't written that well but now people are using it because it's packaged, and it has a lot of arbitrary code execution but upstream also got a girlfriend. So the distribution puts together a crack team of maintainers, picked by those who are the best at flaming on the mailing lists, and and this team has the job of applying slap-dash patches to the packaging of programs like xdinosaurs, to paper over the holes.
Now this is all fine and good. If you read through that course of events, you'll see that nobody ever did anything strictly wrong, and it respects and adapts to the fact that sometimes people's circumstances change. Perhaps the only thing that was wrong was that the maintainers got over-confident about how much they could handle, but we all know coders are an arrogant bunch whom are prone to this type of thinking, so the scenario I describe is, I think, situation normal.
But. In acknowledging that people have flaws or their circumstances change, and seeing that because of their size most people get their software from distributions, a problem begins to make itself apparent. More people than ever are using xdinosaurs, but they're mostly getting it through a distribution where their maintainer decided to package a development snapshot of their software and leave it to rot in stable for three years, or their maintainer likes to practice "full" (read: stupid) disclosure of any security bugs when reported to them, when the project has a perfectly good responsible disclosure policy.
The first problem is clearly the fault of the distribution, but it has happened before and nobody can guarantee it won't happen again. Maintainers make mistakes. You can't tell me it won't happen again, across all distributions, for all eternity after now. So don't even argue this point. Sometimes distributions package software in a way that upstream would rather it wasn't. And hey, I'm not saying this is always a bad thing - there may be a perfectly good reason for changing the defaults or support libraries used for packaging purposes. Some of these reasons will seem very good to the distributions, but may compromise the quality of the software. And this is dangerous because people don't think to blame the distributions when xdinosaurs isn't working. In fact, let me repeat that just to make sure you didn't miss it:
When someone installs a program through their distribution, and it's broken, *they blame the program*. Then they uninstall it.
People don't think "oh it could be an issue with how xdinosaurs is packaged by my distribution". Only us nerds who know what the difference between Linux and Ubuntu is could even begin to comprehend this. And sometimes we don't even think of this - there's plenty of software I've installed through Debian that seemed like crap that might have been good, had I tried compiling from source. But I didn't do that, I uninstalled it and looked for something else. This justifies my previous point that distributions are powerful. 25,000 packages to choose from, and no blame taken when they don't work! (And again I'll point out that I'm disregarding the nerds here).
Now here's where it breaks down. Given that the distributions have this power, I think it's only fair if they accept the responsibility then, of being a first point of call for any bug reports. After all, it could be a problem with the packaging, and only the maintainer can find out for sure. And upstream doesn't want to be bothered with 1000 duplicate bug reports about how some feature doesn't work when it was the fault of the maintainer - that clearly is going to cause tension.
But, by the above statement about people blaming the program first, this often means that people head straight for the software to report their bugs. What an annoyance! The last thing I want to do as a software maintainer is wake up in the morning and delete 10 e-mails from people running xdinosaurs on YALinux and having that bug that's caused by the packaging - man, the maintainer is a dick, I wish YALinux never even packaged my software!
This is one of those tricky problems where there's no easy answer. But here are some guidelines that I think could help, and I would encourage all distributions to consider adopting them.
Make reporting bugs to the distribution easy
When I say easy, I mean that it should be easier to report a bug to the distribution than it should be to report it to the upstream project, if at all possible. This means, that "report bug" option in the menu should report the bug to the distribution when it's packaged, rather than back to the software project. Some education here from the distributions would be useful too. For example, if a real ethos sprang up in the distro community about reporting bugs to the distro, that would catch a lot of the "enthusiastic users" who know enough to report bugs, but not so much about the reasons why they shouldn't report it upstream.
I'm not saying this will be a perfect fix - it won't be, some users will simply charge straight into the software's bug tracker. At this point, it should be the responsibility of the maintainer to listen to any of upstream's complaints about this, and attempt to rectify any obvious issues quickly. Of course it helps if upstream is being constructive too. Which leads into my next suggestion...
Respect upstream's wishes
You might think that packaging their software is a great honour, but they might not think that - especially if they're getting bombarded with bug reports related only to how you packaged it. If they would like something done a certain way, it would pay to respect their wishes if at all possible - and here's the controversial bit - even to the point of removing their software from the distribution if they request it. Packaging software just because it has a free software license doesn't automatically make you cool - you might end up on the receiving end of a large amount of flak if it's not being done right, and it would probably be for the best if your distro just cut its losses and gave up for now.
All reported bugs should be private by default
I know this is probably going to be the most controversial suggestion, but please bear with me while I explain my rationale.
- We know from previous discussion that people are falliable, and sometimes they don't follow instructions when reporting bugs. Life is hard, we accept this and move on.
- We know also that you basically need a CS degree before you're qualified to tell whether any given bug report is a security issue. You need more than that in many cases. I couldn't spot a buffer overrun if it smacked me in the face, while many perfectly competent C coders couldn't tell me what is wrong with the /e modifier in PCRE.
- From 1 and 2, we can see that sometimes people will report a bug that is a security bug, without flagging it as such. Whoops, accidental disclosure
- RetardLinux has a millitant maintainer who likes full disclosure, even when upstream has a policy of responsible disclosure. When a correctly flagged security report comes in, he gleefully publishes it and his fix to the world. Whoops, deliberate disclosure
- IncompetentLinux has a good maintainer, but he's a bit new to this job and hasn't RTFM'd. In comes a serious security report that he misinterprets as a simple fix, and he accidentally publishes the fix before upstream was ready. Whoops, accidental disclosure
I could go on. The point is, we want people to report bugs to the distribution, but we also don't want security bugs to revealed before upstream has had a chance to practice whatever security policy it has in place. And furthermore, the people reporting the bugs are ill-suited to judge whether the bug is a security bug, and even if they are they may not understand the correct procedure. What a mess!
This is why I think bug reports should be private to the maintainer and reporter to start with. When a bug is filed, the maintainer can look at it and decide that either it's no security problem and can be made public, or yes/maybe it is, and they should get the second opinion of someone before making it public. This someone would ideally be upstream, but in lieu of that can be the distribution's security team.
This policy gives software projects a chance to deal with security issues upstream in their own way. For example, the world doesn't just revolve around the distribution and upstream - for example there may be a spin-off project from xdinosaurs that has the same issue but isn't packaged by YALinux, or the software project may have obligations to report vulerabilities to a closed mailing list of paying subscribers.
I'm not advocating a huge change here, really. It's not much more work for a maintainer to quickly review a bug and decide whether it's OK to be public or whether they need more information - and we know maintainers are lazy, so they'll write scripts to make that process easy too. Maintainers already have to review bug reports, so it's not like it'd be more work to tick a box. And if it's distribution policy, then the militant maintainer problem is far less likely to occur - as to irresponsibly disclose a bug would be to violate distribution policy.
This point could easily apply to upstream projects too - the same issue with people who don't know whether they've hit a security issue still stands for xdinosaurs after all. In reality, the difference between having bug reports be secret to start with instead of being open is exactly the same difference as when we use database abstractions other things that make it easy to do things the secure way (in this case, using a prepared statement) by default, instead of making it easy to do things the less secure way. You might argue that bug trackers have the ability to ask users whether they think a bug is a security issue and that this is enough, but you also wouldn't write a query without using placeholders if you could help it, would you?
That's enough for now. I haven't suggested much that upstream projects should do, you may have noticed, but then again I think they're a harder herd of cats to organise. As mentioned before, that's one thing I like about distributions, that they overlay a bit of formality and structure over a mess of software, and so that's where I think the drivers for improvement should come from.
I also haven't named any distribution in particular as being good or bad at this, though I think it's worth mentioning that I'm a Debian user and many of my thoughts are generated from actual experiences interacting with Debian (I'm not a Debian Developer).
Mostly this article is the summary of an IRC debate with Francois Marier and Dan Potawlski. They may have their own thoughts, which I'll link to if they publish them ;).
| [1] | This idea is not mine, it's not even new by the way. It sounds nice in theory but would probably never work in practice - it requires co-operation from everyone which never happens in the real world. |
| [2] | All names are fictional. Well at least they're chosen without googling to see if they really exist. |
| [3] | I can confirm this is possible. Somewhere at the edge of the bell curve is a girl for everyone. |
Like this post? Subscribe to my RSS feed and follow me on twitter to hear about new posts early.
Want to share this post? Tweet
Hi and welcome! In 2009 I quit my job to become an entrepreneur, founding 
