On 29 January 2016 at 19:15, Eric Myhre <ha...@exultant.us> wrote:

We briefly circulated questions about exactly how strong the integrity guarantees of git are today.  (These are good questions -- git is often presumed "secure", but at the same time, Linus has gone on the record explicitly disclaiming any such promises being part of the system's spec or priorities,

so, indeedy we should ask!)  Here's some notes:

Everyone (afaik) should consider adding the following snippet to their ~/.gitconfig:

```
# for $deity's sake, check that anything we're getting is complete and sane on a regular basis
[transfer]
        fsckobjects = true
[fetch]
        fsckobjects = true
[receive]
        fsckObjects = true
```

It seems git's default behavior in many situations is -- despite communicating objectID by content-addressable hashes which should be sufficient to assure some integrity -- it may not actually bother to *check* them.  Yes, even when receiving objects from other repos.  So, enabling these configuration parameters may "slow down" your git operations.  (Anecdotally, I'd say "no it bloody won't"; I've had them on for months now and pretty much forget they were there.)  The return is actually noticing if someone ships you a bogus object.  Everyone should enable these.

These fsck configs were discussed by the Git maintainers in 2013: http://git.661346.n2.nabble.com/propagating-repo-corruption-across-clone-td7580504.html  There's a great deal of detail about when checks are and are not performed there, if someone should want to read deeper.

Aside on length extension: At one point I did a skimming audit of the git serial structures to see if they were subject to length extension attacks.  If present, they would dramatically weaken the faith possible in SHA-1 in this application.  I tentatively attest that everything I saw in the hash tree was sorted, length prefixed, or null-terminated in such a way that I believed it immune to length extension.  (I say 'I attest' in a self-deprecating sense, natch; by all means refrain from trusting my audit.)

--
You received this message because you are subscribed to the Google Groups "binary-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to binary-transparency+unsubscribe@googlegroups.com.
To post to this group, send an email to binary-tr...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/binary-transparency/56ABBA5B.6020703%40exultant.us.

For more options, visit https://groups.google.com/d/optout.