git integrity

[Eric Myhre]

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.)

[Daniel Kahn Gillmor]

On Fri 2016-01-29 14:15:39 -0500, Eric Myhre 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
> ```

interestingly, these settings cause a failure when cloning
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware
as noted in https://bugs.debian.org/743227

If anywhere was a place to look for evidence of binary tampering, i'd
expect repos of firmware blobs to be a spot to look. so, yikes.

I'm going to push for this these settings to be the default in debian.

--dkg

[Paul Tagliamonte]

Agree. I just set it in my local config and ran `git fsck --full` on my repos. Let me know if I can help push it in Debian, dkg

  Paul

--
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-transpar...@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/87k2ms7yog.fsf%40alice.fifthhorseman.net.

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

--

:wq

[Daniel Kahn Gillmor]

On Fri 2016-01-29 18:29:56 -0500, Paul Tagliamonte wrote:
> Agree. I just set it in my local config and ran `git fsck --full` on my
> repos. Let me know if I can help push it in Debian, dkg

If you're interested in following up on this in Debian, i think
https://bugs.debian.org/813157 is the place to do it.

thanks,

--dkg

[Ben Laurie]

Thanks for this...

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,

Do you have a link to that?

 

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-transpar...@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.

[Eric Myhre]

Sweeeet.

I agree with the comment therein that setting `transfer.fsckobjects` alone should be enough. (I didn't recheck my reasoning for having all three in my dotfiles before posting; I guess setting all three is just my style of personal defense-in-depth against future upstream slippage of config semantic changes, and might not be reasonable debian policy :))

On 01/31/2016 05:18 AM, Ben Laurie wrote:
>
> 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,
>
>
> Do you have a link to that?
>

'Fraid I can't remember the primary source I was originally recollecting and haven't successfully trawled my own browser history, though wikipedia quoth something not dissimilar: "the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check." [ https://en.wikipedia.org/w/index.php?title=SHA-1&oldid=702459941#cite_ref-15 ]