I'm not going to cryptographically sign my Git commits, and you shouldn't either

The edge lord way to respond to this article, would be to go around &quot;contributing&quot; to various projects under their name with bad commits. I&#x27;ll leave that for someone else to do, but signing commits means they did actually come from you. In this world with a big bad Internet, where supply chain attacks are real, it really isn&#x27;t that much effort to register on GitHub and verify commits. If you have some religious reason not to against GitHub, sure, don&#x27;t do it, but for the rest of us, after reading the article, I don&#x27;t see why not. The article says it&#x27;s unnecessary complexity, but I don&#x27;t think it is because it addresses a weakness in git&#x27;s design. That it&#x27;s a permanent record that you did something in the past is a feature, not a bug. It means <i>you</i> did it, not someone claiming to be you. Scammers are getting more and more advanced, and it&#x27;s just so little effort now to say you <i>didn&#x27;t</i> do a thing.

I don’t fully understand the argument. The article is rambling and touches so many topics in different ways such that I can’t really see a clear analogy or connection.<p>What I gathered was that the author believes signing commits to be bad because;<p>1. It adds complexity that you otherwise don’t need<p>2. GitHub is the only place that cares or enables this and we don’t want to add to their Git monopoly<p>3. Signing the commit does little in reality since it doesn’t affect anything other than “Verified” on GitHub<p>4. Something about signatures being permanent?<p>Honestly I don’t get the argument. It’s not useless, not hard to set up, and not hard to maintain. You can initially lock yourself out of committing if you mess it up but usually it won’t lock you out. The extra assurance that someone signed the commit with a key that only they should have is really good if you care about that. That means someone can’t just spoof your name (which is very easy with Git) and sneak changes in more easily.<p>Humans are still a key part of working around source control. That means there is trust involved, and code is pretty sensitive. Folks now are also more distributed and it’s harder to control where they access work systems from, or if that environment is secure (eg coffee shop over VPN does little if you leave your computer unlocked and get up to get a refill). Any extra assurance can be meaningful, specially if it’s around your code.<p>If you want something to take more concrete action you can enforce that a bot reject any work with unsigned commits present. Your CI can do that quite trivially even.<p>It’s not perfect but it’s also, IMO, the future. GitHub supports it now but others will in time (or do). Then GitHub will have trained people to get it working and you don’t need to learn it again.<p>Long article for not really saying much.

&gt; It’s worth noting that only GitHub will do this, since they are the root of trust for this signing scheme<p>This is completely untrue. GitLab does this. GitTea does this. You can do this manually in the command line.<p>I don’t think the author knows that they’re talking about.

i&#x27;ve been meaning to set this up for some time. now this does nothing but nudge me to do it sooner than later.