Repository navigation
Use EVTag for release tags #7579
Description
Activity
- addedbuildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.
on Jul 7, 2016 cc @nodejs/release
cc @nodejs/collaborators
$ git secure-tag securetagtest You need a passphrase to unlock the secret key for user: "Rod Vagg <rod@vagg.org>" 2048-bit RSA key, ID 7D83545D, created 2013-11-18$ git secure-tag -v securetagtest gpg: Signature made Thu 07 Jul 2016 16:55:43 AEST using RSA key ID 7D83545D gpg: Good signature from "Rod Vagg <rod@vagg.org>" gpg: aka "Rod Vagg <r@va.gg>" Good Git-EVTag-v0-SHA512 hash$ git tag -v securetagtest object 95170bd48ede90e466a1fcef2dd623dfdae75c44 type commit tag securetagtest tagger Rod Vagg <rod@vagg.org> 1467874543 +1000 securetagtest Git-EVTag-v0-SHA512: 897a0d68e5be8100d37c9d7f8e75bd0c7f8b15d0cd1d4f2601d6632dc9a1e8816659034220028d53c6e8a546221e44280b6d3c8475012dc60b8114060445dd56 gpg: Signature made Thu 07 Jul 2016 16:55:43 AEST using RSA key ID 7D83545D gpg: Good signature from "Rod Vagg <rod@vagg.org>" gpg: aka "Rod Vagg <r@va.gg>"So entirely compatible with what we do now.
@indutny has this got traction anywhere else? How early would we be in the early-adopter phase of this technique? I like that it has version numbers in it but I can imagine there's some evolution of this still to come.
@rvagg I would say we are going to be very early adopters, good news is that (as you pointed out) this is completely compatible with default
git tag -v, so there is no risk. Additionally, I'd say that it can't lower the current security level in any way, since it just adds extra information to it. It should be pretty safe to do this as an experiment!@cgwalters sorry for summoning you, but perhaps you have some information about companies/projects that use EVTag?
Also cc @bnoordhuis
Hmmm, seems interesting.
@indutny Are signed commits similarly only signed with SHA-1?
@indutny Just a suggestion but perhaps you can add tests that verify it generates the same SHA-512 as git-evtag for the same input. It would be a shame if the tools output incompatible tags because of e.g. differences in iteration order.
@Fishrock123 yep, they are.
I think it's clear this functionality should move into the git upstream (and have an implementation in libgit2 after) - without that happening I think it's difficult to build momentum, though it might be interesting to see if a pure node implementation will help.
Mostly so far it's been my original project ostree, gnome-terminal and other random ones like libosinfo.
@cgwalters thank you! Added all of the projects to my evtag-compliance tests:
indutny/git-secure-tag@68a5087
cc @bnoordhuis
I think it's clear this functionality should move into the git upstream
I agree, FWIW.
(I wanted to bring that up in my first comment but I forgot.)
@bnoordhuis I can't agree more. Nevertheless, shipping it to a projects is the best way to make people consider merging it upstream.
Right, I'm not disagreeing with that.
@rvagg what should we do to move forward on this? Should it be documented for our release team?
Opened #7603, please continue the discussion there.
👍
- added a commit that references this issue
on Jul 23, 2016 - added a commit that references this issue
on Aug 5, 2016 - added a commit that references this issue
on Aug 10, 2016 - added a commit that references this issue
on Sep 9, 2016 - added a commit that references this issue
on Sep 28, 2016 - added a commit that references this issue
on Oct 18, 2016 - added a commit that references this issue
on Oct 26, 2016
By default, git provides very loose security guarantees of signed tags. Only the tip of SHA-1 Merkle tree is used, and thus overall security is bound above with the complexity of SHA-1 collision attack.
At this time, SHA-1 is considered insecure, so there is not too much point in generating signed tags as they are, since it may be possible to present different source with the same tag hash if SHA-1 collisions will be found.
However, instead of removing signatures altogether (which we shouldn't do, at least because of the green "Verified" badges on github), I suggest that we should give a try to:
https://github.com/indutny/git-secure-tag
This is a pretty simple tool that builds a Merkle tree too, but with a stronger SHA-512 digest. It is a JS-only implementation of https://github.com/cgwalters/git-evtag , but still quite a fast one: