LWN: Comments on "How long should security embargoes be?"

How long should security embargoes be?

nix — Thu, 01 Mar 2012 12:42:33 +0000

A competent programmer working an entire day should be able to fix pretty much any bug

Er, no. Very much no. Bugfixes can take arbitrarily long periods of time, particularly if the bug turns out to be a design error. (My personal record time to fix a bug is six years -- holding off a design change until other events allowed the change -- and, like anyone, I have a number of bugs outstanding in my own code which will likely never be fixed because they are too minor or the required design change would be too large for the benefit.)

How long should security embargoes be?

dirtyepic — Mon, 27 Feb 2012 04:22:29 +0000

Testsuites aren't going to find security issues opened up by rushed bug-fixes. Nor are they going to find kernel bugs that aren't blindingly obvious. Testsuites catch regressions in the package they're testing. Someone fixed a bug and added a test to make sure it didn't happen again. I'm not saying they won't catch bugs here and there, but relying on them for security is foolish.

And even if all distros had access to clusters of machines of every security-supported arch, you'd have to get upstreams to give a shit about unrelated testsuite failures before they'd become of any use whatsoever. In my experience, it's been largely "Well it passes on my machine, sucks to be you". Some upstreams are better than others (libtool always impressed me, even going as far as to offer to add a workaround for a broken version of a in-house tool of ours), but most regard test failures that don't happen to them to be someone else's problem. This is understandable of course; I'd rather work on something more interesting too.

I'm not going to reply to the rest of your message since I can't seem to come up with a response that would be appropriate in public.

How long should security embargoes be?

slashdot — Thu, 16 Feb 2012 09:01:54 +0000

For kernel issues, just run the testsuites for all packages in the distribution, plus any other generic testsuite/stress test you have, automatically in parallel on a cluster.

Plus, manually test as needed (for /proc/pid/mem, should take less than an hour to write a program to test it still works).

A competent programmer working an entire day should be able to fix pretty much any bug; if not, the feature is most likely totally broken and can thus be disabled in that time.

I strongly doubt Linus Torvalds needed more than a day to fix the /proc/pid/mem issue for instance.

How long should security embargoes be?

kleptog — Thu, 16 Feb 2012 08:10:02 +0000

I'm wondering what kind of testing you can seriously do in 24 hours. Probably just enough to prove that it doesn't crash your system or wipe any disks within 24 hours. In any case, just because someone has found a bug doesn't mean you have a patch to fix it.

There are classes of bugs, like missing bounds checking, which can be quickly deployed with little risk but the recent /dev/mem kernel bug and the PHP debacle are subtle enough that it can take >24 hours just to determine what the correct fix is. A hastily applied fix can make the problem worse.

How long should security embargoes be?

slashdot — Thu, 16 Feb 2012 03:24:43 +0000

How about no embargo window at all?

There's no really no excuse for not being able to deliver a fix in 8-24 hours at most, assuming you have proper automated processes set up, and people distributed across timezones to allow 24/7 response.

And about holidays, well... if a security bug is discovered, one would hope people would work on holidays and at night too without interruption to fix it ASAP!

Honestly, someone who does this commercially and cannot push a security fix within 24 hours ought to be prosecuted for negligence.

How long should security embargoes be?

PaXTeam — Fri, 10 Feb 2012 23:39:59 +0000

users aren't vulnerable during the embargo only, they're vulnerable as long as they use the buggy code. the latter is usually much much longer than the former so a few days more or less for an embargo doesn't really change anything. actually i'm surprised you'd go public with such a statement considering your participation in one of the worst handled linux security bugs of all times. to refresh your memories, this is what was posted to vendor-sec on 2003.09.25:

<arjan> there's a security hole found by akpm
<arjan> that also hits your kernels
<arjan> Subject: [PATCH] do_brk() bounds checking
<arjan> that patch you want
<arjan> agreement is to put it in silently (eg no changelog)
<davej> ok
<arjan> it's not exactly public stuff either
<arjan> linus committed it with a non-security comment
<arjan> so should we
<davej> ok

and the result of this was the now infamous debian core infrastructure compromise a few weeks later. what did you want to prove again?

How long should security embargoes be?

Klavs — Thu, 09 Feb 2012 10:26:40 +0000

Not embargoing - might also help people ensure they have defence in depth - so one "currently released and unsolved" vulnerability doesn't hit them so hard.

How long should security embargoes be?

arjan — Thu, 09 Feb 2012 04:17:22 +0000

I've been around distros small and big for a long time now, and personally I've come to the conclusion that I will not do embargoes for things I have any say or choice in, and I will not join lists that enforce embargoes on my behalf. [I've had people try the "but we put you on the CC with such a list on the CC as well so you're also under the embargo", but I just laughed at the guy... that was just so sad it was funny]

The tradeoff of leaving a wide range of users vulnerable during the embargo does not, in my mind, extend to 2 weeks... If you as a distro can't get a mitigation out in 24 hours, with maybe a more complete fix in 72 hours, then frankly, fix your internal processes. That's not a reason to keep people vulnerable for a very long time.