> 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.
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.
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?"
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.
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.
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
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.
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.
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 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.
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.
My point is that even making calls to the GitHub API and archiving the results (signed by the fetcher, of course :-) can't produce an audit trail and artifacts you can use to reconstruct the commit signature validity history.
Now if you merge a PR, it will be signed by the person who committed the merge (or rebase). Thus the problem is simpler than full-blown distributed PKI (at which point some salivating shill will of course trot out the blockchain as universal panacea).
You need to ensure the signature keys of all committers (a much smaller problem than the universe of all possible contributors) and their timestamped history are known and kept somewhere in the repo. One solution would be to define a standardized file format similar to the SBOM standards CycloneDX or SPDX) to record this log (I suppose its generation and maintenance could be automated by a GitHub action), and signed by a comitter. This file can then be used to validate all the signatures even if GitHub falls off the face of the Earth.
There is a bootstrap problem for how the many committers on a project trust each other, but that is handled by GitHub or whatever mechanism was used to convene the committers together in the first place.
I have a keyring of my teammates' public keys at work. I can verify whether their commits come from them with a single local command - and so can our CI.
You can download my public key from my website and I can tell you in person or over any other channel you trust whether it's correct. At this point, you can verify all my commits with a single local command.
Where does GitHub come into all this? I don't even use GitHub (unless contributing to a project that does).
That's really nice. What tools are you using? How do you manage adding and removing keys? How many people and devices are involved?
> Where does GitHub come into all this?
To maintain verification dynamically for team members. Maintaining lists are otherwise (and in your example, I think) a N^2 maintenance task. Everyone needs to update their pubkey list when a team member adds or removes a device.
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
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.
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.
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.
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...
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.
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.
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.
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.