Skip to content

Use EVTag for release tags #7579

Closed
Closed
Use EVTag for release tags#7579
Labels
buildIssues and PRs related to Node.js builds or CI infrastructure.

Description

@indutny
indutny
opened on Jul 7, 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:

$ time git secure-tag hash
4043b85fe605d3cb57c1b635801da18d2a521e382dd8f4f186decf0680d1b293b79e5366e38aa216e67a35cc9779bd7b0b0ec988874315e01d5c68931da1809a

real    0m3.127s
user    0m2.692s
sys 0m0.991s

Activity

  1. indutny
    added
    buildIssues and PRs related to Node.js builds or CI infrastructure.
    on Jul 7, 2016

  2. indutny commented on Jul 7, 2016

    @indutny
    indutny
    on Jul 7, 2016
    MemberAuthor

    cc @nodejs/release

  3. indutny commented on Jul 7, 2016

    @indutny
    indutny
    on Jul 7, 2016
    MemberAuthor

    cc @nodejs/collaborators

  4. rvagg commented on Jul 7, 2016

    @rvagg
    rvagg
    on Jul 7, 2016
    Member
    $ 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.

  5. indutny commented on Jul 7, 2016

    @indutny
    indutny
    on Jul 7, 2016
    MemberAuthor

    @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

  6. Fishrock123 commented on Jul 7, 2016

    @Fishrock123
    Fishrock123
    on Jul 7, 2016
    Contributor

    Hmmm, seems interesting.

    @indutny Are signed commits similarly only signed with SHA-1?

  7. bnoordhuis commented on Jul 7, 2016

    @bnoordhuis
    bnoordhuis
    on Jul 7, 2016
    Member

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

  8. indutny commented on Jul 7, 2016

    @indutny
    indutny
    on Jul 7, 2016
    MemberAuthor

    @Fishrock123 yep, they are.

    @bnoordhuis done indutny/git-secure-tag@92a6879

  9. cgwalters commented on Jul 7, 2016

    @cgwalters
    cgwalters
    on Jul 7, 2016

    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.

  10. indutny commented on Jul 7, 2016

    @indutny
    indutny
    on Jul 7, 2016
    MemberAuthor

    @cgwalters thank you! Added all of the projects to my evtag-compliance tests:

    indutny/git-secure-tag@68a5087

    cc @bnoordhuis

  11. bnoordhuis commented on Jul 7, 2016

    @bnoordhuis
    bnoordhuis
    on Jul 7, 2016
    Member

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

  12. indutny commented on Jul 7, 2016

    @indutny
    indutny
    on Jul 7, 2016
    MemberAuthor

    @bnoordhuis I can't agree more. Nevertheless, shipping it to a projects is the best way to make people consider merging it upstream.

  13. bnoordhuis commented on Jul 7, 2016

    @bnoordhuis
    bnoordhuis
    on Jul 7, 2016
    Member

    Right, I'm not disagreeing with that.

  14. indutny commented on Jul 7, 2016

    @indutny
    indutny
    on Jul 7, 2016
    MemberAuthor

    @rvagg what should we do to move forward on this? Should it be documented for our release team?

  15. rmg commented on Jul 7, 2016

    @rmg
    rmg
    on Jul 7, 2016
    Contributor

    @indutny @rvagg the response here seems pretty positive, albeit from a limited audience so far. I imagine a PR for adding it to the docs be the next step and might be better to do sooner rather than later so that the conversation moves/continues there instead of being split between here and there.

  16. indutny commented on Jul 8, 2016

    @indutny
    indutny
    on Jul 8, 2016
    MemberAuthor

    Opened #7603, please continue the discussion there.

  17. rvagg commented on Jul 8, 2016

    @rvagg
    rvagg
    on Jul 8, 2016
    Member

    👍

  18. rvagg
    closed this as completedon Jul 8, 2016
  19. indutny
    added a commit that references this issue on Jul 23, 2016

    doc: use `git-secure-tag` for release tags

    3b37d4b
  20. indutny
    added a commit that references this issue on Aug 5, 2016

    doc: use `git-secure-tag` for release tags

    0f3f76c
  21. cjihrig
    added a commit that references this issue on Aug 10, 2016

    doc: use `git-secure-tag` for release tags

    3d1a064
  22. MylesBorins
    added a commit that references this issue on Sep 9, 2016

    doc: use `git-secure-tag` for release tags

    bf33d2f
  23. MylesBorins
    added a commit that references this issue on Sep 28, 2016

    doc: use `git-secure-tag` for release tags

    23989b0
  24. rvagg
    added a commit that references this issue on Oct 18, 2016

    doc: use `git-secure-tag` for release tags

    652e7d6
  25. MylesBorins
    added a commit that references this issue on Oct 26, 2016

    doc: use `git-secure-tag` for release tags

    009df78
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    buildIssues and PRs related to Node.js builds or CI infrastructure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions