Signing Git Commits

signing_commits.md

OpenPGP is a standard for encryption and signing

• https://en.wikipedia.org/wiki/Pretty_Good_Privacy#OpenPGP
• Pairs of public and private keys
• To send you an encrypted document, I encrypt it with your public key, then only your private key can open it
• Singing verifies the sender. You sign with your private key, and then anyone with your public key can verify that it was truely you who sent it.

PGP vs GPG

• PGP is a proprietary implementation and GPG is a Gnu implementation of OpenPGP

Web of Trust

• https://www.gnupg.org/gph/en/manual/x547.html
• The biggest hinderence to GPG adoption for encryption is establishing a web of trust. I trust you and you trust me, we exchange public keys.
• If I trust you and you also trust Herb, then there is a key signing process that basically validates that our public keys are actually our public keys

Keybase Ideology

• https://keybase.io/docs/server_security
• Uses social capital for identity validation.
• Keybase makes the connection between social you (twitter, github, facebok, ...) and your key.
• This allows you to trust a key for an online presence (i.e. coder on GH). Nuanced difference between "this key is yours" and "this key is associated with your online presence"

Keybase Features

• Upload just your public key so that others can send you encrypted messages and files or verify your signature.
• Upload a public / private key pair and use it as a "key locker", also enables you to use their ui for decrypting / signing.
• Generate a key pair with keybase. gives you things like syncing across devices, easy passphrase updates, ...

What does this have to do with Git?

• When you commit or tag code, the only "real" proof that it was actually you is that you included your email.
• You can sign git commits / tags with your private key the same way you would sign a file or a message. Anyone with your public key can verify that it was infact you that did it.
• If you give github a copy of your public key, it will "verify" your commits and tags in the UI to establish trust that it was infact you that signed it.

Why sign commits?

• Social reasons: Let's say you are often a target of terrible things online. Someone might spoof a commit to a terrible online repository to affect your reputation. It doesn't "quite" give you deniability, but it's better than nothing
• If it's a prolific project (linux kernel), someone might spoof a commit introducing a security vulnerability. If it's not signed, then people that should be validating trust can't really know that someone they trust wrote that code.
• Signing release tags is AWESOME it means that people pointing to those shas as a dependency have a bit more of a guarantee about who published it, and also that the entire tag ancestry has been “unchanged”

Alternative viewpoints

• Not every commit needs to be signed. It's probably enough to sign important commits (maybe merge commits??) to verify the current state.
• Linus says that it means that you've just automated the process and made it less credible

How to get started?

1. Create a keybase account and link it to your online presence https://keybase.io/
2. Generate a key pair with keybase https://keybase.io/docs/command_line
3. Import the key pair into your local GPG key utility https://www.keybits.net/post/import-keybase-private-key/
4. Configure git to sign your commits with the PRIVATE key in your store https://github.com/samjonester/dotfiles/commit/726e011ba95147d3d7dbb3ae2780d44bbe0500da#diff-4723a3b40361325f6612c40749b696d9
5. Upload your PUBLIC key to GitHub for your "verified" badge https://github.com/settings/keys