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