5 ms·

I don’t think you should sign your Git commits

15 points by BerislavLopac 3y ago

nailer 3y ago
This is weak. Making commits more meaningful does not mean we need to handle the history of previous unsigned commits as the article asserts. You would simply enact a policy that says from this day, all future commits must be signed in order to prevent future identity theft. Yes, bad people may have snuck bad code into your repo in the past. it does not follow that it is unworthy to prevent bad code entering the repo in future
- deleted 3y ago
  [deleted]
- avgcorrection 3y ago
  Why are you afraid of identity theft in this context?
  - nailer 3y ago
    If someone has your private key, they can act as you online.
    - avgcorrection 3y ago
      The private key that I would hypothetically sign commits with? Then signing commits is compromised too. I’m not sure what point you’re making. On the other hand if I don’t sign my commits then any signed commits (from my stolen private key (SSH)) look out of place. Like it’s weird that all these malicious commits are also signed, even though I have never signed commits.
      - nailer 3y ago
        > The private key that I would hypothetically sign commits with? Yes. If someone has your private key they can sign commits as you. I’m not sure how I can put this more plainly.
ZiiS 3y ago
This falsely assumes signing and trust is somehow tied to GitHub. GPGs web of trust has issues but it allows verifying outside GitHub.
- kohbo 3y ago
  You're right, but also, commit signing is useless if there’s nobody on the other side verifying that the signature can be trusted. GitHub is doing that right now but that also ties projects to GitHub. It's Microsoft's way off ensuring OSS development has to go through their gates.
  - ZiiS 3y ago
    You can `git verify-commit` yourself. Gpg allows you to build a web of trust so you can find other people who trusts the commiter's key.
mytailorisrich 3y ago
I can understand signing patches sent over email. But for commits in any decent organisation one has to log in the network, have access rights to git, go through code review, and then, finally, you have code committed into the repo. In these cases signing commits does not add much, if anything.
- sverhagen 3y ago
  Aren't access credentials for Git entirely separate from the name and email address in the commit? You can commit with anyone's name and email address. Verifying a commit through the user's log in, I wouldn't know how to do, but their commit being verified gives me trust that it was committed by the person whose name is on the commit.
  - mytailorisrich 3y ago
    My point is that what you describe will be detected even before the commit reaches the master repo with the culprit fired as long as you have sensible processes. That's why I don't think commit signing adds anything within organisations. It might be a bit different with public open source repos on services like Github though I don't know how how to verify signatures...
- avgcorrection 3y ago
  It doesn’t seem hard to attribute 1/5 commit in a PR to another person. Then you publish it, no one checks out the individual commits (because that’s how forges are like in my experience), and it gets merged because the 2,000 line diff “LGTM”. I don’t really have belief in the processes of these corporate environment unless the auditing is given on a silver platter. Meanwhile on email: people get an email per patch, where the commit message part has to contain a `From:` line in order to override the email-is-author behavior. PS: There is a utility to giving commit authorship to someone else. Someone sends me the change through a DM. I commit it. Did I author it? No, so I give that to them. Not an exotic use-case at all of this seemingly nefarious feature.
pooper 3y ago
I, too, used to be scared of my "middle school permanent record" except just last week, I witnessed at $work a decision being reached to let old history stay in TFS and only import the current (head if you will) in git with no history at all. I am not saying don't worry about the future or that the future doesn't matter. For most situations, git history won't matter. There is no such thing as a permanent record, not one that most people will care about anyway. Here is my reason for why we don't need commit signing — the commit must stand on its own. Either you understand the change and approve of it, regardless of whether it was signed by Linus Torvalds or Kim Il Sun, or you don't. If you don't understand the change (or the code base) and the code base is important enough for you to go looking for a signature, chances are you should be paranoid if someone got into Linus's computer and stole his private keys. Tl;Dr don't think too much about git signing. Do what makes you happy but know it doesn't matter either way.
- ZiiS 3y ago
  I rely on Linux being secure in ways I cannot personally verify. Partly because my understanding is not deep enough but mainly beacause I don't have the huge amout of time to invest. I use thousands of pieces of very complex software (just to write this message if nothing else). The fact that Linus is prepared to stake his reputation on signing it and that reputation has been build from thousands of people being able to review his work is extreemly important to me.
  - pooper 3y ago
    If you're not looking at individual changesets/commits, how does a git signature affect you?
    - ZiiS 3y ago
      If I am reviewing a fork I can review the changes since a commit with a trusted siganture.
