Re: upstreaming https://github.com/cgwalters/git-evtag ?

From: Colin Walters <walters@verbum.org>
Date: Jan 9, 2018, 02:30 UTC
Message-ID: <1515465051.2895186.1228754952.0036D645@webmail.messagingengine.com>
In-Reply-To: <CAGZ79kZ8AXezcX1_5WJsUJMHiHCzj2B=Uj8+4K3VF+cC6mTCqA@mail.gmail.com>

On Mon, Jan 8, 2018, at 3:49 PM, Stefan Beller wrote:

Show 13 quoted lines

> On Mon, Jan 8, 2018 at 12:40 PM, Santiago Torres <santiago@nyu.edu> wrote:
> > Hi,
> >
> > I personally like the idea of git-evtags, but I feel that they could be
> > made so that push certificates (and being hash-algorithm agnostic)
> > should provide the same functionality with less code.
> >
> > To me, a git evtag is basically a signed tag + a data structure similar
> > to a push certificate embedded in it. I wonder if, with the current
> > tooling in git, this could be done as a custom command...
> 
> In that case, why not migrate Git to a new hash function instead
> of adding a very niche fixup?

Every day, for many years I find it maddening and really ridiculous that the Fedora package build process insists I provide it a tarball instead of being able to just fetch a signed git tag.

Now while I haven't fought the battle to teach Fedora to actually use this, I think I have a pretty strong argument that git-evtag very clearly fulfills the same role that a signed tarball does.

In particular, how a single checksum covers the entire source - no
hash tree involved.  The way that the evtag is "horizontal" across
the source while the git tree is "vertical" around history means
they're complementary.

> See Documentation/technical/hash-function-transition.txt
> for how to do it.

evtag took me a day or two to write initially and doesn't impose any requirements on users except a small additional bit of software.

In contrast, working on hash-function-transition.txt? That seems like it'd easily consume many person-months of work. And that plan only exists post-shatter.io, whereas git-evtag long predates both.

> Personally I'd dislike to include ev-tags as it might send a signal
> of "papering over sha1 issues instead of fixing it".

I don't agree. I think it's pretty clear that a hash function transition would be a huge amount of work - not least because of course there are now at least two widely used implementations of git in C, plus https://www.eclipse.org/jgit/ plus...

> push certificates are somewhat underdocumented, see the

Why not call them "git signed pushes"? Junio's post even says "the signed push".

And I just looked at this a little bit more but I'm not sure I see how this covers the same goal as evtags; it seems more about stopping someone from MITM my push to github.com, and not about ensuring integrity from someone pulling from github.com (and not wanting to fully trust github).