mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Eric S. Raymond" <>
To: Jonathan Nieder <>
Subject: Re: RFC: Separate commit identification from Merkle hashing
Date: Mon, 20 May 2019 22:38:32 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Jonathan Nieder <>:
> Hi!
> Eric S. Raymond wrote:
> > One reason I am sure of this is the SHA-1 to whatever transition.
> > We can't count on the successor hash to survive attack forever.
> > Accordingly, git's design needs to be stable against the possibility
> > of having to accommodate multiple future hash algorithms in the
> > future.
> Have you read through Documentation/technical/hash-function-transition?  It
> takes the case where the new hash function is found to be weak into account.
> Hope that helps,
> Jonathan

Reading now...

At first sight I think it looks pretty compatible with what I am proposing.
The goals anyway, some of the implementation tactics would change a bit.

I think it's a weakness, though, that most of it is written as though it
assumes only one hash transition will be necessary.  (This is me thinking
on long timescales again.)

Instead of having a gpgsig-sha256 field, I would change the code so all
hash cookies have an delimited optional prefix giving the hash-algorithm
type, with an absent prefix interpreted as SHA-1.

I think the idea of mapping future hashes to SHA-1s, which are then
used as fs lookup keys, is sound.  The same technique (probably the
same code!) could be used to map the otherwise uninterpreted
commit-IDs I'm proposing to lookup keys.

I should have said in my previous mail that I'm prepared to put
my coding fingers into making all this happen. I am pretty sure my
gramty manager will approve.
		<a href="">Eric S. Raymond</a>

  reply	other threads:[~2019-05-21  2:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-21  1:32 RFC: Separate commit identification from Merkle hashing Eric S. Raymond
2019-05-21  1:57 ` Jonathan Nieder
2019-05-21  2:38   ` Eric S. Raymond [this message]
2019-05-21  2:58     ` Jonathan Nieder
2019-05-21  3:31       ` Eric S. Raymond
2019-05-23 19:09 ` Jakub Narebski
2019-05-23 20:09   ` Jonathan Nieder
2019-05-23 20:53     ` Eric S. Raymond
2019-05-23 20:50   ` Eric S. Raymond
2019-05-23 20:54     ` Jonathan Nieder
2019-05-23 21:19       ` Eric S. Raymond
2019-05-23 21:39         ` Randall S. Becker
2019-05-23 21:50       ` Ævar Arnfjörð Bjarmason

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:

  List information:

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

  git send-email \ \ \ \ \

* 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

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