Signing my git commits without GPG

Unlike most git users, I try to sign my commits. Unfortunately, the only way to do this right now is to use PGP signatures, because that is all that git is able to integrate with. This has meant that in practice I have to use GPG if I want to sign my commits, an experience I do not relish. Last week, I wrote a program to replace GPG for that purpose.

Background: PGP and GPG

If you don’t know what this PGP and GPG business is all about, let me first tell you that you are fortunate to have avoided this unpleasant subject until now. A quick rundown:

  • PGP, which stands for Pretty Good Privacy, is a specification for an information security system, describing a format for transmitting data like encrypted messages and digital signatures.

  • GPG, which stands for GNU Privacy Guard, is an implementation of PGP that has become the standard implementation. It is written in C.

Diplomatically, I would say that both PGP the protocol and GPG the implementation leave a lot to be desired. They have a notoriously bad user experience and interface: this system is almost impossible for most potential users to use “correctly.” Having read the specification of PGP and some of the code for GPG, I also have a poor opinion of the internal details here, which have clearly accumulated unnecessary cruft over several decades of existence.

I would also add that I think PGP/GPG has created a harmful culture around information security. Between its arcane interface and encouragement of silly myths (like moving your mouse around while generating a key), it inculcates a culture of learned helplessness in which we are led to believe we are incapable of truly understanding information security & making informed, autonomous decisions for ourselves. By centering a web of trust based on permanent identifying keys, the protocol emphasizes unattainable goals like perfect trust over more important and achievable goals, as other people have explained better and before me.

All of this results in a culture of technical authoritarianism completely contrary to the stated goals of the crytoanarchists who designed these systems; not to mention the lack of widespread adoption these kinds of secure tools have seen in practice. The ongoing continuation of this culture is, I think, largely the consequence of our failure as technologists to integrate the critical and intellectual traditions of the humanities in our work.

I think you should probably not use PGP or GPG if you can help it. If you want to communicate privately, I think you should use a messaging application that implements the Signal Protocol, such as Signal, WhatsApp, or Wire. Unfortunately, for digital signatures, fewer options exist; in particular, git only integrates natively with something that has the same interface as GPG.

pbp: Implementing part of the PGP protocol in Rust

Rust package registries like crates.io use git to transport important (and security critical) metadata about the packages they contain in a repository called an index. I’ve been taking steps toward trying to sign and verify the data in that index without shipping a copy of GPG with Rust to every user.

This means I need to implement enough of the PGP protocol to create signatures and public keys that git will accept as valid. I’ve done this in a library which I’ve named pbp, this stands for Pretty Bad Protocol.

This library implements parsing and generation for a small subset of the PGP protocol: specifically only using the ed25519 signature scheme & only using certain packet format options. This is enough that if you want to verify a signature generated by any recent verison of GPG using an ed25519 private key, pbp should be able to parse that signature. Similarly, signatures generated using pbp should be parsed correctly by GPG.

bpb: Signing my own commits with pure Rust code

Before implementing anything in cargo which depends on pbp, I wanted to exercise the library a little bit. I was also a bit annoyed about having to set up GPG on the new laptop I just got in order to sign my commits. So instead of setting up GPG, I wrote a little program to sign my commits without depending on GPG at all.

My program is called bpb, which stands for boats’s personal barricade. It generates PGP signatures in the way that git expects GPG to do, allowing me to replace GPG with bpb for my purposes. Right now, it doesn’t verify commits, and instead shells out to GPG for that kind of thing. To implement the actual ed25519 signing algorithm, bpb depends on the dalek project, a set of excellent cryptography libraries written in pure Rust.

I did not design bpb to be a generally usable product, but maybe someday it will become one. For now, you should consider carefully whether its security properties are a good fit for your use case. It was designed for my use case: I want to generate a new public key on each machine I use to write code, store it unencrypted in my home directory, and publish it to GitHub to verify the commits I post to my GitHub account. If this isn’t enough security confidence in the signatures it generates for your purposes, it won’t be adequate for you.

I personally don’t verify other peoples' commits, because the people I collaborate with mostly don’t sign their commits at all. As a result, bpb does not verify commits itself (passing through commands like that to GPG). Though I doubt I will have time to make it happen, I would love for bpb to evolve into something generally useable for people in a similar situation to me to start signing and verifying one anothers' commits without the theatrical rigamarole that keeps most people from bothering with GPG.

Conclusion

There’s not very much of a point to this post: I just wanted to document a little side project I’ve been working on recently. It’s somewhat exciting to me that I could personally delete GPG from my systems and my life wouldn’t change, having replaced that project with a relatively small Rust application. More and more of my tools are being replaced by new code written in Rust, which makes me feel excited about the work I’m doing to enable the authors of these tools.

I’ve expressed some mild opinions about information security practices in this post; if you want to contact me because you disagree with my opinions, I’ll let you know that I am not very interested in debating information security with strangers from the internet. I find that these conversations are usually aggressive and unpleasant: this could change and should.