Security Policy Update on prenotifications
We’re planning to extend who we prenotify of any future High and Critical security issues.
Last month we dealt with a High severity security vulnerability which affected some versions of OpenSSL, CVE-2020-1967
While we fix Low and Moderate issues from time to time, fortunately High and Critical issues are quite rare. The previous High severity vulnerability was over 3 years earlier in 2017 CVE-2017-3733 and the last Critical was in 2016 CVE-2016-6309
Our Security Policy outlines some of the principles on how we deal with issues; it’s our aim to keep issues private for as little time as possible, but also to give notice of High and Critical issues in advance to distributions in such a way as we can get more users protected from the start.
It’s always been a trade-off; so many things ship OpenSSL in them, even more have OpenSSL as a dependency, and so many of these consumer companies would like to know about issues in advance. However the more people we tell the higher the chances of a leak, but also the longer it takes to do the prenotification. We want to keep the time an issue is private as short as we can, and our prenotification period is 7 days or less. Additionally, these prenotifications use up a lot of our time as they require lots of 1:1 interactions and are always more involved than sending a single email blast with an advisory and patch. Often at the start of the process we don’t have a complete understanding of the issue so the advisory and patch change, sometimes several times, and sometimes these get altered right up to the last minute of release, as we gain feedback from distros based on their testing and review.
The OMC voted this week to update our security policy to include the option of us giving prenotification to companies with which we have a commercial relationship. (Edited to clarify: the vote was to allow notification to our Premium Support customers and this does not include lower support levels, sponsors, or GitHub sponsors.) We believe this gives a balance of how to pick a few companies that can help test and feedback on the fix; where we’ve already committed time from our paid resources to work with those companies, and also while not overloading us with extra work or overly increasing the risk of early leaks.
This change does not have any other effect on our principles, nor does it change who we already notify about issues outside of those commercial relationships. All these prenotifications will be under the same terms and timescales, and we will always choose to do the right thing for our community as a whole and not be influenced by commercial agreements. So we’re still going to get updates for High and Critical issues out as quickly as we can and keep embargoes to the minimum possible, generally 7 days or less.
Thankfully severe OpenSSL security issues are quite rare. We recommend users of OpenSSL subscribe to our openssl-announce mailing list to get our announcements and advisories.