ZiiS 3y ago
Changes are not an issue. If a maintainer says all future commits will be signed then that is fully verifiable. The fact that older commits arn't in no way effects the trust
politelemon 3y ago
The analogies used do not work but are strongly being used as a foundation for the rest of their arguments, so the entire reasoning feels weak and misguided. No, we don't sign things with keys in real life, the same words being used in two different spheres of life do not make one 'false'. The HTTPS one is more of a rabbit hole of misunderstanding — trying to draw similarities with https and git signing is probably the root of the problem here. I'd suggest considering it on its own merit, and trying to understand why git commit signing was introduced, and what you would use it for given the cases. Also worth noting that some of the info is wrong, Github is not the root of trust, and also aren't the only one who encourage it; Gitlab have a similar guide and badge FWIW.
- MattPalmer1086 3y ago
  This is an example of someone with limited understanding drawing broad and unsubstantiated conclusions, as you say, using poor analogies. In general, when there's a thing that doesn't make sense to you and in which you are not expert, your first reaction should not be "everyone else is stoopid", but rather "what am I missing here?"
yoavm 3y ago
https://github.com/jayphelps/git-blame-someone-else https://github.com/jayphelps/git-blame-someone-else is a pretty good reason to sign your commits
- avgcorrection 3y ago
  I am also able to pee in my office mate’s coffee cup. What should we do to mitigate that threat model?
  - Daviey 3y ago
    You've described the action, now let's work out the risk. If you can describe the impact and likelihood we can talk about controls.
klabb3 3y ago
A lot of statements but with an important convoluted point: git signing happens with a public key that nobody knows how to verify properly. So should we sign them today, without being able to verify yet? Well, that isn’t 100% true. GitHub knows. But relying on GitHub is a good reason to not use the feature at all, imo. A bit stallmanesque perhaps? Maybe. I have absolutely no idea about your ssh keys, which goes back to decentralized self-sovereign identity being an unsolved problem (socially and administratively, not technically). Add commit signing to the giant list of use cases, I guess.
- fmajid 3y ago
  It’s not a GitHub feature, it’s a git one. The question is, how do you manage your web of trust in a distributed environment? Users set up the keys they trust for signatures using GitHub’s admin UI. GitHub exposes public keys via https://api.github.com/users/fazalmajid/keys https://api.github.com/users/fazalmajid/keys but it doesn’t tell you which keys are access and which are signing. There is also no way to see what the list was at a specific point in time, e.g. when the commit was signed. The second question is how do you ensure key revocation, which is a hard problem involving verified timestamps. If you are in a closed environment like proprietary software development you can and should build their own PKI, but in an open open-source workflow the author has a point, these last-mile issues make signed commits incomplete for trust purposes.
  - klabb3 3y ago
    > It’s not a GitHub feature, it’s a git one. Yes, I know. That’s part of my answer. The point is that signing is a ritualistic useless dance if there’s nobody on the other side verifying that the signature belongs to someone (ie trusts it). > Users set up the keys they trust for signatures using GitHub’s admin UI. Yeah, that’s fine. But that’s between me and GitHub. > GitHub exposes public keys[…] Exactly. I agree with your points about security. But even so, it’s still a proprietary system relying on centralized identity. It ties projects to GitHub, and offloads trust to them. This is not git anymore - it’s the same as signing in with Yahoo or WeChat. It’s a way for Microsoft to put themselves on the critical path for virtually all today’s OSS dev. > If you are in a closed environment like proprietary software development you can and should build their own PKI I don’t know about this. Operate PKI? Maybe. Build? Aside from dedicated expert teams at mega-corps, no thanks. PKI is closely related to the decentralized identity problem - which is what I really hope we will solve. We really, really need it.
