Re: Buffer overflows

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30.8.2007, at 23.46, Linus Torvalds wrote:

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.

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.

Attachment: PGP.sig
Description: This is a digitally signed message part


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux