Future Heartbleeds without the heartache

In the wake of Heartbleed, the OpenSSL project has decided that *nix distributions that use the popular crypto pack will get advance notice of upcoming security-related bugfixes.

The project has decided that distributions that ship with OpenSSL will get some advance notice of issues ahead of fixes – an announcement on the openssl-announce list but not details of specific issues.

While the project's keepers have decided that critical bugs should be dealt with “in camera” as far as is possible, they also note that critical vulnerabilities should not remain secret for too long: “OpenSSL embargoes should be measured in days and weeks, not months or years”, the post states.

The level of secrecy surrounding a bug will, the project says, be determined on three levels of severity. “Low severity” issues – including hard-to-exploit attacks – will be announced as soon as fixes are published, in general “immediately”, and while they might trigger bug-fixes, they probably won't trigger new releases.

“Moderate severity” issues include application crashes, flaws in uncommon protocols like DTLS (datagram transport layer security) and local exploits. These, the project has decided, will be kept in-house until a new release with bug-fix ships.

“High severity” issues will be kept private until a new release of all supported versions ships, with the project undertaking to “keep the time these issues are private to a minimum”, in particular if there is either a risk or evidence that an issue is being exploited.

This has an interplay with the notification policy: mostly, when a security-fix release is planned, it will be announced (along with its severity) and the schedule posted on the OpenSSL home page, but the nature of the fix won't be made public until the release lands.

However, “for updates that include high severity issues we will also pre-notify with more details and patches”, on the basis that OpenSSL-using OSes will need a few days' extra notice to prepare packages for end users and provide test feedback.

The project notes that it doesn't want the prenotification to become a marketing hook: “It is not acceptable for organisations to use advance notice in marketing as a competitive advantage. For example 'if you had bought our product/used our service you would have been protected a week ago'”, the post states. ®