Dailydave mailing list archives
Re: [Full-disclosure] Linux's unofficial security-through-coverup policy
From: pageexec () freemail hu
Date: Sat, 19 Jul 2008 14:56:49 +0200
On 18 Jul 2008 at 10:43, Valdis.Kletnieks () 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. _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- Linux's unofficial security-through-coverup policy Brad Spengler (Jul 16)
- Re: [Full-disclosure] Linux's unofficial security-through-coverup policy M. Shirk (Jul 16)
- Message not available
- Re: [Full-disclosure] Linux's unofficial security-through-coverup policy Brad Spengler (Jul 16)
- Message not available
- Re: [Full-disclosure] Linux's unofficial security-through-coverup policy Brad Spengler (Jul 16)
- Re: [Full-disclosure] Linux's unofficial security-through-coverup policy Dave Aitel (Jul 17)
- Re: [Full-disclosure] Linux's unofficial security-through-coverup policy Thomas Ptacek (Jul 17)
- Re: [Full-disclosure] Linux's unofficial security-through-coverup policy Valdis . Kletnieks (Jul 18)
- Re: [Full-disclosure] Linux's unofficial security-through-coverup policy Thomas Ptacek (Jul 19)
- Re: [Full-disclosure] Linux's unofficial security-through-coverup policy nnp (Jul 19)
- Re: [Full-disclosure] Linux's unofficial security-through-coverup policy pageexec (Jul 19)
- Re: [Full-disclosure] Linux's unofficial security-through-coverup policy Brad Spengler (Jul 16)
- Re: [Dailydave] [Full-disclosure] Linux's unofficial security-through-coverup policy Steve Grubb (Jul 17)