avgcorrection 3y ago
Completely correct that you should have a reason for signing something which goes beyond the vacuous “why not”. In my own work, the surrounding context is sufficient verification. By the way: patch attestation [1] is perhaps somewhat related. Pretty well-thought out techniques for verifying that patches sent via email. [1] https://lwn.net/Articles/813646/ https://lwn.net/Articles/813646/
seba_dos1 3y ago
> With signed commits, you are saying something permanently, but you don’t really know what it is that you’re saying. I know perfectly well what I'm saying. I'm saying that this particular commit has been authored by me (or someone who possesses my key), not by anyone else who typed "--author=seba_dos1" into their command prompt. I'm not saying anything else about the commit. I'm not saying "this code is safe", I'm not saying "I audited this source tree", I'm not even saying "I authored the code" just with the signature alone - I'm saying "I authored the commit, and here's the proof". Whatever you do with that information is up to you - and usually, for most people, this information is mostly useless, but there are cases where it's not. I'm really baffled by people who seem to try very hard to attach some extra meaning to this. "What is the possible security benefit?" - there's none, obviously (at least not on its own). It's not about security at all, what made you think it was about security in the first place? A GPG signature attached to an e-mail I wrote does not tell you that I'm not lying, but it can be useful nevertheless. > It’s worth noting that only GitHub will do this, since they are the root of trust for this signing scheme `git show --show-signature <rev>`. There's no need for GitHub for this.
nancyp 3y ago
We have a policy for our QA to sign release candidate tags. It's purely for non repudiation reasons. That's the sole purpose to keep verification on validity of the commit chain.
EPWN3D 3y ago
The analogy to notarizing everything you sign is misguided. Notarization is not required to prove you signed something -- it's usually required to make a legal claim about something in the document, e.g. "I am making these claims under penalty of perjury, and this independent party watched me make those claims." Commit signing provides an integrity and attribution, but that's it. The author seems to think there's some broader meaning to it, but there isn't. Broader meaning can be built on top of commit signing, but that's a separate system that can have a lot of different forms. I remember reading similar stuff about code signing in the early aughts. The complaints weren't about code signing, they were about accountability. "If I sign this then that means someone can hold me responsible for something that goes wrong." But they can do that anyway -- code signing didn't create a whole new form of tort that was completely impossible before. There's this sect of software people that seem to think that it's impossible to make legal attributions without the involvement of asymmetric cryptography. Like, they could just show up to court and go "You can't prove that I wrote that software because it's unsigned" and so any legal action against them is impossible. And therefore being forced to sign stuff opens them up to a whole new universe of legal action. In reality, if someone wants to sue you, they will. If they say that you wrote something, and it looks and smells a lot to a court like something you wrote, the court will determine that you wrote it. So sign your commits -- not because it'll magically make bugs go away, but because supply chain integrity is turning into a real problem really quickly, and this kind of stuff is just table stakes at this point.

15 points by BerislavLopac 3y ago

This is weak. Making commits more meaningful does not mean we need to handle the history of previous unsigned commits as the article asserts. You would simply enact a policy that says from this day, all future commits must be signed in order to prevent future identity theft. Yes, bad people may have snuck bad code into your repo in the past. it does not follow that it is unworthy to prevent bad code entering the repo in future

deleted 3y ago
[deleted]
avgcorrection 3y ago
Why are you afraid of identity theft in this context?
- nailer 3y ago
  If someone has your private key, they can act as you online.
  - avgcorrection 3y ago
    The private key that I would hypothetically sign commits with? Then signing commits is compromised too. I’m not sure what point you’re making. On the other hand if I don’t sign my commits then any signed commits (from my stolen private key (SSH)) look out of place. Like it’s weird that all these malicious commits are also signed, even though I have never signed commits.
    - nailer 3y ago
      > The private key that I would hypothetically sign commits with? Yes. If someone has your private key they can sign commits as you. I’m not sure how I can put this more plainly.

ZiiS 3y ago

This falsely assumes signing and trust is somehow tied to GitHub. GPGs web of trust has issues but it allows verifying outside GitHub.

kohbo 3y ago
You're right, but also, commit signing is useless if there’s nobody on the other side verifying that the signature can be trusted. GitHub is doing that right now but that also ties projects to GitHub. It's Microsoft's way off ensuring OSS development has to go through their gates.
- ZiiS 3y ago
  You can `git verify-commit` yourself. Gpg allows you to build a web of trust so you can find other people who trusts the commiter's key.

mytailorisrich 3y ago

I can understand signing patches sent over email. But for commits in any decent organisation one has to log in the network, have access rights to git, go through code review, and then, finally, you have code committed into the repo. In these cases signing commits does not add much, if anything.

sverhagen 3y ago
Aren't access credentials for Git entirely separate from the name and email address in the commit? You can commit with anyone's name and email address. Verifying a commit through the user's log in, I wouldn't know how to do, but their commit being verified gives me trust that it was committed by the person whose name is on the commit.
- mytailorisrich 3y ago
  My point is that what you describe will be detected even before the commit reaches the master repo with the culprit fired as long as you have sensible processes. That's why I don't think commit signing adds anything within organisations. It might be a bit different with public open source repos on services like Github though I don't know how how to verify signatures...
