Posted on twitter @ioerror @torproject @thegrugq @vlad902:
Some good news. With the Git 2.2 release we may be getting much strong Git tag verification:
* "git push" learned "--signed" push, that allows a push (i.e. request to update the refs on the other side to point at a new history, together with the transmission of necessary objects) to be signed, so that it can be verified and audited, using the GPG signature of the person who pushed, that the tips of branches at a public repository really point the commits the pusher wanted to, without having to "trust" the server.
I’ll use git push --signed as soon as it’s in Debian, at least in backports. It fixes a nice gap.
(This doesn’t solve the questions of this thread, though.)
(I am going to ask https://www.whonix.org/blog/git-verification-security on the git mailing list to get some more answers.)
Asked on the git mailing list:
We’re hosed. (Not a Whonix specific issue! Any project that relies on signed git tags (big parts of the Free Software world, if they’re not doing worse by not proving signed tags at all).
- Looks like signed git tags are only as safe as SHA-1 + […] for git cloners.
- They’re aware of the issue.
- Probably no one will be working on it anytime soon.
- They disagree on the security (weakness) of SHA-1.
- They’d welcome patches.
Source, asked on the git mailing list:
Signing, verifying git commits, especially when tagging a (release) commit might help a bit. All in all there is very little we can do on Whonix side to improve things.
Just now added to my ~/.gitconfig.
[commit] gpgsign = true
So all git commits by myself should be signed from now. (This requires a new git version than in Debian wheezy. The one from jessie works and can be fortunately be easily installed in wheezy.)
In future, I’ll do as Mike Gerwitz recommends, signed git tags will point to signed git commits.
For the build script / main repo (https://github.com/Whonix/Whonix), made a note here to remember pushing only git tags that point to signed git commits:
Added instructions for verification of git commits to build documentation template:
Sounds good. While this gives a good assurance that files in the Whonix project repo are contributed by you, is it the same for commits by other people too?
As long they don’t sign their commits, no.
Jason sometimes directly committed stuff to https://github.com/Whonix. (I’ll review that, since I have to stay on top of developments and because I cannot push before I fetch and merge anyhow.) So I’d have to add a useless commit on top if we wanted to create a release out of that git head.
For others who provide git branches in git forks such as troubadour with https://github.com/troubadoour/whonix-repository-wizard (unsigned git commits), I also review for non-maliciousness and security issues before merging. For example.
git diff troubadoour/master
And also check the log doesn’t contain anything crazy.
git log master..troubadoour/master
Just now did set “never use fast forward merging” option in git.
This will force to always make a merge commit. And that merge commit will be automatically signed by me.
But I don’t think we should force everyone who commits to gpg sign their commits. Wouldn’t be that useful for pseudonymous contributors. (Would still have some use for long term contributors.)
There are two things one can verify. The signed git tag. (“git tag -v 10.0.0.5.5-stable”) And the signed git commit.
- (Added the missing “–stable”.)
- And the more important change, fixed the signed commit verification command.
For example… Changed from…
“git rev-list --max-count 1 10.0.0.5.5-stable” outputs at which commit the 10.0.0.5.5-stable tag is pointing. That’s “21f040366a42c2d7454ff4affa6bcad9f36d8f57”.
“git log --show-signature -1 21f040366a42c2d7454ff4affa6bcad9f36d8f57” checks the signature of the commit.
Would appreciate others thinking through if this is fine.
How to verify a git commit at which a git tag is pointing?:
[quote=“Patrick, post:32, topic:513”]How to verify a git commit at which a git tag is pointing?:
Got a good suggestion.
Hey guys. Seems there is a workaround for the SHA1 problem (ref: git-evtag). Related to: Qubes issue “Cryptographically strong code signing”
git development mailing list question -
gpg verify git sub modules useful?:
Related to quote…
We have broken SHA-1 in practice.
Git developers having a lengthy discussion on
SHA1 collisions found:
Last time I checked the git devs were wrangling about which hash to replace SHA1 with. The obvious answer is BLAKE2 but they could have refused for some retarded reasons.