-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Linus Torvalds wrote: > > On Tue, 25 Jan 2005, John Richard Moser wrote: > >>>Sure there is. There's the gain that if you lock the front door but not >>>the back door, somebody who goes door-to-door, opportunistically knocking >>>on them and testing them, _will_ be discouraged by locking the front door. [...] > >>>Never mind that he still could have gotten in. After all, if you locked >>>the back door too, he might still have a crow-bar. >> >>Crowbars don't work in computer security. > > > Sure they do. They're the brute-force password-cracking. They're the > physical security of the machine. They are any number of things. > > The point being that you will always have holes. Arguing for "there's > another hole" is _never_ an argument against a small patch fixing one > problem. > Not what I meant. http://www.ubuntulinux.org/wiki/USNAnalysis I'm more focused on this sort of security. Finding and fixing bugs is important, but protecting against the exploitation of certain classes of bugs is also a major step forward. > Take it from me - I've been reviewing patches for _way_ too long. And it's > a damn lot easier to review 100 small patches that do simple things and > that have been split up and explained individually byt he submitter than > it is to review 10 big ones. > Yeah I noticed. I'm trying to grep through the grsecurity megapatch and write an LSM clone (stackable already) based on those hooks to reimplement GrSecurity, as an academic learning experience. I try to make something functional at each step (I did linking restrictions first), but it's hard to find everything in that gargantuant thing related to a specific feature :) That being said, you should also consider (unless somebody forgot to tell me something) that it takes two source trees to make a split-out patch. The author also has to chew down everything but the feature he wants to split out. I could probably log 10,000 man-hours splitting up GrSecurity. :) > It's also a lot easier to find the (inevitable) bugs. Either you already > have a clue ("try reverting that one patch") or you can do things like > binary searching. The bugs introduced a patch often have very little to do > with the thing a patch fixes - exactly because the patch _fixes_ > something, it's been tested with that particular problem, and the new > problem it introduces is usually orthogonal. true. Very very true. With things like Gr, there's like a million features. Normally the first step I take is "Disable it all". If it still breaks, THEN THERE'S A PROBLEM. If it works, then the binary searching begins. > > Which is why lots of small patches usually have _different_ bug behaviour > than the patch they fix. To go back to the A+B fix: the bug they fix may > be fixed only by the _combination_ of the patch, but the bug they cause is > often an artifact of _one_ of the patches. > Wasn't talking about bugfixes, see above. > IOW, splitting the patches up makes them > - easier to merge > - easier to verify > - easier to debug > > and combining them has _zero_ advantages (whatever bug the combined patch > fix _will_ be fixed by the series of individual patches too - even if the > splitting was buggy in some respect, you are pretty much guaranteed of > this, since the bug you were trying to fix is the _one_ thing you are > really testing for). Lots of work to split up a patch though. > > See? > > Linus > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9qX3hDd4aOud5P8RAlMGAJ0cXEbY1QALk6EyfCNJDE26FdRYLQCdGOQB 799/tZxwWQkpv+a/eavf4EY= =GQR6 -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
