Hi, Jonathan Nieder wrote: > Ramkumar Ramachandra wrote: >> Jonathan Nieder wrote: >>> Ramkumar Ramachandra wrote: > >>>> [...] >>>> While at it, also fix a bug: currently, we use a commit-id-shaped >>>> buffer to store the word after "pick" in '.git/sequencer/todo'. This >>>> is both wasteful and wrong because it places an artificial limit on >>>> the line length. Eliminate the need for the buffer altogether, and >>>> add a test demonstrating this. >>> >>> Reading the above does not make it at all obvious that I should want >>> to apply this patch because otherwise my prankster friend can cause my >>> copy of git to crash or run arbitrary code by putting a long commit >> >> Working backwards: >> get_sha1() is what will finally misbehave: how? > > Not sure what you're talking about. I was saying that any commit that > goes from "git can segfault in such-and-such circumstance" to "git no > longer segfaults in that circumstance" should loudly proclaim so! That's what I'm confused about: how can I make git misbehave (let alone segfault) after applying this commit? In the previous message, I was trying to work backwards to figure that out -- I clearly didn't get anywhere. In other words: what happens if an overly long (a length that doesn't fit into a size_t) line is present? How does strchrnul() behave? How do we work around this without imposing some kind of artificial hard limit? Thanks. -- Ram -- 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