avgcorrection 3y ago
It doesn’t seem hard to attribute 1/5 commit in a PR to another person. Then you publish it, no one checks out the individual commits (because that’s how forges are like in my experience), and it gets merged because the 2,000 line diff “LGTM”. I don’t really have belief in the processes of these corporate environment unless the auditing is given on a silver platter. Meanwhile on email: people get an email per patch, where the commit message part has to contain a `From:` line in order to override the email-is-author behavior. PS: There is a utility to giving commit authorship to someone else. Someone sends me the change through a DM. I commit it. Did I author it? No, so I give that to them. Not an exotic use-case at all of this seemingly nefarious feature.

pooper 3y ago

I, too, used to be scared of my "middle school permanent record" except just last week, I witnessed at $work a decision being reached to let old history stay in TFS and only import the current (head if you will) in git with no history at all. I am not saying don't worry about the future or that the future doesn't matter. For most situations, git history won't matter. There is no such thing as a permanent record, not one that most people will care about anyway. Here is my reason for why we don't need commit signing — the commit must stand on its own. Either you understand the change and approve of it, regardless of whether it was signed by Linus Torvalds or Kim Il Sun, or you don't. If you don't understand the change (or the code base) and the code base is important enough for you to go looking for a signature, chances are you should be paranoid if someone got into Linus's computer and stole his private keys. Tl;Dr don't think too much about git signing. Do what makes you happy but know it doesn't matter either way.

ZiiS 3y ago
I rely on Linux being secure in ways I cannot personally verify. Partly because my understanding is not deep enough but mainly beacause I don't have the huge amout of time to invest. I use thousands of pieces of very complex software (just to write this message if nothing else). The fact that Linus is prepared to stake his reputation on signing it and that reputation has been build from thousands of people being able to review his work is extreemly important to me.
- pooper 3y ago
  If you're not looking at individual changesets/commits, how does a git signature affect you?
  - ZiiS 3y ago
    If I am reviewing a fork I can review the changes since a commit with a trusted siganture.

ZiiS 3y ago

Changes are not an issue. If a maintainer says all future commits will be signed then that is fully verifiable. The fact that older commits arn't in no way effects the trust

politelemon 3y ago

The analogies used do not work but are strongly being used as a foundation for the rest of their arguments, so the entire reasoning feels weak and misguided. No, we don't sign things with keys in real life, the same words being used in two different spheres of life do not make one 'false'. The HTTPS one is more of a rabbit hole of misunderstanding — trying to draw similarities with https and git signing is probably the root of the problem here. I'd suggest considering it on its own merit, and trying to understand why git commit signing was introduced, and what you would use it for given the cases. Also worth noting that some of the info is wrong, Github is not the root of trust, and also aren't the only one who encourage it; Gitlab have a similar guide and badge FWIW.

MattPalmer1086 3y ago
This is an example of someone with limited understanding drawing broad and unsubstantiated conclusions, as you say, using poor analogies. In general, when there's a thing that doesn't make sense to you and in which you are not expert, your first reaction should not be "everyone else is stoopid", but rather "what am I missing here?"

yoavm 3y ago

https://github.com/jayphelps/git-blame-someone-else https://github.com/jayphelps/git-blame-someone-else is a pretty good reason to sign your commits

avgcorrection 3y ago
I am also able to pee in my office mate’s coffee cup. What should we do to mitigate that threat model?
- Daviey 3y ago
  You've described the action, now let's work out the risk. If you can describe the impact and likelihood we can talk about controls.

klabb3 3y ago

A lot of statements but with an important convoluted point: git signing happens with a public key that nobody knows how to verify properly. So should we sign them today, without being able to verify yet? Well, that isn’t 100% true. GitHub knows. But relying on GitHub is a good reason to not use the feature at all, imo. A bit stallmanesque perhaps? Maybe. I have absolutely no idea about your ssh keys, which goes back to decentralized self-sovereign identity being an unsolved problem (socially and administratively, not technically). Add commit signing to the giant list of use cases, I guess.

