Re: weaning distributions off tarballs: extended verification of git tags

From: Morten Welinder <mwelinder@gmail.com>
Date: Feb 28, 2015, 20:34 UTC
Message-ID: <CANv4PNmF9sTh8od9xT5tYTOF1Cv0Mev2Muf-qxQDS_6kE7EnOw@mail.gmail.com>
In-Reply-To: <1425134885.3150003.233627665.2E48E28B@webmail.messagingengine.com>

Is there a point to including a different checksum inside a git tag? If someone can break the SHA-1 checksum in the repository then the recorded SHA-256 checksum can be changed. In other words, wouldn't you be just as well off handing someone a SHA-1 commit id?

If you can guard the SHA-256 with a signature, you can do the same thing to the SHA-1. Or the tarball for that matter.

Unrelatedly, your assumptions:

Tar balls have too many degrees of freedom to rely on them being created identically in the future.

> - The assumption that this source has been run through some tests

A perfectly valid assumption for some build systems, notably autotools. "make distcheck" is the only way my tarballs get made and they only get made when the checks succeed. (If your point was that many projects have too few tests, well, then I agree.)

M.

On Sat, Feb 28, 2015 at 9:48 AM, Colin Walters <walters@verbum.org> wrote:

Show 31 quoted lines

> Hi,
>
> TL;DR: Let's define a standard for embedding stronger checksums in tags and commit messages:
> https://github.com/cgwalters/homegit/blob/master/bin/git-evtag
>
> I think tarballs should go away as a source distribution mechanism in favor of pure git.  I won't go into too many details of the "why" here (hopefully most of you agree!) but that's the background.
>
> Now, there are a few things that the classical tarball model provides:
>
> - Version numbers compatible with dpkg/rpm/etc
>   -> Do the same with your tag names, and use a well known scheme like "v$VERSION"
> - The assumption that this source has been run through some tests
>   -> Broken assumption, and regardless you want to rerun tests downstream
> - Hosting providers typically offer a strong checksum over the entire source
>   -> The topic of this post
>
> The above strawman code allows embedding the SHA256(git archive | tar).  Now,
> in order to make this work, the byte output of "git archive" must never change in the
> future.  I'm not sure how valid an assumption this is.  Timestamps are set to the
> commit timestamp, but I could imagine someone wanting to come along later
> and tweak the output to be compatible with some variant of tar or something.
>
> We could define the checksum to be over the stream of raw objects, sorted by their checksum,
> and that way be independent of archiving format variations.
>
> Is there agreement that something like this makes sense in the git core?  Does the
> concept make sense?  Does anything like this exist today?  Other thoughts/objections?
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html