Re: upstreaming https://github.com/cgwalters/git-evtag ?
- Date: Mon, 08 Jan 2018 21:30:51 -0500
- From: Colin Walters <walters@xxxxxxxxxx>
- Subject: Re: upstreaming https://github.com/cgwalters/git-evtag ?
On Mon, Jan 8, 2018, at 3:49 PM, Stefan Beller wrote:
> On Mon, Jan 8, 2018 at 12:40 PM, Santiago Torres <santiago@xxxxxxx> 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
> 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).