git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Schleizer <patrick-mailinglists@whonix.org>
To: git@vger.kernel.org, whonix-devel@whonix.org
Cc: mikegerwitz@gnu.org
Subject: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?
Date: Sun, 16 Nov 2014 15:31:10 +0000	[thread overview]
Message-ID: <5468C33E.2080108@whonix.org> (raw)

Hi!

How safe are signed git tags? Especially because git uses SHA-1. There
is contradictory information around.

So if one verifies a git tag (`git tag -v tagname`), then `checksout`s
the tag, and checks that `git status` reports no untracked/modified
files, without further manually auditing the code, how secure is this
actually? Is it only as safe as SHA-1?

Let's assume an adversary, that is capable of producing SHA-1 collisions.

Linus Torvalds said: [1]

> Git uses SHA-1 not for security

And goes on.

> The security parts are elsewhere

Could you please elaborate on this? Where are the security parts? Can
you please briefly explain how these work? Where can I read more about this?

Wikipedia says. [2]

> Nonetheless, without second preimage resistance [3] of SHA-1 signed
commits and tags would no longer secure the state of the repository as
they only sign the root of a Merkle tree [4].

Which contradicts what Linus Torvalds said. What does that mean for
security? Which statement is true?

> "The source control management system Git uses SHA-1 not for security
but for ensuring that the data has not changed due to accidental
corruption. Linus Torvalds has said, "If you have disk corruption, if
you have DRAM corruption, if you have any kind of problems at all, Git
will notice them. It's not a question of if, it's a guarantee. You can
have people who try to be malicious. They won't succeed. [...] Nobody
has been able to break SHA-1, but the point is the SHA-1, as far as Git
is concerned, isn't even a security feature. It's purely a consistency
check. The security parts are elsewhere, so a lot of people assume that
since Git uses SHA-1 and SHA-1 is used for cryptographically secure
stuff, they think that, OK, it's a huge security feature. It has nothing
at all to do with security, it's just the best hash you can get. [...] I
guarantee you, if you put your data in Git, you can trust the fact that
five years later, after it was converted from your hard disk to DVD to
whatever new technology and you copied it along, five years later you
can verify that the data you get back out is the exact same data you put
in. [...] One of the reasons I care is for the kernel, we had a break in
on one of the BitKeeper sites where people tried to corrupt the kernel
source code repositories." [6]

If (!) I understand Mike Gerwitz ([...] GNU [...]) 's opinion, his
opinion is, that for best security each and every commit should be
signed for best possible git verification security.

See also:

- Mike Gerwitz's "A Git Horror Story: Repository Integrity With Signed
Commits" [7]

- Verbose reply by Mike Gerwitz to my question. [8]

- Similar question on security stackexchange. [9] Quote: "Nevertheless,
If somebody managed to find a way how to find SHA1 collisions easily,
then git would have much bigger problem."

Cheers,
Patrick

[1] https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s
[2] https://en.wikipedia.org/wiki/SHA-1#Data_integrity
[3] https://en.wikipedia.org/wiki/Second_preimage_resistance
[4] https://en.wikipedia.org/wiki/Merkle_tree
[5] https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s
[6] https://en.wikipedia.org/wiki/SHA-1#Data_integrity
[7] http://mikegerwitz.com/papers/git-horror-story
[8] https://www.whonix.org/forum/index.php/topic,538.msg4278.html#msg4278
[9]
https://security.stackexchange.com/questions/67920/how-safe-are-signed-git-tags-only-as-safe-as-sha-1-or-somehow-safer

             reply	other threads:[~2014-11-16 15:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-16 15:31 Patrick Schleizer [this message]
2014-11-17 21:26 ` How safe are signed git tags? Only as safe as SHA-1 or somehow safer? Jeff King
2014-11-21 23:01   ` Patrick Schleizer
2014-11-21 23:32     ` Jason Pyeron
2014-11-22 19:48       ` Jeff King
2014-11-22 19:43     ` Jeff King
2014-11-25 12:59     ` Fedor Brunner
2014-11-24  1:23   ` Duy Nguyen
2014-11-24 10:15     ` Michael J Gruber
2014-11-24 11:44       ` Duy Nguyen
2014-11-25 10:41         ` Duy Nguyen
2014-11-24 15:51       ` Jeff King
2014-11-24 18:14   ` Nico Williams
2014-11-25  1:16     ` Duy Nguyen
2014-11-25  1:23       ` Jonathan Nieder
2014-11-25  1:52         ` Duy Nguyen
2014-11-25  3:40           ` Stefan Beller
2014-11-25  3:47           ` Jeff King
2014-11-25 10:55             ` Duy Nguyen
2014-11-25 17:23             ` Junio C Hamano
2014-11-25 11:07       ` brian m. carlson
  -- strict thread matches above, loose matches on Subject: below --
2014-11-24  0:52 bancfc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5468C33E.2080108@whonix.org \
    --to=patrick-mailinglists@whonix.org \
    --cc=git@vger.kernel.org \
    --cc=mikegerwitz@gnu.org \
    --cc=whonix-devel@whonix.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).