Re: Buffer overflows
- From
- Timo Sirainen <tss@iki.fi>
- Date
- Aug 30, 2007, 21:08 UTC
- Message-ID
- <7D84F3C7-129D-4197-AAF1-46298E5D0136@iki.fi>
- In-Reply-To
- <alpine.LFD.0.999.0708301340470.25853@woody.linux-foundation.org>
On 30.8.2007, at 23.46, Linus Torvalds wrote:
Show 9 quoted lines
> On Thu, 30 Aug 2007, Timo Sirainen wrote: >> >> Looks like nothing has happened since my last mail about this >> (http://marc.info/?l=git&m=117962988804430&w=2). > > Perhaps because your patch was using a totally nonstandard and slow > interface, and had nasty string declaration issues, as people even > pointed > out to you.
Slow?
> If you were to send in a patch that simply just fixed some random case > without introducing the other stuff in forms that nobody is used to, > people would probably react more.
The problem is that the git code is full of these random cases. It's simply a huge job to even try to verify the correctness of it. Even if someone did that and fixed all the problems, tomorrow there would be new ones because noone bothers to even try to avoid them. So there really isn't any point in trying to make git secure until the coding style changes.
The code should be easy to verify to be secure, and with some kind of a safe string API it's a lot easier than trying to figure out corner cases where strcpy() calls break.
Show 11 quoted lines
> Especially since: > >> I sure hope no-one's using git-mailinfo to do any kind of >> automated mail >> processing from untrusted users. > > Obviously nobody would do that. Not because of any email buffer > overflows, > but because people wouldn't want to apply untrusted patches in the > first > place!
And anyone who uses git-mailinfo for anything else than manually applying trusted patches to their own tree deserve what they get, I suppose? For example if I decided to use it to automatically extract patches and their descriptions out of received emails and put them in a queue somewhere where I could look at them more easily.