Upshot for vendors: a version number bump for patches is important!

Our primary goals should be to ensure that fixes we produce, and information we generate in the QA process, make their way upstream where they will benefit the broadest cross-section of the community. Separately, we want to ensure that each Ubuntu release ships without major issues, regardless of where those issues originated. We are responsible for the user experience of every line of code, even though we don’t produce every line of code.

For Shuttleworth, upstream cooperation is the key to providing the best user experience when it comes to distributing projects you did not write.

I reply:

Can you give me some guidance on your response guidelines to security vulnerabilities? Is there a timeframe that you try and have vulnerabilities fixed by?

They reply:

Hi David,

We’re always looking for new ideas and fixes to roll out in future updates but as as rule we don’t comment on possibilities or timeframes.

His commenters discuss the lack of reporting guidelines for security flaws in websites. In a more recent post, he reveals that 37signals was the previously unnamed vendor, and writes:

Vulnerability reporting should not be handled in the same way that you manage feature requests.

[Via ZDNet, which discusses whether treating security flaws as defects is a more effective way to communicate the problems they cause.]

Issues to consider here are the usual with security bugs: vendor communication versus disclosure. In the case of security problems in end-user software the problem with disclosure is the race for users to patch their systems against attacks being launched on those systems, with consequences that vary per attacked system. When it’s a website with a security problem, disclosure has a different weight, as rather than leaving some users in the lurch while a fix is rushed out (or leaving them to fight for one), the vulnerability can largely be fully exploited immediately. There’s only one target. You may be writing off this vulnerability’s consequences all together in the hope of future responsiveness from the vendor.

In other words, this is an issue that could have surfaced at any point in the past two or three years — but did not. Instead, news of the bug surfaced just five hours into biggest, and perhaps most important, software launch in Mozilla’s history.

The article goes on to describe various possible motivations for timing a security announcement with a highly publicised major release: it might benefit the researcher, but it also hurts Mozilla a lot. This is hostile bug reporting at its finest, if it wasn’t a coincidence.

“The problem is a classic example of buffer overflow from the ’90s,” Core Security CTO Ivan Arce told TechNewsWorld. “It’s not a very sophisticated thing, [which] makes it surprising.”

…

The flaw was first found in January, but Core Security says it was not corrected until just a few days ago.

“This could have been done better — especially on such a critical software,” Arce told TechNewsWorld. “It’s not somebody’s FTP server. It’s software that is critical and should be addressed in a more timely manner.”

…lets be honest with ourselves. We’re actually ok with some things going “boom”. If we weren’t we’d be working for NASA. Every other development house I know of regularly releases software with bugs in it. As long as nothing too important breaks and nothing breaks in a way that leaves you looking like an idiot there’s a good chance you’re willing to live with it, for a while at lest. So, now that we’ve admitted the truth to ourselves, we can start triaging our app.

Bugs that less likely to be fixed:

It would be great to fix every bug in the product, but it’s also great to ship J. In prioritizing which issues to fix, here are the some factors that cause certain bugs to miss the triage bar. Bugs that are least likely to be addressed:

• Are not reproducible or very hard to reproduce. This may be because the problem occurs intermittently or there are not enough details in the bug report
• Have strange and complex steps to introduce failure
• Have no perceived customer impact
• Are edge cases
• Risk introducing greater instability through the bug fix then the bug itself causes. Especially late in the product cycle, the bar for these types of bugs is very high because the bugs that may be introduced by the fix we will likely not have time to fix.

The quality of open source code has improved over the last two years, according to an audit sponsored by the US Department of Homeland Security.

The security and quality of more than 250 open source projects – including Apache, Linux, Firefox and PHP – was assessed using code analysis tools from Coverity as part of the federal government’s Open Source Hardening Project. Coverity set up a scan site that invited individual developers to put their code through its paces with its static source code analysis tool, Coverity Prevent.

So, what is the Ubuntu Global Bug Jam? Put simply, it is a world-wide online and face-to-face event to get people together to fix Ubuntu bugs – we want to get as many people online fixing bugs, having a great time doing so, and putting their brick in the wall for free software. This is not only a great opportunity to really help Ubuntu, but to also get together with other Ubuntu fans to make a difference together, either via your LoCo team, your LUG, other free software group, or just getting people together in your house/apartment to fix bugs and have a great time.

Computerworld UK quotes Ralph Silva, senior analyst at financial services advisory firm Tower Group, regarding rating agencies’ lackadaisical attitude toward technology management:

Ratings agencies never put sufficient emphasis on their technology resources,” he said. In spite of technology playing a key part in ratings decisions, “they simply haven’t felt getting technology right was important enough to business processes, unlike banks”.