From: Jeff King <peff@peff.net>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: Duy Nguyen <pclouds@gmail.com>,
Patrick Schleizer <patrick-mailinglists@whonix.org>,
Git Mailing List <git@vger.kernel.org>,
whonix-devel@whonix.org, mikegerwitz@gnu.org
Subject: Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?
Date: Mon, 24 Nov 2014 10:51:08 -0500 [thread overview]
Message-ID: <20141124155108.GC25912@peff.net> (raw)
In-Reply-To: <54730546.7000200@drmicha.warpmail.net>
On Mon, Nov 24, 2014 at 11:15:34AM +0100, Michael J Gruber wrote:
> > I wonder if we can have an option to sign all blob content of the tree
> > associated to a commit, and the content of parent commit(s). It's more
> > expensive than signing just commit/tag content. But it's also safer
> > without completely ditching SHA-1.
> >
>
> This amounts to hashing the blob content with whatever hash you told
> your gpg to use (hopefully not sha1 ;) ) and signing that.
Right. You could also create a graph of SHA-256 (or whatever) object
hashes and sign that. I.e., create a parallel to git's trees using
SHA-256 and include a single:
object-256 ....
line in the tag header. That still involves re-hashing all of the data,
but it would at least be possible to cache (i.e., a mapping of SHA-1 to
SHA-256 hashes). Of course one way to keep that caching layer up to date
would be to just calculate the SHA-256 along with the SHA-1 whenever we
create an object. And then you can sprinkle SHA-256 links in other
places, too, like commit objects.
And now you are halfway down the road to a combined SHA-1/SHA-256 git.
:)
The tricky thing is fitting the extra hash into the tree objects. And of
course the rules for actually generating and/or sending extra objects.
-Peff
next prev parent reply other threads:[~2014-11-24 15:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-16 15:31 How safe are signed git tags? Only as safe as SHA-1 or somehow safer? Patrick Schleizer
2014-11-17 21:26 ` 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 [this message]
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=20141124155108.GC25912@peff.net \
--to=peff@peff.net \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=mikegerwitz@gnu.org \
--cc=patrick-mailinglists@whonix.org \
--cc=pclouds@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.