User: Password:
|
|
Subscribe / Log in / New account

How long should security embargoes be?

How long should security embargoes be?

Posted Feb 16, 2012 8:10 UTC (Thu) by kleptog (subscriber, #1183)
In reply to: How long should security embargoes be? by slashdot
Parent article: How long should security embargoes be?

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.


(Log in to post comments)

How long should security embargoes be?

Posted Feb 16, 2012 9:01 UTC (Thu) by slashdot (guest, #22014) [Link]

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?

Posted Feb 27, 2012 4:22 UTC (Mon) by dirtyepic (subscriber, #30178) [Link]

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?

Posted Mar 1, 2012 12:42 UTC (Thu) by nix (subscriber, #2304) [Link]

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.)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds