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>