I wanted to finally start getting into signing my commits, mainly because among any other reasons, it increases the overall confidence in my work. With the GitHub's decision to display a yellow warning stating Unverified near the commit list, the trend towards signing will almost without a doubt only continue.

This situation can, and maybe even will, evolve to a point, where only signed commits will be generally accepted, wherever more than one people is working with a repository, and that is a good thing. Properly signed work greatly decreases chances that the malicious code will slip in, if nothing else.

The problem lies in the word properly. There is a clear way stating how to properly sign commits. There is however no clear way, when we move one step further: How to handle signing keys properly?

Handling GnuPG keys

There is a ton of material available and I have read quite a good deal of it recently. All this has led me to two conclusion: The whole PGP scene (including OpenPGP and GnuPG) is a mess we probably cannot live without.

At first I thought I did not adapt the gpg workflow sooner because there simply was no pressing need to. But there are actually two scenarios of not learning how to use a tool or a workflow, otherwise used regularly and also considered important by other people doing the same thing:

  1. Not learning because of no pressing need, as mentioned
  2. Not learning because the tool does not need learning, unless doing something specific

As an example of the second scenario I would mention web bundlers category. Here, tools like Webpack, Rollup, Parcel or some of the new players like Snowpack, Vite or ESbuild.

Too many people use these tools without ever learning how to use them, as they come configured by someone else already and for the purposes at hand they usually just work. This argument can be applied to many other things, such as using an IDE prevents learning how to use git commands, or even the argument's simpler form stating that using GUI prevents learning any underlying commands.

GitHub signing commits automatically

The moment I was left somehow puzzled was when I have found out that when adding commits via GitHub web interface, they get Verified automatically. It caught me by surprise, because I knew I did not touch any PGP related fields in the GitHub interface, so I did not know how could they become signed. As a side note, I use primarily my self-hosted Gitea server and I am pretty satisfied with it and that's why I do not keep up with all the changes GitHub is rolling out.

I am not entirely sure how does GitHub do the automatic commit signing as I have not read anything about that mechanism yet. It is probably based on the assumption that I am logged in securely, my email address is verified and other similar pieces of information. This feature reveals itself in a strange light when working for instance on a collaborative Pull-Request and pushing separate commits via both channels: GitHub web interface and git push to my forked repository branch, tracked by that Pull-Request.

When looking at the commits made like this, it promotes chaos. The commits come from the same person, but some are verified and some are unverified. I believe, that such picture, with the words Verified and Unverified alternating furiously reduces the confidence in the code I push. This can also happen when someone does all the signing entirely manually and sometimes forgets to sign, but in this scenario, is the user's choice to adapt a workflow where they need to keep track of certain things (not forget to sign each commit manually). In the former case, GitHub does some decision making here instead.

Should everything be signed?

Consider a hypothetical scenario, where GitHub forces a policy that every single commit accepted into it's ecosystem has to be signed and there is no way around it.

Let's put all the political, economical and social implications aside, which all important by their nature nonetheless, and focus purely on some technical implications. Would such strong a policy ensure, that all the commits would in fact be signed? The answer is yes. No sign, no push. Problem solved.

But would it mean that all the commits are signed properly? Let's consider a scenario, where some user would mistakenly push the master key used to sign the commits in the same repository? And what if some user did so deliberately, as an act of rebellion against the forced policy?

Would this mean that all the commits are signed? Yes, this requirement would still hold. But would it mean that all the commits are signed properly? Definitely not, but I have yet to understand all or at least the main implications of such scenario.

Conclusion

Even after all this research and years of telling to myself "I have to start using GnuPG soon", especially for signing commits, not even getting into encrypted/signed emails whatsoever, I still did not start.

The reason is that it looks like there are too many ways to do it wrong. It also looks like it pays of in the long run to do it right, but that obviously requires some research and very likely some investments into the dedicated hardware. Either it all becomes more streamlined or I push myself to learn ad set up it finally. Everything is impossible until you do it.

This is a 38th post of #100daystooffload.

Update

Just a few days after publishing this post I have found out that there is only a single signature that is also published in the keyserver, information can be queried as follows:

gpg --search-keys 4AEE18F83AFDEB23


gpg: data source: https://hkps.pool.sks-keyservers.net:443
(1)	GitHub (web-flow commit signing) <noreply@github.com>
	 2048 bit RSA key 4AEE18F83AFDEB23, created: 2017-08-16

I would still like to understand it deeper, hopefully I will stumble upon some post explaining the problematic in a more digestible pieces.