severity 813157 important
tags 813157 + upstream
quit
Hi Daniel,
Daniel Kahn Gillmor wrote:
> transfer.fsckobjects
> fetch.fsckobjects
> receive.fsckobjects
I'd love to turn the first of these on by default. It implies the other
two. I'll bring this up upstream.
> Many users of git rely on commit IDs for integrity proof that they're
> working from the same point in the repository held by other developers
> (i've certainly told people that they can do this) without knowing that
> one pull from a malicious repo could tamper with the contents of a
> freshly-received object without noticing.
Are you referring to the possibility of SHA-1 collisions between
corrupt objects and clean ones? I don't think anyone has produced
such a collision yet, but that's an interesting attack vector. I'm
also interested in figuring out how to move to a more futureproof
object naming scheme in Git (the simplest approach to this I've heard
discussed is
* extend git protocol to allow declaring a different hash function.
Objects are named according to that hash function.
* to switch hash functions for an existing repository:
- rebuild all objects using the new hash
- create a list mapping old object names (that used the old hash
function) to new object names (using the new hash)
- PGP-sign that list to avoid tampering and serve it. Clients can
then combine trusted lists to allow commands that refer to the
old object name to continue to work.
* regularly switch hash functions to the current best-practice hash
* refuse to clone repositories that use a sufficiently old hash
function without a --force option.
).
I think fsck-ing incoming objects has other useful security properties
in addition to the SHA-1 collision related problem you mentioned.
Objects that pass fsck are less likely to trigger bugs (both in git
itself and code that calls git). Git and callers are not *supposed*
to do bad things when faced with malformed objects but there hasn't
been enough work using fuzzing tools to rule out problems.
Thanks,
Jonathan
