Security embargoes are something of a double-edged sword. The idea is to
coordinate a release date for a particular security fix between the
affected parties (typically distributions in the Linux world). But, while
the embargo is in place, no fixes are being issued which increases the
length of time that users are vulnerable. That could lead to
widespread—or targeted—attacks against vulnerable systems if
the flaw is already known, is leaked, or is rediscovered during the embargo
The chances of that may be relatively small, but they certainly increase as
a function of the length of the embargo.
It is for those reasons that embargoes in the Linux world are typically
short. While proprietary vendors will sometimes sit on a vulnerability for
months, Linux embargoes are generally on the order of a week or two. The
rules for the acceptable length of an embargo are set by the venue where
the information is shared, which for Linux distributions is the closed linux-distros
mailing list. There is also an associated distros mailing list which also adds
in representatives from some of the BSDs. These two lists have taken the place
of the vendor-sec list that was compromised
in March 2011.
Up until recently, the guidelines for linux-distros specified that the
maximum allowable embargo was 14 days. That means that anyone reporting a
bug to the list should be willing to wait that long to publicly
release any information; it also binds list participants to that
deadline. The idea is that anyone who doesn't want to agree to embargoes
of up to 14 days shouldn't be using linux-distros. As part of the
discussion of the bug and fix on that list, a coordinated release date (CRD)
would be chosen so that all distributions would release at the end of the
List administrator Alexander Peslyak (aka Solar Designer) recently made a
change to the guidelines to better reflect reality. There is an effort to
avoid having a CRD that falls on a Monday or a Friday to try to not
land on a holiday or other inconvenient day for administrators who may
need to do lots of updates because of the security fix. That meant that
the 14 day maximum sometimes stretched to 19 days, so Peslyak changed the
page to reflect that. He also posted to
the open oss-security list to highlight the change.
There were no complaints about the change, though there were some
alternatives suggested (10 business days for example), until Peslyak followed up his message suggesting that
perhaps the 14-19 days be reduced to 7-11 days. Even that length of time
is longer than he would like, "but I am proposing what I
think has a chance to be approved by others without making the list a
lot less useful to them".
Peslyak also outlined his reasons for preferring
shorter embargo windows. Distributions that have the fix ready more
quickly can get it into the hands of users sooner, rather than waiting
a week or more for the embargo to end. Also, it reduces the window of time
in which the vulnerability could be rediscovered or leaked from the list
somehow. There are also logistical concerns with longer embargoes including
increased tracking of multiple overlapping embargoes.
Both Marc Deslauriers of the Ubuntu security team and Kurt Seifried of the
Red Hat security response team were quick to disagree with a one-week (more
or less) embargo period. Depending on the severity of the bug and the
difficulty of the fix, it may be hard for some distributions to pull
together, test, and release fixes in that time frame. In particular,
Seifried is concerned about volunteer-run
distributions that may lack the staff to ensure fixes in a shorter period.
But Deslauriers makes another important point:
This means vendors will be keeping information about the vulnerability
private until they are confident they are able to release within a week,
at which point they will then share the information with other vendors
who will scramble to get their updates ready.
As a distro, I now have two choices: I sit on vulnerabilities until our
own QA and testing is done, at which point I send them to the list and
hope that 7 days is enough for everyone else, or I simply stop using the
list for anything that's more than trivial and contact other vendors
That's the fine line that Peslyak is walking here. If the embargo
requirements become too onerous (or seem that way), distributions may stop
reporting to the list—or only report after they have made progress
with a fix. But, other lists have other rules. The closed kernel security
list says that it will do embargoes up to 7 days, but it seems to rarely
happen that way, undoubtedly partially due to Linus Torvalds's distaste for
embargoes. That policy may also result in distributions delaying reports
to the kernel security list,
It should be noted that these "closed" lists have been fairly leaky at
times. In addition to the vendor-sec list compromise, the kernel security
list may have been breached as part of the kernel.org compromise. The
list now uses PGP-encrypted emails, which should help unless the host doing
the re-encryption to each member's key is breached.
There are also dangers from fixes that are rushed, of course. The
recent PHP remote code execution
vulnerability came about because of a rushed fix for a different security hole. There is certainly
value in taking some time to get a security fix right, the only question
here is how long that should be, and, for full disclosure types, whether
users should be made aware of the problem while the fix is in progress.
In the end, the 14-19 day window stayed, though a preference for embargoes
of less than 7 days was added. It's a difficult problem, partly because
there are so many unknowns. Fixes can be difficult to apply (particularly
if they need to be backported) and to test, especially for multiple
distribution releases. But the longer the bug is embargoed, the longer
users are at risk without any ability to mitigate the problem locally while
awaiting a fix. That's why the full disclosure camp believes that
information on security holes should be released without delay, so that
users are empowered to make their own decisions. That approach is not
very popular with vendors, of course. Embargoes and their length is an
issue that will likely be debated again and again because there isn't an
"obviously correct" solution.
Comments (8 posted)
The solution to "My kernel update doesn't boot" should be "Automatically
detect that that happened, give the user that information and fall back
to the old kernel", not "Always show the user a menu that they almost
always don't care about". Solve the actual problem.
-- Matthew Garrett
And so, I intend to wear those shoes proudly. While I don’t plan on
following in the footsteps of anyone (because, you know, that would be
walking in circles, which isn’t highly productive), I do aspire to step
with the same spirit that those before me have — honestly, transparently,
communicative-ly (new word!), with humor, and with care. And I aspire to
Get Stuff Done, sans red tape.
Anyhow, while I am looking forward to playing around with Debian Wheezy,
the current Debian testing branch, I can foresee Squeeze and my #! Statler
builds remaining on a couple of my boxes for a good while yet. IMHO, the
release still has plenty of legs left in it, even if some people consider
it only fit for servers. Troglodytes!
-- Philip Newborough
Comments (1 posted)
Stefano Zacchiroli shares a few bits on his January activities. Various
legal issues have kept him busy, including the copyright and licensing of
the Debian web site, trademarks, and working with the Debian France
association in becoming a Debian Trusted Organization.
Full Story (comments: none)
The Debian GNU/Hurd porters have installation media available. These bits
also contain their Wheezy release goals. "Since the ftp-master
meeting in July 2011, significant improvements have been made, and a
technological preview of GNU/Hurd with Wheezy, as was made for kFreeBSD did
for Squeeze, is still the target.
Full Story (comments: none)
Fedora project leader Jared Smith has announced that he is moving on. "I'm happy to announce that Red Hat has selected Robyn Bergeron to be
the next Fedora Project Leader. Robyn has proven herself in the
Fedora community over the last several years, and I have complete
confidence in her abilities to lead the Fedora Project. In addition
to planning FUDCon Tempe in 2011 and helping to lead the Marketing and
Cloud SIGs within Fedora, Robyn has been an integral part of many
other Fedora events and endeavors. Most recently, she has held the
role of Fedora Program Manager, helping to ensure that we all stay on
schedule and helping the Fedora feature process stay on track.
Full Story (comments: 12)
Kubuntu lead developer Jonathan Riddell has sent out an announcement that
Canonical will no longer be funding work on the KDE-based Kubuntu
distribution. "The practical changes are I won't be able to work on KDE bits in my
work time after 12.04 and there won't be paid support for versions
after 12.04. This is a rational business decision, Kubuntu has not
been a business success after 7 years of trying, and it is unrealistic
to expect it to continue to have financial resources put into it.
Full Story (comments: 92)
Newsletters and articles of interest
Comments (none posted)
"2012 will be the year of the lizard
, in this nod to SUSE Linux's 20th anniversary this year. "But this relatively long existence almost didn't come to pass, as what began as S.u.S.E. GmbH in 1992 has undergone two major takeovers, a partnership with Microsoft that led to near-revolt in the Linux community, and a heretofore-unknown consideration by Red Hat to purchase the German Linux company just prior to the turn of the century.
Comments (none posted)
at Parabola GNU/Linux, a recent entry in the GNU list of free
. "Parabola developers chose a refreshing approach to limiting the availability of non-free software while maintaining the ability to use Arch mirrors: all the "liberated" (built with special options or otherwise stripped off the non-free parts) packages are included in a separate "libre" repository; the blacklisting of non-free packages is done with a virtual "your-freedom" package that doesn't install any files but conflicts with a long list of packages. Installing this package makes pacman (package manager) remove all the non-free software to resolve conflict or replace it with free analogues if required.
Comments (none posted)
Page editor: Rebecca Sobol
Next page: Development>>