> > 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. I agree that, in nature it shouldn't be difficult, but I also think that things usually take longer when you try to minimize code reuse and streamline the system's design. > 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. I think this is partly true. A hash transition has been brought up multiple times pre-shattered. In my opinion shattered was a much-needed PR push for SHA1 deprecation. In practice, things changed very little. > > 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... I agree with Stefan here. I think it's better in the long-term to push for hash-agnosticity. I don't know if git-evtag is hash agnostic, but if it is not, then we have two transition plans to think about. > > > push certificates are somewhat underdocumented, see the > > Why not call them "git signed pushes"? Junio's post > even says "the signed push". A signed push creates a push certificate. > > 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; Correct me if I'm wrong (it's been a couple of years) but last time I read about git evtags, they basically did the following: 1. Create a signed tag. 2. Create a signed statement of all the references. 3. Create a checksum of the checked out code on the tag. 4. Create a tarball of it. I think 1) is already happening, 2) is very similar information to the one contained in a push certificate. I don't know how necessary are 3) and 4), but that's just my very opinionated take on it. Full disclosure, I published a "competing" solution a couple of years ago[1] but, in my personal opinion, I think push certificates can achieve the same security guarantees as my system with very little changes. Cheers! -Santiago. [1] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias
Attachment:
signature.asc
Description: PGP signature
