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 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).
