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

[pageexec at freemail.hu]

On 18 Jul 2008 at 10:43, Valdis.Kletnieks at vt.edu wrote:

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

no, that's not 3 days of development. that's 3 days of commits during the
merge window. you know, when, well, such commits are expected to be merged
in the first place. the development of these patches took place of over
several weeks/months beforehand.

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

and when those regressions are fixed, will the corresponding commits state
that they fix a filesystem corruption/system hang/system lockup/etc problem?
because if they do (and past history suggests so) then you've just answered
why commits fixing security bugs should also say so.

> 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?

why would they have to do anything with something they don't even know exists?
how's that relevant to their handling of commits where they do know what they
fix?

> (That's even supposing we can come up with a reasonable and usable definition
> of "security-related bug".

a security bug is one that allows to break the security model of the given
system.