Hi Jonathan--
On Fri 2016-01-29 20:22:18 -0500, Jonathan Nieder wrote:
> 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.
great, thanks.
>> 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?
No, i'm referring to the possibility of shipping an object that doesn't
have the claimed SHA-1 digest at all, and it being blindly accepted.
> 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
I'm interested in being able to move to a stronger cryptographic digest
for git (algorithmic agility is hard, though, esp. with stored data: be
careful! i like your rough outline) but i wouldn't want this fix to get
caught behind such a larger overhaul.
> 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.
right, agreed. For such a central tool, it really needs to be safe by
default.
--dkg
