Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 09 Apr 2014 19:28:53 +0200
From:      =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To:        Walter Hop <freebsd@spam.lifeforms.nl>
Cc:        freebsd-security@freebsd.org, Kimmo Paasiala <kpaasial@icloud.com>, Pawel Biernacki <pawel.biernacki@gmail.com>
Subject:   Re: Proposal
Message-ID:  <867g6y1kfe.fsf@nine.des.no>
In-Reply-To: <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> (Walter Hop's message of "Wed, 9 Apr 2014 17:17:37 %2B0200")
References:  <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
Walter Hop <freebsd@spam.lifeforms.nl> writes:
> FreeBSD ports had a fix after ~4 hours I think, Ubuntu patched their
> base about an hour later, FreeBSD base took around 24 hours.

All Bryan had to do to update the port was change the version number in
the Makefile, run "make makesum" and commit.  I assume that he did some
testing as well, but apart from that, he probably spent more time
writing the commit message than actually updating the port.

Ubuntu is much the same, since they distribute OpenSSL as a package
rather than part of the base system - they don't even _have_ a base
system.

RedHat had prior notice since one of the OpenSSL devs is on their
security team.  They had an update ready to roll out before the issue
was leaked (the builds are dated 2014-04-07 11:34:45 UTC), and were
basically just waiting for the announcement, which was originally
planned for today.

To update OpenSSL in the FreeBSD base system, Xin first had to verify
which FreeBSD releases were vulnerable and which weren't.  He then had
to obtain, verify, apply and test a patch for head, stable/10 and
releng/10.0.  Next, he had to upload the patch to the freebsd-update
build servers and start the builds, which take several hours.  Once the
builds were done, he had to sign them and move them to the master
server, from which they propagated to the mirrors, and then sign the
release.

Once the builds were ready to go, he moved into a phase where everything
had to happen more or less simultaneously: commit the patches, finalize
the advisory (which contains revision numbers and timestamps), sign it,
then commit the advisory and the patch to the doc tree, update the
relevant portions of the web site, wait for them to propagate (or grab a
passing member of clusteradm@ and have them push it through manually),
and finally mail out the advisory.

Bonus points for updating vuln.xml and liaising with MITRE / CMU CERT /
NVD / what have you.

And yes, he has a whole team, but apart from writing the advisory (which
is a lot more work than you'd think), this process is pretty much
single-threaded.  The best you can hope for is to have someone relieve
you while you eat and sleep.

And while everybody is running around yelling OMG THE INTERNET IS ON
FIRE and calling this an unprecedented event, I'm sitting here with a
strong sense of d=C3=A9ja vu, because this sort of thing actually happens
quite often.  Off the top of my head, I can think of two advisories last
year - out of 14 - that were more or less rushed out in a panic.

DES (so@ on sabbatical)
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?867g6y1kfe.fsf>