On 30/08/2007, Timo Sirainen <tss@xxxxxx> wrote: > 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). > > > 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. You don't want a manual check to do these kinds of checks. Not only is it a huge job, you have the human factor: people make mistakes. This is (in part) what the review process is for, but understanding how to identify code that is safe from buffer overruns, integer overflows and the like is a complex task. Also, it may work on 32-bit which has been verified, but not on 64-bit. It would be far better to specify the rules on how to detect these issues into a static analysis tool and have that do the checking for you. Therefore, it is possible to detect when new problems have been added into the codebase. Does sparse support identifying these issues? > 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. Why is it easier? If you have a fixed-size buffer, why not use strncpy, which is what a safe string API is essentially doing anyway? In this case, detecting strcpy usage can be done via grep. This is quick, simple and easy to repeat. Other things are more complicated, which is where automated verification tools help. - Reece - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
