Re: git-index-pack really does suck..

[Nicolas Pitre <nico@cam.org>]

On Tue, 3 Apr 2007, Linus Torvalds wrote:

> I don't care *what* it is conditional on, but your arguments suck. You 
> claim that it's not a normal case to already have the objects, when it 
> *is* a normal case for alternates, etc.
> 
> I don't understand why you argue against hard numbers. You have none of 
> your own.

Are hard numbers like 7% overhead (because right now that's all we have) 
really worth it against bad _perceptions_?

Sure, the SHA1 collision attack is paranoia.  But it is becoming 
increasingly *possible*.

And when we only had unpack-objects on the receiving end of a fetch, you 
yourself bragged about the implied security of GIT in the presence of a 
SHA1 collision attack.  Because let's admit it: when a SHA1 collision 
will happen it is way more probable to come on purpose than from pure 
accident.  But as you said at the time, it is not a problem because GIT 
trusts local objects more than remote ones and incidentally 
unpack-objects doesn't overwrite existing objects.

The keeping of fetched packs broke that presumption of trust towards 
local objects and it opened a real path for potential future attacks.  
Those attacks are still fairly theoretical of course.  But for how 
_long_?  Do we want GIT to be considered backdoor prone in a couple 
years from now just because we were obsessed by a 7% CPU overhead?

I think we have much more to gain by playing it safe and being more 
secure and paranoid than trying to squeeze some CPU cycles out of an 
operation that is likely to ever be bounded by network speed for most 
people.

And we _know_ that the operation can be optimized further anyway.

So IMHO in this case hard numbers alone aren't the end of it.  Not as 
long as they're reasonably low.  And especially not for a command which 
is 1) rather infrequent and 2) not really interactive like git-log might 
be.


Nicolas