I recently started using the excellent keybase.io app for encrypted chat and all the crypto goodness motivated me to finally set up gpg verified commits on Github. I started with this helpful article: Github GPG + Keybase PGP which I recommend you take a look at, but I had to do a few more steps that I wanted to document.
Keybase is easy to install: keybase.io/download. For arch, it was a simple install and setup:
packer -S keybase-bin run_keybase
Once installed, you’ll need to start up the app and create an account if you haven’t already.
Generate a new key with keybase, and upload it to your profile. Alternatively, use
keybase pgp select to use your an existing key. To use this key for Github verified commits, it will need to have the same email as on your Github account.
$ keybase pgp gen
Export your keybase secret key to your gpg keyring:
$ keybase pgp export -s -p | gpg --allow-secret-key-import --import --
List keys in your gpg keyring and locate your keybase key
$ gpg --list-secret-keys --keyid-format LONG /home/jay/.gnupg/pubring.kbx ---------------------------- sec rsa4096/C17228D898051A91 2017-01-30 [SC] 326DA75610069B5DECA8D2DDC17228D898051A91 uid [ultimate] Jay Baker
ssb rsa4096/7C87801D5E56F673 2017-01-30 [E] sec rsa4096/C24CD98AB0900706 2017-09-28 [SC] [expires: 2033-09-24] F21FC721B22B0C176BAFBE35C24CD98AB0900706 uid [unknown] Jay Baker uid [unknown] Jay Baker ssb rsa4096/4599729752E8D5C4 2017-09-28 [E] [expires: 2033-09-24]
I have two keys here, the second one is the one I made with keybase pgp gen. We want to grab the keyid string from the second line:
sec rsa4096/C24CD98AB0900706 2017-09-28 [SC] [expires: 2033-09-24] C24CD98AB0900706=
Let’s set a trust level for our key. Since we just made it, we can give it full trust.
$ gpg --edit-key C24CD98AB0900706 gpg (GnuPG) 2.2.1; Copyright (C) 2017 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. sec rsa4096/C24CD98AB0900706 created: 2017-09-28 expires: 2033-09-24 usage: SC trust: unknow validity: unknown ssb rsa4096/4599729752E8D5C4 created: 2017-09-28 expires: 2033-09-24 usage: E [unknown] (1). Jay Baker
[unknown] (2) Jay Baker gpg> trust Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y sec rsa4096/C24CD98AB0900706 created: 2017-09-28 expires: 2033-09-24 usage: SC trust: ultimate validity: ultimate ssb rsa4096/4599729752E8D5C4 created: 2017-09-28 expires: 2033-09-24 usage: E [ultimate] (1). Jay Baker [ultimate] (2) Jay Baker gpg> quit
Now we can decide to do global or per repository signing with git. This step is optional, you can always manually sign commits with
git -S or
git --gpg-sign on a per commit basis.
$ git config commit.gpgsign true
This is per repository, add a
--global flag after
config if you want to enable gpg signing globally for git. If we change our minds later and want to disable signing just run the same command but with
false. Also, if want to do just do a single commit without signing:
$ git --no-gpg-sign commit
Now let’s tell git which gpg key to use:
$ git config user.signingkey C24CD98AB0900706 # per repository
Again, add a
--global flag if you want.
To verify that our commit worked:
$ git log --show-signature commit 1f10113fadeae03fd8de870fb18c8563d0b3c602 (HEAD -> master) gpg: Signature made Thu 28 Sep 2017 17:23:20 EDT gpg: using RSA key F21FC721B22B0C176BAFBE35C24CD98AB0900706 gpg: Good signature from "Jay Baker
" [ultimate] gpg: aka "Jay Baker " [ultimate] Author: Jay Baker Date: Thu Sep 28 17:23:20 2017 -0400 detailed commit message goes here
Finally, we need to add our key to Github. Remember, your key will need the same email as your Github user email. You can add more email addresses to your key with
gpg --edit-key and then the
Let’s get our public key from keybase:
$ keybase pgp export -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFnNUb8BEAC3RGNiW3AYUIxAsrQBRfclM65naI/xGlvRju6b5tuoZ33Qbvnq ... WB+E6/rYlZG4Vdk2W1bTk0R2iAVHoamZD0PmJAkv46SiuHqeyOdBGAGsgdVo1FGa Gw== =sE0m -----END PGP PUBLIC KEY BLOCK-----
Copy that, and head to https://github.com/settings/keys, click “New GPG key”, paste it in, then click “Add GPG key” to save it. verifi
That’s it! You can now have verified commits on Github with your keybase pgp key!
I’ve been very busy at work, mastering infrastructure as code tools and work-flows, but somehow I’ve found the time to start learning Go!
I had already learned some python and even used it for a couple of small projects at work. Python is a great language with beautiful syntax that makes coding a joy, but it’s slow as molasses and managing dependencies is no fun. Docker can help here (that’s how I solved my dependency and environment parity issues), but you just can’t beat static binaries for portability and ease of deployment, not to mention speed.
Go is a newer language compared to Python or Java, but it has quickly gained popularity. Most of my favorite DevOps tools are written in Go: Docker, Kubernetes, Consul, Nomad, Packer, Terraform … the list goes on. When new open source DevOps tools appear, it’s more surprising at this point when they’re not written in Go!
For a previous project, I wrote a little tool in python that watches for newly uploaded files and feeds them into an ETL pipeline. It wasn’t pretty but it got the job done. Since that’s a problem I can wrap my head around, I decided to build the same thing in Go, or at least the file system watching part. Moving files around the filesystem is fairly trivial in any language.
I’ve since created a more powerful version of this which I hope to finish up soon and post here, but I figured this little snippet would be useful for anyone just getting started with Go or fsnotify