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
Just to be clear, this is about how signed commits appear in GitHub, right? Native Git signing is as robust – and complex – as it’s always been, with the user having to keep their own GPG private and public keys. Managing these keys is the same process for signing outbound emails or preparing to receive inbound encrypted emails, with the attendant usability quirks like dealing with key revocation.
The author’s main gripe appears to be with how GitHub presents a veneer of trust based on the commit signature, but not in pursuit of a cognizance security objective. That the veneer of “verified” could be confused with “safe to compile/execute” could regress overall security of users. I think this position is well-supported by the examples given.
But what I don’t see is how this relates to Git signing at-large, when GitHub is not involved. The title of this Lemmy post and the blog post is “Unsigned Commits” and the author only ever mentions the consequences as they pertain to GitHub. Yet the same concern as the author’s post can apply here: users who don’t recognize that this is a GitHub-specific grievance might think ALL Git commit signing is useless, which is wrong. And that mistake would regress overall security of all Git users.
An example of Git signing outside of GitHub is the Linux kernel. Note that “PGP keys” are what GPG uses to sign the commits; that’s not confusing at all.
PGP helps ensure the integrity of the code that is produced by the Linux kernel development community and, to a lesser degree, establish trusted communication channels between developers via PGP-signed email exchange.
Ever since the 2011 compromise of core kernel.org systems, the main operating principle of the Kernel Archives project has been to assume that any part of the infrastructure can be compromised at any time. For this reason, the administrators have taken deliberate steps to emphasize that trust must always be placed with developers and never with the code hosting infrastructure, regardless of how good the security practices for the latter may be.
As the Linux folks so eloquently put it, and in firm agreement with the author of this post, the infrastructure (kernel.org or GitHub) cannot be trusted over indefinite timescales, and problems will arise eventually. In disagreement with the author but in agreement with the Linux people, signed commits decentralize the trust, making the infra less useful to attack.
I personally still encourage Git signing, just like I would encourage email signing and encryption. But not just because GitHub is telling me I should. Every email and commit I produce, I should sign; the author here says I shouldn’t, and I disagree. Signatures are valid for a specific purpose, until the day the signature key is revoked, which I can always do, however annoying.
TL;DR: Git signing is fine. What GitHub built atop native Git signing is questionable. Do sign stuff, but for real reasons, not just because GitHub tells you to.
I almost wanted to call the linked post as clickbait, based on its terse title and the bold claim made in the subheader (“I’m not going to cryptographically sign my git commits, and you shouldn’t either”). But there was just enough substance to present and justify a colorable argument in the post. It just wasn’t the same argument presented in the title, and took me way too long to determine what the grievance was directed at.
Worthwhile read? Eh, not until its position is clarified to not be confusing.
For anyone wondering - why would I need it? I’m already signed in to github, the commit is commited using my ssh-key, Github knows it’s me. Why would I need another verification?
Here’s why. https://dev.to/martiliones/how-i-got-linus-torvalds-in-my-contributors-on-github-3k4g . If someone commits with your email (or github noreply email, which is public), it will get attributed to you. I was just trying it with colleauges account, and so far I haven’t found any way how to tell that it really wasn’t him.
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.
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.
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.
I think he should reconsider his stance on signing commits.
Agreed, and I have more arguments against commit signing.
- Commit immutability is undesirable, and mutable commits are not compatible with signing. For instance, pull requests are squashed and rebased to keep linear history, and changes are cherry picked around. It does not change authorship, however it changes hashes and invalidates any signatures. Or, say, one wants to adopt an otherwise FOSS project which though contains some copyrighted material in its repository, which needs to be
filter-branched away, again invalidating the signatures. - In our world where stuff randomly gets criminalized I prefer to avoid being undeniably linked to my code.
BTW this topic has common considerations with now mandatory (on GH and more places) 2FA. For the latter reason, and also for own convenience and for reducing risk of losing access to your account (which I assess as much higher than risk of leaking my password to third parties) I make second factor public, effectively reverting to 1FA.
I make second factor public, effectively reverting to 1FA.
I work as a Red Teamer, and I heavily disagree with this approach. MFA has been a bane of so many engagements. We usually end up with a lot of credentials from the target company that we can’t really use for anything (unless you already are in the network, where some of Windows services don’t require it), because each one is under MFA.
There’s so many different ways how can you solve the problem of not loosing access to you account. Make offline back-ups of recovery keys, back up your Aegis vault to different places.
Also, you may have a pretty good level of security awarness, highly reducing the risk of any kind of breach happening to you. But that’s something you can only affect to a degree. Supply chain attacks happen, zero days happen. An extension you are using in your browser may get compromised, and someone pushes a info-stealer instead (which has already happened, i.e with Nano Defender). MFA is what will help you in cases like these.
- Commit immutability is undesirable, and mutable commits are not compatible with signing. For instance, pull requests are squashed and rebased to keep linear history, and changes are cherry picked around. It does not change authorship, however it changes hashes and invalidates any signatures. Or, say, one wants to adopt an otherwise FOSS project which though contains some copyrighted material in its repository, which needs to be
Great read.
I agree about the culture problem. People want to slap extra encryption into things, like a spoiler on a hatchback.
The core issue is that the problem being addressed by signed commits is already solved.
Did MajorHavoc write this commit?
If it has my username, on GitHub, you’re confident it’s my commit.
Alternately, it could be someone with so much access to my SSH keys, or to GitHib’s infrastructure, that they could easily sign commits as me, anyway.
Signed commits might become more compelling when we start to favor fully open source federated git solutions. At that point, if I’m famously trustworthy, and the repo I submitted a signed commit to is not, then my signature could mean something.
But even then, there’s the risk that someone interprets my 4 minute typo fix as my having some clue whether the repo is actually safe to use…
Anyone can slap your name and email on a commit and pretend you wrote it
On GitHub, the account that pushed the commit is already fairly evident.
Commits pushed from my GitHub account are differentiated from commits that are not.
I don’t want huge centralized Git infrastructure, but while we have it, signed commits are less compelling.
And I’m not saying I love the current state of code authorship verification, either.
If it has my username, on GitHub, you’re confident it’s my commit.
Apparently, that’s not true: https://dev.to/martiliones/how-i-got-linus-torvalds-in-my-contributors-on-github-3k4g
However, it’s a pretty old article - maybe it’s already fixed? I’ll have to try that.
EDIT: It still works, and you can just use the github noreply address, which is ID+username@users.noreply.github.com . The commit gets linked to their profile, and is shown on their profile page, has their username and profile picture. I haven’t figured out any difference between legit and impersonated commit so far, but maybe it’s hidden somwhere in the repo administration.
So, there you have it. That’s what PGP signing is for.
Nice.
That’s enough to make me reconsider signing. Thanks!
Can someone explain this article? I’m not sure what signing a commit is. If it’s the information appended with a commit (username, time of commit, commit message), then it sounds insane to be against that. It’s so helpful to not only know who did what in case you need to reach out to the person behind something, but also knowing the why behind it can be important.
The majority of the issues the author has seem strange to me. I can understand not wanting GitHub to be this central authority. However, in what world is making a commit to a repo indicative of one endorsing every single line in a repo? And the security issues just come down to “don’t let your data leak”. Though that could be an issue if GitHub leaks it themselves.
the information appended with a commit (username, time of commit, commit message)
it’s not that, it’s the cryptographic signature of the commit’s contents with a private key, which allows verifiers to attest the integrity of the commit and authorship through the corresponding public key. The problem is that anyone can write anyone else’s name and address in the author field. The signature would mitigate this impersonation problem.
And ultimately, that’s a good thing. The article just puts into question the overall usefulness of it and how GitHub in particular handles this process.
Thank you for explaining and for the article, that makes sense. I can’t see any reason against having it, but I’ve never had to interact with that so I’m not qualified enough to form a concrete opinion!
I’ve never understood the point of signing commits. If i can push a commit to a repo, then i can also add my own keys to the repo as well right? So malicious actor with my password can happily push signed commits?
Do many people actually sign commits?
I don’t sign my commits.
Though I’ll admit I’m not making a moral judgement, it was just a pain in the ass to setup last time I had the time to try it.
I don’t sign my commits because I’m not going to verify anyone’s commits.
Yep. Same.
And of course there’s a relevant XKCD:https://xkcd.com/1181/
Unless they have access to your private key then there’s no way they can sign code as you.
Alternatively yes, access to your password (and 2fa) would allow them the ability to add an ssh private key for you.
But that’s irrelevant because the issue at hand is that I can make a commit to a repo that I have access to, but using your username, and there’s no way to verify it wasn’t you (actually there is but it requires some assumptions and is also dependent on the git hosting infrastructure)
However when you use signing, key ‘A’ may be able to access a repo but can’t sign commits as key ‘B’, so you can’t have the blame dropped on you for malicious commits (again, unless they also compromised your account/key)
For some more detail see https://dev.to/martiliones/how-i-got-linus-torvalds-in-my-contributors-on-github-3k4g
I use comment signing as some kind of a multifactor.
I have my signing key saved on YubiKey, so it’s pretty difficult that an attacker could gain access to it.
However, you can still commit through git web browser, and usually have a session for it open when working. If I slipped up and someone got to my PC while I have github open (or managed to steal my session cookies somehow - i.e a rubber ducky driveby), his options are:
- Commit without signing through SSH. I have ssh key password in my password manager that auto-locks after a minute, so that shouldn’t happen, plus the commit wouldn’t be signed since I have the key with me.
- Commit something though the browser - he can’t sign it.
- Add SSH or a new signing key through the browser - I get immediately notified.
So, the end result should be that thanks to the signing mechanism, I should immediately know that something is wrong. Is it neccessary? Probably not, but I still think it’s worth it, at least for me.
Now I’m wondering whether it wouldn’t be better to have the ssh key on the Yubikey instead. Hmm. I did only discover commit signing later, and didn’t have ybikey before, so it never occured to me.
I just like seeing the green badge.
I wouldn’t expect or ask others to do it in normal circumstances. FWIW, there might be a (marginal) advantage of using it though:
Here’s the only one that might convince me to start signing commits someday. The high level issue is that the author of a commit is whoever shows up in the Author: field, which can be any random string. GItHub manages permissions on a repo using a GitHub account, which may or may not use the same email addresses in a commit. Anyone can push commits to their own repositories with anyone else’s email address.