fmajid 3y ago
It’s not a GitHub feature, it’s a git one. The question is, how do you manage your web of trust in a distributed environment? Users set up the keys they trust for signatures using GitHub’s admin UI. GitHub exposes public keys via https://api.github.com/users/fazalmajid/keys https://api.github.com/users/fazalmajid/keys but it doesn’t tell you which keys are access and which are signing. There is also no way to see what the list was at a specific point in time, e.g. when the commit was signed. The second question is how do you ensure key revocation, which is a hard problem involving verified timestamps. If you are in a closed environment like proprietary software development you can and should build their own PKI, but in an open open-source workflow the author has a point, these last-mile issues make signed commits incomplete for trust purposes.
- klabb3 3y ago
  > It’s not a GitHub feature, it’s a git one. Yes, I know. That’s part of my answer. The point is that signing is a ritualistic useless dance if there’s nobody on the other side verifying that the signature belongs to someone (ie trusts it). > Users set up the keys they trust for signatures using GitHub’s admin UI. Yeah, that’s fine. But that’s between me and GitHub. > GitHub exposes public keys[…] Exactly. I agree with your points about security. But even so, it’s still a proprietary system relying on centralized identity. It ties projects to GitHub, and offloads trust to them. This is not git anymore - it’s the same as signing in with Yahoo or WeChat. It’s a way for Microsoft to put themselves on the critical path for virtually all today’s OSS dev. > If you are in a closed environment like proprietary software development you can and should build their own PKI I don’t know about this. Operate PKI? Maybe. Build? Aside from dedicated expert teams at mega-corps, no thanks. PKI is closely related to the decentralized identity problem - which is what I really hope we will solve. We really, really need it.

avgcorrection 3y ago

Completely correct that you should have a reason for signing something which goes beyond the vacuous “why not”. In my own work, the surrounding context is sufficient verification. By the way: patch attestation [1] is perhaps somewhat related. Pretty well-thought out techniques for verifying that patches sent via email. [1] https://lwn.net/Articles/813646/ https://lwn.net/Articles/813646/

seba_dos1 3y ago

> With signed commits, you are saying something permanently, but you don’t really know what it is that you’re saying. I know perfectly well what I'm saying. I'm saying that this particular commit has been authored by me (or someone who possesses my key), not by anyone else who typed "--author=seba_dos1" into their command prompt. I'm not saying anything else about the commit. I'm not saying "this code is safe", I'm not saying "I audited this source tree", I'm not even saying "I authored the code" just with the signature alone - I'm saying "I authored the commit, and here's the proof". Whatever you do with that information is up to you - and usually, for most people, this information is mostly useless, but there are cases where it's not. I'm really baffled by people who seem to try very hard to attach some extra meaning to this. "What is the possible security benefit?" - there's none, obviously (at least not on its own). It's not about security at all, what made you think it was about security in the first place? A GPG signature attached to an e-mail I wrote does not tell you that I'm not lying, but it can be useful nevertheless. > It’s worth noting that only GitHub will do this, since they are the root of trust for this signing scheme `git show --show-signature <rev>`. There's no need for GitHub for this.

nancyp 3y ago

We have a policy for our QA to sign release candidate tags. It's purely for non repudiation reasons. That's the sole purpose to keep verification on validity of the commit chain.

EPWN3D 3y ago

The analogy to notarizing everything you sign is misguided. Notarization is not required to prove you signed something -- it's usually required to make a legal claim about something in the document, e.g. "I am making these claims under penalty of perjury, and this independent party watched me make those claims." Commit signing provides an integrity and attribution, but that's it. The author seems to think there's some broader meaning to it, but there isn't. Broader meaning can be built on top of commit signing, but that's a separate system that can have a lot of different forms. I remember reading similar stuff about code signing in the early aughts. The complaints weren't about code signing, they were about accountability. "If I sign this then that means someone can hold me responsible for something that goes wrong." But they can do that anyway -- code signing didn't create a whole new form of tort that was completely impossible before. There's this sect of software people that seem to think that it's impossible to make legal attributions without the involvement of asymmetric cryptography. Like, they could just show up to court and go "You can't prove that I wrote that software because it's unsigned" and so any legal action against them is impossible. And therefore being forced to sign stuff opens them up to a whole new universe of legal action. In reality, if someone wants to sue you, they will. If they say that you wrote something, and it looks and smells a lot to a court like something you wrote, the court will determine that you wrote it. So sign your commits -- not because it'll magically make bugs go away, but because supply chain integrity is turning into a real problem really quickly, and this kind of stuff is just table stakes at this point.