5 ms·

Beware: Signing commits with SSH or GPG keys removes the "plausible deniability" [1][2]. Of course certain projects (especially if very critical or secure syst

Beware: Signing commits with SSH or GPG keys removes the "plausible deniability" [1][2]. Of course certain projects (especially if very critical or secure systems) definitely benefit from that but imagine you put your handwritten signature on every single step of your work (hint: you don't do that in the real World). You would never do so for normal internet activity like Google searches, Twitter or Facebook yet you want to sign your git commits with a signature undeniable connected to yourself, probably also connected to your real name. If you just think that signing is just a "cool feature to have" then you should really educate yourself about implications of having a connected (real name?) identity on the internet. [1] https://en.wikipedia.org/wiki/Plausible_deniability https://en.wikipedia.org/wiki/Plausible_deniability [2] https://legaldictionary.net/plausible-deniability/ https://legaldictionary.net/plausible-deniability/ P.S.: I just wanted to make people think before activating this feature. Most GitHub code and repositories worked perfectly without it. Do you really need it? When yes, why?

ehutch79 4y ago
Why wouldn't you want this? Committing code is not like browsing facebook, or searching on google. Even then, your name is on any posts you're making on twitter or facebook, and i'm sure google knows what you're searching. As a maintainer, why would you want people to be able to deny making a given commit? or have them come in completely anonymously?
- sodality2 4y ago
  Say you’re writing some code that may be illegal (piracy stream, rips off another API with licensed content, etc). I would want to deny that it was me (but then, i wouldn’t connect it to my real-life identity at all).
  - ducktective 4y ago
    It's that serious? Wouldn't the offended party just ask for the content/service/repo be removed?
    - sodality2 4y ago
      With the digital footprint these days, that might impede employment in the future in certain industries or sectors, especially if it’s tied to your name.
      - ducktective 4y ago
        >if it’s tied to your name How can this be proved? Even with signing, anyone can impersonate anyone.
        Volundr 4y ago
        The entire point of the signature is that it can't be forged. If a commit is signed with your private keys, I can reasonably conclude you authored it.
        heartbreak 4y ago
        I know this is a solved problem in certain contexts, but realistically how does a third party prove that your private keys are yours?
        dinkledunk 4y ago
        Because if you're signing your commits you're probably also the type of person to sign your email with the same key.
        palata 4y ago
        Adding a data point to your statistics: I sign commits and packages I maintain (when it applies), not my emails.
  - tekno45 4y ago
    is it not enough to sign it and burn the keys? PGP encrypted public messages is common even on the dark web.
  - fomine3 4y ago
    Obvious recent case is Tornado Cash.
- swatcoder 4y ago
  > As a maintainer, why would you want people to be able to deny making a given commit? or have them come in completely anonymously? 1. Because you trust code for what it is and are willing to trade attribution surety for a lesser ask of contributors 2. Because you care about certain principles of anonymity and non-repudiation and want to respect them in your own plainly legitimate project. 3. Because your project is or risks becoming illegitimate in some jurisdiction and you want to protect your contributors as best you can. It'd be nice if we can continue to respect these reasons as valid even while allowing other maintainers to exercise different policies.
  - ndhlms 4y ago
    I don't see that any of those reasons are relevant, in all honesty. 1. This is not even a moderate ask; using ssh for git transactions is no more or less burdensome than https 2. As has been pointed out, there is no reason or reliable way to verify the identity of a creator's SSH key 3. Real-world example of such a project, or why this matters in the context of (2)?
    - cmroanirgo 4y ago
      > there is no ...reliable way to verify the identity of a creator's SSH key GitHub exposes your public key via it's API. (Why? I have no idea. I call it a privacy violation) So, you need to create new github identity for every SSH identity that you wish to remain anonymous for, otherwise they just get tied together & one aspect of anonymity is lost.
      - ndhlms 4y ago
        All that does is associate an arbitrary SSH key with a GitHub account. There is still no reliable way to verify the identity of the GitHub account owner, or the SSH key that account holder generated. How does that expose any more information than you do by pushing a commit with a GitHub account?
- GauntletWizard 4y ago
  As a creator, it is sometimes advantageous for me to deny some of my own work. I regularly use "fixup" commits and rebase them out of existence. I'd be mildly embarrassed to have all of them sticking around in code forever. As a user of code published on Github, I sure as heck want there to be clear ownership and authorship of the code I use, and to be able to hold them accountable for malice. And there is lots malicious code on Github, trying to disguise itself as legit; Having a strong public persona isn't guarantee that my github code isn't malicious, but it does raise the stakes. As a human who has seen what happens when people commit mistakes, we're very emotionally bad at dealing with mistakes. "Who broke the vase?" is a tough question to ask. "Who broke the build" can carry the same weight - Both very little, and very much, depending on when it's asked and how expensive the vase was. I'd like to think that making mistakes will be easier in a merkle-tree structured world; That as a collective, we will learn to do a better job of helping people admit their mistakes, come forward with them, and say "I made that mistake, and have learned from it". The internet has proven that false again and again. In two important ways - People are unwilling to forgive, and people are unwilling to admit. Past minor mistakes haunt people forever all the time. Look at things like "Has Justine Landed Yet?"[1]. A malicious liar (We'll call them Eve) will deny, refute, and plain old lie in the face of whatever. There can be incredibly convincing evidence (A RSA-Key Verified Git Signature, for example) of... whatever, and it will be written off as "Harassment" by friends of Eve. Further: There's plenty of actual malice that passes itself off as not. Rapists say "She clearly wanted it, she got wet" - Criminals do that at all levels, making up excuses for why their victims deserved it. Regardless - It is a sea change to be held accountable for your code. I do want it, but I do not believe that SSH key verification will achieve that. I think it will be a significant change when it does happen, though, and one with significant consequences. [1]https://www.nytimes.com/2015/02/15/magazine/how-one-stupid-tweet-ruined-justine-saccos-life.html https://www.nytimes.com/2015/02/15/magazine/how-one-stupid-t...
  - jart 4y ago
    GitHub never deletes anything you push. Even if you rebase and force push, that old information is still accessible. Also why would you drag out such an ugly article to make a point?
tompt 4y ago
Also known as non-repudiation[1] and, as you point out, not something to be used without considering its consequences. https://en.wikipedia.org/wiki/Non-repudiation https://en.wikipedia.org/wiki/Non-repudiation
- blowski 4y ago
  What consequences? Something like "if you push to a repo that gets taken down for DCMA requests, you can't deny in court that you made the commit"?
- mirekrusin 4y ago
  You can't deny you authored commits even if somebody steals your private key?
a_t48 4y ago
There's nothing about this that stops you from having multiple identities. You can generate a unique key for a project or github account, and then only using that key for that purpose. This allows trust that "MarvinTheMartian" the maintainer of the "Q-36 Space Modulator" doesn't have false commits under their name (maybe important for their reputation!), while still giving the plausible deniability that "therealmarv" isn't developing cartoonish WMDs.
- therealmarv 4y ago
  This is definitely the way to go. I just wanted to highlight and warn that some people do not think their actions or new features 100% through their mind. Many/Most repos were also useful without the signing feature.
advisedwang 4y ago
It looks like this feature can be used with an pseudonym account that may be the way to go if this is a concern for you. Having your real name on the GitHub account but not having a commit sig is not really that strong deniability anyway. If your thinking about some situation where you are being legally hounded because of code (e.g. DMCA, tornado cash situation etc) they will subpoena your hardware and likely find enough evidence that you can't plausibly deny writing the code anyway. GitHub logs may show you the upload was with a SSH key or http auth associated with you anyway. For non legal situations, I suspect most observers won't really believe that a non-signed upload could have been done by someone else. Especially if it's to a repo only you have upload permission to or something.
R0b0t1 4y ago
> but imagine you put your handwritten signature on every single step of your work In most engineering or engineering adjacent fields you are doing this, btw. Yes, in software too.
zzyzxd 4y ago
> You would never do so for normal internet activity like Google searches, Twitter or Facebook Websites from Google search result are verified by my browser via HTTPS certs. On twitter or facebook, users usually trust the centralized authnz systems hosted by the platform to verify content ownership. But out of box, git allows you to use whatever name/email on your commit, so that's a problem. In my whole career, there were 3 times that I got questioned about "why did you introduce this line of code, which caused some production issue?" and turned out to be results of someone junior developer's rebase/amend or whatnot. I pointed out that I always sign my commits and those unsigned ones were not mine. Without signature I really could not tell whether I was the author or not, since some commits are months/years old. I believe those altered commits were honest mistakes without malicious intention, and our organization has blameless culture. But I still want to let my coworkers know that I am not the one who caused this problem. Signing commits helps a lot in these situations and clears misunderstanding, and I believe more or less impacted my performance review and bonus (my performance would probably not be as good if I had to own those incidents). CI/CD tools are getting better each day, a commit can mean a lot more than "a snapshot of the code base", like, it could have been a checkpoint of the state of the production environment (IaC, GitOps ... etc). You already have your name on the commit, so why not offer a way for others to verify you are really who you say you are? And I should probably clarify, that the identity of a git commit does not have to be linked to a human in real life. It's just a way to verify that a commit is really from author X and not Y.
- jart 4y ago
  > But out of box, git allows you to use whatever name/email on your commit, so that's a problem. Systems are typically unsecured until someone starts abusing it. GitHub has obviously foreseen this possibility which is why they have the infrastructure in place to restrict freedom in the interest of security. The day someone starts aggressively misusing that feature, they could take it away just like that.
deleted 4y ago
[deleted]

ehutch79 4y ago

Why wouldn't you want this? Committing code is not like browsing facebook, or searching on google. Even then, your name is on any posts you're making on twitter or facebook, and i'm sure google knows what you're searching. As a maintainer, why would you want people to be able to deny making a given commit? or have them come in completely anonymously?

sodality2 4y ago
Say you’re writing some code that may be illegal (piracy stream, rips off another API with licensed content, etc). I would want to deny that it was me (but then, i wouldn’t connect it to my real-life identity at all).
- ducktective 4y ago
  It's that serious? Wouldn't the offended party just ask for the content/service/repo be removed?
  - sodality2 4y ago
    With the digital footprint these days, that might impede employment in the future in certain industries or sectors, especially if it’s tied to your name.
    - ducktective 4y ago
      >if it’s tied to your name How can this be proved? Even with signing, anyone can impersonate anyone.
      - Volundr 4y ago
        The entire point of the signature is that it can't be forged. If a commit is signed with your private keys, I can reasonably conclude you authored it.
        heartbreak 4y ago
        I know this is a solved problem in certain contexts, but realistically how does a third party prove that your private keys are yours?
        dinkledunk 4y ago
        Because if you're signing your commits you're probably also the type of person to sign your email with the same key.
        palata 4y ago
        Adding a data point to your statistics: I sign commits and packages I maintain (when it applies), not my emails.
- tekno45 4y ago
  is it not enough to sign it and burn the keys? PGP encrypted public messages is common even on the dark web.
- fomine3 4y ago
  Obvious recent case is Tornado Cash.
swatcoder 4y ago
> As a maintainer, why would you want people to be able to deny making a given commit? or have them come in completely anonymously? 1. Because you trust code for what it is and are willing to trade attribution surety for a lesser ask of contributors 2. Because you care about certain principles of anonymity and non-repudiation and want to respect them in your own plainly legitimate project. 3. Because your project is or risks becoming illegitimate in some jurisdiction and you want to protect your contributors as best you can. It'd be nice if we can continue to respect these reasons as valid even while allowing other maintainers to exercise different policies.
- ndhlms 4y ago
  I don't see that any of those reasons are relevant, in all honesty. 1. This is not even a moderate ask; using ssh for git transactions is no more or less burdensome than https 2. As has been pointed out, there is no reason or reliable way to verify the identity of a creator's SSH key 3. Real-world example of such a project, or why this matters in the context of (2)?
  - cmroanirgo 4y ago
    > there is no ...reliable way to verify the identity of a creator's SSH key GitHub exposes your public key via it's API. (Why? I have no idea. I call it a privacy violation) So, you need to create new github identity for every SSH identity that you wish to remain anonymous for, otherwise they just get tied together & one aspect of anonymity is lost.
    - ndhlms 4y ago
      All that does is associate an arbitrary SSH key with a GitHub account. There is still no reliable way to verify the identity of the GitHub account owner, or the SSH key that account holder generated. How does that expose any more information than you do by pushing a commit with a GitHub account?
GauntletWizard 4y ago
As a creator, it is sometimes advantageous for me to deny some of my own work. I regularly use "fixup" commits and rebase them out of existence. I'd be mildly embarrassed to have all of them sticking around in code forever. As a user of code published on Github, I sure as heck want there to be clear ownership and authorship of the code I use, and to be able to hold them accountable for malice. And there is lots malicious code on Github, trying to disguise itself as legit; Having a strong public persona isn't guarantee that my github code isn't malicious, but it does raise the stakes. As a human who has seen what happens when people commit mistakes, we're very emotionally bad at dealing with mistakes. "Who broke the vase?" is a tough question to ask. "Who broke the build" can carry the same weight - Both very little, and very much, depending on when it's asked and how expensive the vase was. I'd like to think that making mistakes will be easier in a merkle-tree structured world; That as a collective, we will learn to do a better job of helping people admit their mistakes, come forward with them, and say "I made that mistake, and have learned from it". The internet has proven that false again and again. In two important ways - People are unwilling to forgive, and people are unwilling to admit. Past minor mistakes haunt people forever all the time. Look at things like "Has Justine Landed Yet?"[1]. A malicious liar (We'll call them Eve) will deny, refute, and plain old lie in the face of whatever. There can be incredibly convincing evidence (A RSA-Key Verified Git Signature, for example) of... whatever, and it will be written off as "Harassment" by friends of Eve. Further: There's plenty of actual malice that passes itself off as not. Rapists say "She clearly wanted it, she got wet" - Criminals do that at all levels, making up excuses for why their victims deserved it. Regardless - It is a sea change to be held accountable for your code. I do want it, but I do not believe that SSH key verification will achieve that. I think it will be a significant change when it does happen, though, and one with significant consequences. [1]https://www.nytimes.com/2015/02/15/magazine/how-one-stupid-tweet-ruined-justine-saccos-life.html https://www.nytimes.com/2015/02/15/magazine/how-one-stupid-t...
- jart 4y ago
  GitHub never deletes anything you push. Even if you rebase and force push, that old information is still accessible. Also why would you drag out such an ugly article to make a point?

tompt 4y ago

Also known as non-repudiation[1] and, as you point out, not something to be used without considering its consequences. https://en.wikipedia.org/wiki/Non-repudiation https://en.wikipedia.org/wiki/Non-repudiation

blowski 4y ago
What consequences? Something like "if you push to a repo that gets taken down for DCMA requests, you can't deny in court that you made the commit"?
mirekrusin 4y ago
You can't deny you authored commits even if somebody steals your private key?

a_t48 4y ago

There's nothing about this that stops you from having multiple identities. You can generate a unique key for a project or github account, and then only using that key for that purpose. This allows trust that "MarvinTheMartian" the maintainer of the "Q-36 Space Modulator" doesn't have false commits under their name (maybe important for their reputation!), while still giving the plausible deniability that "therealmarv" isn't developing cartoonish WMDs.

therealmarv 4y ago
This is definitely the way to go. I just wanted to highlight and warn that some people do not think their actions or new features 100% through their mind. Many/Most repos were also useful without the signing feature.

advisedwang 4y ago

It looks like this feature can be used with an pseudonym account that may be the way to go if this is a concern for you. Having your real name on the GitHub account but not having a commit sig is not really that strong deniability anyway. If your thinking about some situation where you are being legally hounded because of code (e.g. DMCA, tornado cash situation etc) they will subpoena your hardware and likely find enough evidence that you can't plausibly deny writing the code anyway. GitHub logs may show you the upload was with a SSH key or http auth associated with you anyway. For non legal situations, I suspect most observers won't really believe that a non-signed upload could have been done by someone else. Especially if it's to a repo only you have upload permission to or something.

R0b0t1 4y ago

> but imagine you put your handwritten signature on every single step of your work In most engineering or engineering adjacent fields you are doing this, btw. Yes, in software too.

zzyzxd 4y ago

> You would never do so for normal internet activity like Google searches, Twitter or Facebook Websites from Google search result are verified by my browser via HTTPS certs. On twitter or facebook, users usually trust the centralized authnz systems hosted by the platform to verify content ownership. But out of box, git allows you to use whatever name/email on your commit, so that's a problem. In my whole career, there were 3 times that I got questioned about "why did you introduce this line of code, which caused some production issue?" and turned out to be results of someone junior developer's rebase/amend or whatnot. I pointed out that I always sign my commits and those unsigned ones were not mine. Without signature I really could not tell whether I was the author or not, since some commits are months/years old. I believe those altered commits were honest mistakes without malicious intention, and our organization has blameless culture. But I still want to let my coworkers know that I am not the one who caused this problem. Signing commits helps a lot in these situations and clears misunderstanding, and I believe more or less impacted my performance review and bonus (my performance would probably not be as good if I had to own those incidents). CI/CD tools are getting better each day, a commit can mean a lot more than "a snapshot of the code base", like, it could have been a checkpoint of the state of the production environment (IaC, GitOps ... etc). You already have your name on the commit, so why not offer a way for others to verify you are really who you say you are? And I should probably clarify, that the identity of a git commit does not have to be linked to a human in real life. It's just a way to verify that a commit is really from author X and not Y.

jart 4y ago
> But out of box, git allows you to use whatever name/email on your commit, so that's a problem. Systems are typically unsecured until someone starts abusing it. GitHub has obviously foreseen this possibility which is why they have the infrastructure in place to restrict freedom in the interest of security. The day someone starts aggressively misusing that feature, they could take it away just like that.

deleted 4y ago

[deleted]