git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Herczeg Zsolt <zsolt94@gmail.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Git and SHA-1 security (again)
Date: Tue, 19 Jul 2016 17:31:59 +0200	[thread overview]
Message-ID: <CACsJy8CSUu=AemQ-7uxth_2M=ko_KDGsdObwYdiE=L4OMKcVZw@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1607190910370.3472@virtualbox>

On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> But we can recreate SHA-1 from the same content and verify GPG, right?
>> I know it's super expensive, but it feels safer to not carry SHA-1
>> around when it's not secure anymore (I recall something about
>> exploiting the weakest link when you have both sha1 and sha256 in the
>> object content). Rehashing would be done locally and is better
>> controlled.
>
> You could. But how would you determine whether to recreate the commit
> object from a SHA-1-ified version of the commit buffer? Fall back if the
> original did not match the signature?

Any repo would have a cut point when they move to sha256 (or whatever
new hash), if we can record this somewhere (e.g. as a tag or a bunch
of tags, or some dummy commits to mark the heads of the repo) then we
only verify gpg signatures _in_ the repository before this point.

> That would pose at least these two problems:
>
> 1. The point of a signature is trust. If all of a sudden the signature
> does not match what is supposedly signed, that trust is broken.
>
> 2. The point of going to a stronger hash is to increase the trust. If
> any developer could decide to sign the SHA-1-ified version of any future
> commit, and Git validating it, it would be even worse than not switching
> to a new hash: it would leave us open to collision attacks *and* pretend
> that we prevented such attacks.

GPG signatures are still valid on the old repo (we will keep old repos
around forever, I suppose). And because they sign on the "weak" hash,
sha1, at some point they will be broken (but until then we can still
regenerate sha1 and verify locally). When sha1 is broken, GPG
signatures of the past can't be trusted anymore.

If people care enough about the past, they should re-sign (at least
for tags). Commits can be re-signed by the person who does the
conversion. Yes you have to trust that person. Sort of a painful fresh
start, with hopefully better security.
-- 
Duy

  reply	other threads:[~2016-07-19 15:32 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-16 13:48 Git and SHA-1 security (again) Herczeg Zsolt
2016-07-16 20:13 ` brian m. carlson
2016-07-16 21:46   ` Herczeg Zsolt
2016-07-16 22:03     ` brian m. carlson
2016-07-17  8:01   ` Johannes Schindelin
2016-07-17 14:21     ` brian m. carlson
2016-07-17 15:19       ` Duy Nguyen
2016-07-17 15:42         ` brian m. carlson
2016-07-17 16:23           ` Theodore Ts'o
2016-07-17 22:04             ` brian m. carlson
     [not found]               ` <1468804249.2037.0@smtp.gmail.com>
2016-07-18  1:18                 ` Fwd: " Herczeg Zsolt
2016-07-18  7:12                 ` Johannes Schindelin
2016-07-18 15:09                   ` Herczeg Zsolt
2016-07-18 15:57                     ` Johannes Schindelin
2016-07-18 16:05                       ` Duy Nguyen
2016-07-19  7:18                         ` Johannes Schindelin
2016-07-19 15:31                           ` Duy Nguyen [this message]
2016-07-19 17:34                             ` David Lang
2016-07-19 17:43                               ` Duy Nguyen
2016-07-19 17:59                                 ` David Lang
2016-07-19 18:04                                   ` Duy Nguyen
2016-07-19 18:58                                     ` Herczeg Zsolt
2016-07-20 14:48                                       ` Duy Nguyen
2016-07-20 12:28                                     ` Johannes Schindelin
2016-07-20 14:44                                       ` Duy Nguyen
2016-07-20 17:10                                         ` Stefan Beller
2016-07-20 19:26                                           ` Junio C Hamano
2016-08-22 22:01                                         ` Philip Oakley
2016-07-18 16:12                       ` Herczeg Zsolt
2016-07-19  7:21                         ` Johannes Schindelin
2016-07-18 18:00               ` Junio C Hamano
2016-07-18 21:26                 ` Jonathan Nieder
2016-07-18 23:03                 ` brian m. carlson
2016-07-21 13:19                   ` Johannes Schindelin
2016-07-21 12:53                 ` Johannes Schindelin
2016-07-22 15:59                   ` Junio C Hamano
2016-07-18  7:00       ` Johannes Schindelin
2016-07-18 22:44         ` brian m. carlson
2016-07-21 14:13           ` Johannes Schindelin
2016-07-18 16:51       ` Duy Nguyen
2016-07-19  7:31         ` Johannes Schindelin
2016-07-19  7:46           ` David Lang
2016-07-19 16:07         ` Duy Nguyen
2016-07-19 17:06           ` Junio C Hamano
2016-07-19 17:27             ` Duy Nguyen
2016-07-19 18:46               ` Junio C Hamano
2016-07-18 16:51 ` Ævar Arnfjörð Bjarmason
2016-07-18 17:48   ` Herczeg Zsolt
2016-07-18 20:01     ` David Lang
2016-07-18 20:02     ` Ævar Arnfjörð Bjarmason
2016-07-18 20:55       ` Junio C Hamano
2016-07-18 21:28         ` Herczeg Zsolt

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to='CACsJy8CSUu=AemQ-7uxth_2M=ko_KDGsdObwYdiE=L4OMKcVZw@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    --cc=tytso@mit.edu \
    --cc=zsolt94@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).