[peff]

A few important points that aren't mentioned in the post:

- you have to tell git to use submodules for this to trigger (so `clone --recurse-submodules` or a manual `git submodule update --init`)

- credit for discovery goes to Etienne Stalmans, who reported it to GitHub's bug bounty program

- most major hosters should prevent malicious repositories from being pushed up. This is actually where most of the work went. The fix itself was pretty trivial, but detection during push required a lot of refactoring. And involved many projects: I wrote the patches for Git itself, but others worked on libgit2, JGit, and VSTS.

[avar]

Another thing not mentioned in the post, although admittedly more obscure, is that a 2.17.1 client will still happily ferry the evil objects along in its default configuration. I.e. in this sort of setup:

    unpatched hosting site ->
    in house (patched) v2.17.1 --bare mirror ->
    unpatched client

The transfer.fsckObjects setting needs to be explicitly turned on for the in-house mirror so that it doesn't collude in passing the bad objects along from the unpatched hosting site.

The protection in v2.17.1 only gets enabled by default if you're checking out a repository yourself, not if you're merely fetching and re-serving git objects[1].

Turning on receive.fsckObjects as the official v2.17.1 release notes suggest is not sufficient to protect against this attack. It needs to be transfer.fsckObjects, which also turns on fetch.fsckObjects, which is what's needed here.

1. https://public-inbox.org/git/20180529211950.26896-1-avarab@g...

[ethomson]

Thanks, peff, for the feedback. I pushed some changes to try to clarify that this does indeed require `clone --recursive`, and I added a note to credit Etienne Stalsman explicitly. That was an oversight in my haste.

[peff]

No problem! Thanks for all your work on this.

I should have clarified above, too: there were folks from GitHub, Microsoft, and Google working on the various fixes.

[ethomson]

The Git community is great because even though many of the interested parties compete with each other in some form or another, we always put that aside. And that's especially true for security issues.

[lpage]

For anyone else interested: https://git.kernel.org/pub/scm/git/git.git/commit/?id=7913f5...