I’m curious to hear what the Lemmy programming community thinks of this!


  • The author argues against signing Git commits, stating that it adds unnecessary complexity to systems.
  • The author believes that signing commits perpetuates an engineering culture of blindly adopting complex tools.
  • The consequences of signing Git commits are likely to be subtle and not as dramatic as some may believe.

Archive link: https://archive.ph/vjDeK

  • Eager Eagle@lemmy.world
    link
    fedilink
    English
    arrow-up
    13
    arrow-down
    2
    ·
    9 months ago

    I think the author balloons gpg signing into a problem and overlooks the impersonation aspect the signatures try to mitigate. Out of the cons listed:

    Unknown, possibly unlimited future liability for the consequences of running code in a commit you signed

    I don’t see how proof of commit authorship would change the warranties a piece of software is supposed to deliver. Sure it’ll make the untruthful claim of non-authorship harder (i.e. “I didn’t write this” when they in fact did); on the flipside, the signature would also protect the author from an impersonation attempt of a malicious/deceiving piece of code. Either way, I wouldn’t worry much about it.

    Further implicitly cementing GitHub as a centralized trust authority in the open source world

    This doesn’t hold. Commit signature is a feature of git itself, even though the article chooses to focus on GitHub. And afaik github integration of signatures doesn’t break code hosting elsewhere, GH merely allows you to register your GPG signature with them so they’re able to validate the commits, but the author is still able to enroll the same GPG key to other hosts.

    Introducing unknown reliability problems into infrastructure that relies on commit signatures

    Not sure what they mean by this. If your infra is set up to require signature, they might have valid concerns about impersonation and/or operate in a regulated environment.

    Temporary breach of your GitHub credentials now lead to potentially permanent consequences if someone can smuggle a new trusted key in there.

    This is a temporary problem, not permanent. After the breach the genuine author can go to the settings and delete the compromised key. Commits signed with a deleted key fallback to an unverified status.

    New kinds of ongoing process overhead as commit-signing keys become new permanent load-bearing infrastructure, like “what do I do with expired keys”, “how often should I rotate these”, and so on.

    Same with SSH keys, security is often a trade-off with convenience.

    • cadekat@pawb.social
      link
      fedilink
      arrow-up
      5
      ·
      9 months ago

      This doesn’t hold. Commit signature is a feature of git itself, even though the article chooses to focus on GitHub. And afaik github integration of signatures doesn’t break code hosting elsewhere, GH merely allows you to register your GPG signature with them so they’re able to validate the commits, but the author is still able to enroll the same GPG key to other hosts.

      Not only that, but GitHub rewrites signatures on rebase (and sometimes on fast forward merge) with their own private key. Using signatures on GitHub is basically pointless.

      • Eager Eagle@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        9 months ago

        true, that happens to me all the time

        edit: I think they just rewrite the commit without signing it, not with their private key. Either way, the first signature is lost on rebasing.