I don’t think you should sign your Git commits
blog.glyph.im
blog.glyph.im
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.
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.
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?"
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.
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.
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
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.
Yes. If someone has your private key they can sign commits as you. I’m not sure how I can put this more plainly.
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.
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.
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).
> 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.
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...
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.
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.