git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: "Eric S. Raymond" <esr@thyrsus.com>, git@vger.kernel.org
Subject: Re: RFC: Separate commit identification from Merkle hashing
Date: Thu, 23 May 2019 13:09:29 -0700	[thread overview]
Message-ID: <20190523200929.GA70860@google.com> (raw)
In-Reply-To: <86h89lq96v.fsf@gmail.com>

Hi,

Jakub Narebski wrote:

> I think Documentation/technical/hash-function-transition.txt misses
> considerations for fast-import format (it talks about problem with
> submodules, shallow clones, and currently not solved problem of
> translating notes; it does not talk about git-replace, either).

Hm, can you say more?  I think fast-import is not significantly
different from other tools that want to pick an appropriate object
format for input and an appropriate object format for output.

Do you mean that the fast-import file should have a field for
explicitly specifying the input object format, and that that doc
ought to call it out?

[...]
> For security, all references in Merkle-tree of hashes must use strong
> verification hash.  This means that you need to be able to refer to any
> object, including commit, by its verification hash name of its
> verification hash form (where all references inside object, like
> "parent" and "tree" headers in commit objects, use verification hashes).

This kind of crypto agility weakens any guarantees that rely on
strength of a hash function.  The security level would be that of the
weakest of the supported hash functions.

In other words, usually the benefit of supporting multiple hash
functions as a reader is that you want the strength of the strongest
of those hash functions and you need a migration path to get there.
If you don't have a way to eventually drop support for the weaker
hashes, then what benefit do you get from supporting multiple hash
functions?

Jonathan

  reply	other threads:[~2019-05-23 20:09 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
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 [this message]
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:
  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=20190523200929.GA70860@google.com \
    --to=jrnieder@gmail.com \
    --cc=esr@thyrsus.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@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).