From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>, Duy Nguyen <pclouds@gmail.com>
Cc: Joey Hess <id@joeyh.name>, GIT Mailing List <git@vger.kernel.org>
Subject: Re: weaning distributions off tarballs: extended verification of git tags
Date: Thu, 05 Mar 2015 13:36:27 +0100 [thread overview]
Message-ID: <54F84DCB.9000900@alum.mit.edu> (raw)
In-Reply-To: <xmqqsidn7ymg.fsf@gitster.dls.corp.google.com>
On 03/03/2015 12:44 AM, Junio C Hamano wrote:
> [...]
> I was about to suggest another alternative.
>
> Pretend as if Git internally used SHA-512 (or whatever hash you
> want to use) instead of SHA-1, compute the object names that
> way. Recompute the contents of a tree object is by replacing
> the 20-byte SHA-1 field in it with a field with whatever
> necessary length to hold the longer object names of elements in
> the tree.
>
> But then a realization hit me: what new value will be placed in the
> "parent " field in the commit object? You cannot have SHA-512
> variant of commit object name without recomputing the whole history.
>
> Now, if the final objective is to replace signature of tarballs,
> does it matter to cover the commit object, or is it sufficient to
> cover the tree contents?
The original goal was to replace a tarball signature, for which the
"alternative" that you described above seems quite elegant.
If the goal were really to certify the entire history, then none of the
proposals that I have seen so far is adequate anyway, because none of
them propose to include better than the original SHA-1s of the parent
commits.
Including other metadata from the release commit does not seem useful to
me; how valuable is it to know the author and commit message of the last
commit that happened to make it into a release? It would be more useful
to know the SHA-1 of that commit, but that would presumably be included
elsewhere in the packaging data used by the distribution.
> [...]
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
next prev parent reply other threads:[~2015-03-05 12:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-28 14:48 weaning distributions off tarballs: extended verification of git tags Colin Walters
2015-02-28 19:14 ` brian m. carlson
2015-02-28 20:34 ` Morten Welinder
2015-03-02 17:09 ` Colin Walters
2015-03-02 18:12 ` Joey Hess
2015-03-02 19:38 ` Sam Vilain
2015-03-02 20:08 ` Junio C Hamano
2015-03-02 20:52 ` Sam Vilain
2015-03-02 23:20 ` Duy Nguyen
2015-03-02 23:44 ` Junio C Hamano
2015-03-03 0:42 ` Duy Nguyen
2015-03-05 12:36 ` Michael Haggerty [this message]
2015-07-08 4:00 ` Colin Walters
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=54F84DCB.9000900@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=id@joeyh.name \
--cc=pclouds@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.
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.