[SECURITY] Git General Verification + Verifying Whonix submodules

Development
21

Blog post:

22

Posted on twitter @ioerror @torproject @thegrugq @vlad902:

23

Some good news. With the Git 2.2 release we may be getting much strong Git tag verification:

http://lkml.iu.edu/hypermail/linux/kernel/1411.0/05384.html

* "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.
24

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 News - Whonix Forum on the git mailing list to get some more answers.)

25

Asked on the git mailing list:
http://www.mail-archive.com/git@vger.kernel.org/msg61087.html

26

One answer:
http://www.mail-archive.com/git@vger.kernel.org/msg61128.html

27

Summary:

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:
http://www.mail-archive.com/git@vger.kernel.org/msg61087.html

[hr]

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.

28

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:
Dev/Redistribution - Whonix

Added instructions for verification of git commits to build documentation template:
https://www.whonix.org/wiki/Template:Build_Documentation_Get_Source_Code#OpenPGP_Verify_the_Source_Code

29

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?

30

Good point.

As long they don’t sign their commits, no.

Jason sometimes directly committed stuff to Whonix · GitHub. (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 GitHub - 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.

git config --global --add merge.ff false

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

31

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.

Worked on https://www.whonix.org/wiki/Template:Build_Documentation_Get_Source_Code…

Changelog:

  • (Added the missing “–stable”.)
  • And the more important change, fixed the signed commit verification command.

Changed from…

git log --show-signature HEAD^..{{VersionNew}}

To…

git log --show-signature -1 "$(git rev-list --max-count 1 {{VersionNew}}-stable)"

For example… Changed from…

git log --show-signature HEAD^..10.0.0.5.5-stable

To.

git log --show-signature -1 "$(git rev-list --max-count 1 10.0.0.5.5-stable)"

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

32

How to verify a git commit at which a git tag is pointing?:

33

[quote=“Patrick, post:32, topic:513”]How to verify a git commit at which a git tag is pointing?:

Got a good suggestion.

git verify-commit 11.0.0.2.8-developers-only^{commit}
34

Hey guys. Seems there is a workaround for the SHA1 problem (ref: git-evtag). Related to: Qubes issue “Cryptographically strong code signing”

1 Like
35
36
37

git development mailing list question - gpg verify git sub modules useful?:

https://public-inbox.org/git/CAGZ79kav0yB=g5kwB68oHRxbd0mDJ5-gGTJSidSKkZ75gmT44Q@mail.gmail.com/T/#t

Related to quote…

We have broken SHA-1 in practice.

https://shattered.io/

Git developers having a lengthy discussion on SHA1 collisions found:

https://public-inbox.org/git/CA+55aFwjzbhYyFm_MqL=cDZZeKbSjqd-jSeb0yW_bJ_WQTzEpA@mail.gmail.com/T/#t

38

Please scrutinize.

39

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.

40

Looks like git implemented sha256.

But can you find instructions on how to use git with sha256 or how to migrate existing git repositories to sha256?