[Dailydave] [Full-disclosure] Linux's unofficial security-through-coverup policy

[Valdis.Kletnieks at vt.edu]

On Thu, 17 Jul 2008 09:57:54 CDT, Thomas Ptacek said:

> I'm not sure Linus and Alan are really in a reasonable position to
> coordinate and clear advisory traffic. There are too many downstream
> vendors, too many release schedules, and too much political BS.

Not to mention that Linus and Andrew are basically drowning in updates, and
are quite busy enough without trying to coordinate advisories.
I did a 'git pull' of Linus's tree at 22:15PM 07/15.  It's now 10:30AM 07/18.

 508 files changed, 56962 insertions(+), 16737 deletions(-)

That's *3 days* of development.  Quite likely, that 56K new lines will have
something that turns out to be a security bug. Possibly 3 or 4.  On the other
hand, by the time the merge window for 2.6.27 closes in 2 weeks, there will be
several hundred thousand lines of updates, and probably 150 to 200 regressions.

And Linus's point is that many of those regressions matter *more* than most
security bugs, because they can totally hose your system too - corrupt
filesystems, cause system hangs and lockups, poor performance, and who knows
what else.

The other issue that *nobody* seems to want to address is that a *lot* of
bugfixes are, at the time, considered simply bugfixes.  If anything, there
are *more* bugfixes that are realized to be security-related after release
than bugfixes that are known at release time to be issues.

So we release 2.6.N with 4 known security fixes, and 4,934 other patches,
of which 15 aren't recognized as security until weeks/months in the future.

Even if they flag those 4 in the release notes, what do you propose they do
with those other 15?

(That's even supposing we can come up with a reasonable and usable definition
of "security-related bug".  By one standard, almost every oops or panic would
count as DoS bugs, by other standards those are just bugs that need fixing
because probably 20 times as many sites will trip over them by accident as
will get hit maliciously by them.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080718/1d2481c0/attachment.pgp