 So thank you, Olivier. My name is Caleb Thompson. I work at Thoughtbot with Mason here, this guy, and co-organize Keep Ruby Weird. We are here to find the answers to the question, what is this PGP thing and how can I use it? You can find me on the internet here just about anywhere. So a lot of you got USB keys. Those have the software that we're going to be using today. So if you can copy that onto your disk and then pass that key along to somebody else, it also has my public key on there. So if you just copy both of those things onto your disk, we'll get to them later. This is a link to the slides because this font doesn't make it very clear, that's a zero. So I'm not going to be pausing too much in this presentation. I don't want to have to go back and forth to show some of the commands that we're going to run. All of the commands are in these slides, so I'll give you a minute to go ahead and grab those. If you are interested in, if you're already like a PGP pro, or if you are more interested in the command line, or if after this you're interested in learning more about PGP in general, I wrote an extensive blog post about a year ago now that details just about everything I know about all of this stuff. It uses the command line tools rather than the GUI tool that we're using today. But all of the same concepts apply, and it does a really good job of explaining why you're doing any of these things as well as how to do them. So we're going to be using a program called GPGTools. It's actually a suite of programs. You can download those from the internet at GPGTools.org or they're on the USB that I've given you. So this is how you would download them. That's the button. So because this is security software, we actually have to verify that the package is the correct package. Mason made the joke that let this be the last package that you don't verify, but we are going to verify it. So if you have a trusted PGP version, then what you can do is download the GPG signature from GPGTools right here. Download the key from here. Import it into GPGTools or into your favorite GPG program, PGP implementation. And then you can verify the fingerprint of the public key here and run this command on the command line to actually make sure that you have the software that you expect to have. Probably though, you didn't already have a GPG implementation on your computer. So we are instead going to verify the SHA of the package. So I've given you something. It could very well be malicious. It could, I could have given you the wrong piece of software accidentally. I didn't install from that binary myself. And so what we're going to do is check it against the SHA that GPGtools.org says is the correct one. So a SHA sum is just the simplest way to verify that the file that you're looking at is the file that somebody wanted you to have. So you can be sure that the person lying to you about the piece of software is the same person who's lying to you on the internet, on the website that you downloaded it from. And maybe that person lying to you is actually a developer. So this is the command that you were gonna run to make the, to verify the package. And it's gonna output a number. You want to make sure that the number matches up to this one. So once you are satisfied that you have the right piece of software, we're gonna install it just like you would normally. There's nothing special here to installing the package. Can somebody make sure that she gets the USB? I'm gonna move on. I have helpers who are gonna make sure that you are being dealt with. Okay, so the next step is going to be building key pairs and uploading public keys. What the heck is a key pair? To get anywhere with PGP, you're gonna need one of these things and it's composed of two parts. That's why it's called a pair. It has a public key which you're gonna publish and it's used to encrypt messages to the owner of that key and to verify messages from you, messages, yeah, from you to that person, to other people. So people will use your public key to verify messages that you send them. And a private key, which you keep secret and safe and it never goes on to the internet and it allows you to decrypt messages that people encrypt to you using your public key and to sign messages so that others can be sure that you made them. Algorithms that use, that separate public and private keys are more secure for several reasons. But the primary one is that the private key just never goes out onto the internet. In the case of PGP, it's also passphrase encrypted and even then, this is still not something that you'd ever put onto Dropbox or Facebook or whatever you kids are using these days to share files. If you must move it around, USB is the easiest and best way to do that. But then you wanna make sure that that USB stick is destroyed and everything else. Kill it with fire. This is how we're actually going to do this. So we're going to generate a new key, click the top left corner to do that. It's gonna fill in a lot of your information automatically. We're gonna make sure that we've picked the longest length. 4096 should be that number, but if there's a bigger one on your machine, use it instead. And then we're going to check expires, I unchecked it, but we're actually going to check it. Change the date to about a year out from now. And the reason that we do this is so that if you ever completely lose access to a key, it'll invalidate itself automatically after some amount of time. And you can change the expiration date, you can just right click on the key, your secret key, and change the expiration date at any time, you just need to unlock the key. But this means that it's sort of a dead man switch. It means that you're not accidentally leaving your key out so that people still think that it's a valid way of contacting you basically. So what can we do with this key? I'm going to pause here and make sure that everybody's got a key. All right, so now we have keys, what can we do with them? The piece of software that I gave you, automatically, if you use mail.app to send email, it's now got a couple of encryption tools in there. So one of them is to sign, one of them is to encrypt. You can now sign every outgoing email and it won't hurt anybody. And if you know that you're communicating with somebody who also has a key and you have that key handy, then you can encrypt to them and that's a good practice as well, just so that we've got more noise when the NSA is trying to crack encryption things. But the simplest thing that we can do that's not already configured for you is to sign git commits. So there's a little bit of configuration in here to do. The first is we need to tell git that we want it to sign all of the commits that we make. So from the terminal, this is how you make that happen. Then we need to tell git which key to sign with. But GPG is pretty smart. By default, it'll use the only private key that you've got, but it's still a good practice to have this in there. So I have my whole name and email address in here. GPG will find this just fine, but it makes a little bit more sense sometimes if you're having issues to just go ahead and use your key ID, which is the last eight characters in your fingerprint, which you can get by right clicking on your key to view details. And so what this does is every commit you make, you attach a signature object to, and those get pushed up automatically with git pushes and others who care about this stuff basically can verify that you are the right author. How do we do that? So verifying with git is not super difficult, especially if you use aliases. So git log show signatures is the simplest way to do this. So it's gonna print out in addition to the normal commit message and the commit shot and maybe the diff stat or the diff. It's gonna also include the GPG output for verifying when it verifies that the commit is correct. Git show will do the same thing, but just for a specific commit-ish. And then you can do git tag hyphen hyphen verify with a tag name to verify that a specific tag was done. So you'll see tags a little bit more often in the wild because it's easier to convince people that they should be signing tags than it is commits. Why would we do any of this stuff? Well, a signed commit says, I wrote this thing, here's proof. I wrote it and I thought it was good enough to include in this repository. And I've proven that somebody else didn't do this and said it was me. A signed tag says, I released this, here's proof. So it's almost the same thing, but I didn't necessarily write everything. All I did was probably run the tests and said this was ready to go, released a gem version or whatever. What this does for us is it gets your signature in as many places as possible. GPG can be configured to automatically download keys to verify signatures. And that means that you've got more ways to establish trust. So for example, if Aaron Patterson is signing all of his commits into Rails, you can be pretty sure that this person who's doing a lot of cool work is who you think tender love is. So you can say, well, I trust that this person is right, so I'm gonna go ahead and sign their keys, and then you know that anybody that key has signed, which would include me, is probably who they say they are by sort of a transit of trust. And frankly, it's super easy to do, so why wouldn't you do it? Signing and verifying gems. This is where we get into our RailsConf specific bit. First of all, there's no good way at all to do this. There is a way to sign gems, and it comes in this module, which is included in every Ruby installation over the last couple of years. It's not great. It uses some other algorithm that is, in my opinion, not as powerful. And it defaults to not verifying when you sign, or when you create gems, release gems, or install gems. So it's useless. What it does is it uses open SSL keys. So these are the same sort of keys that we use for SSL on the internet. Unfortunately, they're the same sort of keys that we use for SSL on the internet, which means that there's no centralized, there's no way to distribute them. You just get them along with the gem that's installed, or the website that you visit. And there's a centralized authority, a certificate authority. So you, so this isn't taking advantage of the web of trust that PGP provides, which is like, well, you trust Aaron, he trusts me, we're all good to go. It requires you to trust a certificate authority manually. In the case of SSL on the internet, HTTPS stuff, you've actually implicitly trusted all of the certificate authorities that matter to you by having a Mac computer, or having a Windows computer, or installing Chrome. They just do that for you. It's not a decision that you make, which is different in PGP, where you do make that decision explicitly. Private keys are not encrypted. This is not a limitation of open SSL. This is a limitation of gem security. I don't know why, but that's a thing. Keys are self-signed. So most of the time when you get a gem that is signed, it's going to be the signature file or the public key is actually just gonna sign itself. And so the only way that you can trust it is if you explicitly trust that one key. And even the root of the certificate authority has to self-sign to be valid in this silly, silly thing. Open SSL, don't use it. You need a trust path. So verifying a signature or a SHA is dearly meaningless if you can't trust that it's come from a person that you believe in. Just checking that they've signed something doesn't mean anything. It means that they know how to use open SSL or GPG. This is actually what we did at the beginning. We blindly trusted that the website that we downloaded software from was controlled by the people that we thought it was. But they were providing the SHA, the GPG signature, the key, and the software that was signed. So none of it is actually very useful. But it's the closest that we can get unless you actually know one of those maintainers. Or they're on the web of trust, which they are. So a package and a signature all come from the same source that can be faked by everyone. This is true of Gems. This is not really something that you can get around unless there's another way to also get this key. So in the case of Gems, there's really no other way to get the keys that you're verifying. In the case of GPG, we've got key servers. We've got people who upload their own keys. We've got people who give you a USB stick with their keys on them. There are no key servers for open SSL. And key servers are this basically distributed system of sort of like DNS where you upload your key and it propagates out to a bunch of different servers and then anybody can use their own server of choice to pull down a key. In the case of Gems, the keys and the cert chains are included in the gem tarball. You can't specify a system-wide trust. With GPG you can say, I will trust anybody who has any sort of signature or you can say, I only trust people who I've signed myself or you can say, if Derek says they're cool people, I believe it. Signatures are included in the gem. This is what gems look like when you untar them. So you've got each of these .gzip files and if they happen to be signed, which most gems aren't because this is difficult to do. And as I sort of made it clear, not super useful, then they include a signature file for each file as well. Required reading, if any of this is interesting to you, this gem stuff, this slide has a bunch of links on it. This is where I've distilled all of this information that I've just given you from. So sort of my citations as well. So backing up a bit, how do other people take care of these problems? Well, the most common and simplest way to do this is manually, just like we did when we installed GPG tools. It was an archive, so it's a single file that we could have gotten the shot from. And this is what most of the packages are doing for us automatically. Aptitude, homebrew, et cetera, automate this. So aptitude uses GPG to verify. Homebrew has a shot, so as long as you trust the homebrew package itself, then you can trust that the person who authored the recipe for installing a piece of software has downloaded the right piece of software, that the one that they expected to download. And RVM actually distributes Michael Pappas' personal key and automatically verifies that during installation. So to fix these problems for ourselves, we need some sort of automatic verification before installation. We should be verifying signatures, no matter what. Every time we install something, we should verify that it was correctly signed. That means that the person who signed it, the package hasn't been tampered with since the person who signed it signed it. It should be configurable to verify trust. So if I have a large web of trust myself, then I should say you should be verifying that the person who wrote this software somewhere in my web of trust. And if either of those checks fail, if you've configured trust or if the signature fails, the gem shouldn't install at all because it's not what we expect. It's not what we think it is, which means that it may be malicious. So we need stronger web of trust connections throughout the community. If we can verify one maintainer, we can probably trace paths to others. Conferences are a great way to build these cross-organization, interstate, or even transcontinental connections in the web of trust. Open-source companies could have centralized keys. So Thoughtbot actually has one of these. This is not how we use it. This is how I think we should use it and I have begun pushing for this. They should sign each maintainer's employees and contributors, so an external contributor who's doing a lot of work for us, keys. So at things like this, when we're in person, we should be verifying that we should be using this company key to verify other people, individuals' keys. And then also at these events, we can have Thoughtbot's key sign test double's key or AT&T's key, which means that if you have met me and Thoughtbot has signed my key and Test Double has signed Thoughtbot's key and Test Double has also signed Justin Searle's key and Justin Searle's release is a piece of software, you can verify with only four hops the maintainer is who they say they are and then you've got a web of trust connection. It's pretty cool. We need better tools support for all of this. So tools that we use, the big one is RubyGems. RubyGems solution is simple on paper, difficult to implement. We could use OpenPGP instead of OpenSSL. I plan to put my money where my mouth is and actually work on a gem plugin to do this to allow you to sign keys with PGP and verify them on installation. There is already a tool that does this but in my opinion it is too difficult to use so it won't see adoption. GitHub, Git already supports showing signatures. So GitHub could also do that without much more work. This is what Git by the way will output when you actually verify somebody's signature with show signature or with show log or show signatures on log or show. Having a standard way to claim social accounts. So this is a little bit difficult to see but you can see that there's a couple of highlighted user IDs on here. Both of them say at Caleb Thompson and then link to Twitter status or a GitHub repository where I make an assertion that I am the person who controls this account and this key. So by doing that you can be sure that somebody who controls GitHub and somebody who controls the key with this fingerprint are the same person. You can't be sure that they are Caleb Thompson because you haven't looked at my ID. You haven't met me but you do know that the key and the social account is connected. So connecting these two ideas we can say we could have GitHub show a badge like the Twitter verified icon that says yes this commit was signed and is correct because Caleb Thompson has uploaded his key and that key has signed this commit. It's great. People do things for badges, it's crazy but this is just a small thing that GitHub could be doing that would mean that five more people maybe start signing commits and that'd be pretty great. Signing keys. So this is, we've talked about signing keys. This is actually how we do it. So Mason is there. We're gonna need to help again. So signing a key is like signing a message. It uses the same mechanics internally but you're writing onto a signature file. It has a different semantic meaning. What you're doing is asserting that you've verified owner identity. So you've looked at somebody's driver's license or passport and the name on that document matches up to the name on the user IDs on the key. You're asserting that you've verified that you have the right key. So I gave you my key. I will later give you my keys fingerprint and with those two things you can be sure that you have the thing that I wanted you to have and you're asserting that that person has verified ownership of the key which means that they can unlock the private key and use it. This is uncommon to actually see done because it's sort of difficult but it boils down to once you sign a key you export it to a file, encrypt it and email it to the person by using the email on the user ID and then they can decrypt it, import it into their own key chain and upload it to a key server. Because that's a little bit complicated it doesn't happen super often but if we had tooling that made that easier then it could and it would mean that the web of trust is a little bit stronger. So signing a key establishes transitive trust. It announces to the world that if they trust you to verify these things they can trust the keys of the people you have signed because they are more likely to represent the people that they actually say. You haven't verified it yourself but you trust your friend to say that they are who they say they are. You've been introduced. All of this is fundamental to the web of trust. A word that I've said a lot, I have a picture. This is a web of trust. At the center because it's mine, you see me but all of these lines are connections are signatures that I've made with other people. And the more closely we're related in the web of trust the closer people are. This one's a little bit older. My new one is taller. It's pretty cool. But it's just fun to like see graphs. I like graphs of myself and so I sign a lot of keys. But one thing that you can see here is I apologize for dotting but this is Michael's key. Michael has signed George's key. We're all co-workers. I haven't verified George's key in person because he lives in Stockholm, New York now. But because Mike has signed it and I trust Mike to verify George's identity then I can be reasonably sure that when I communicate with George's private key or public key, he is who he says he is. It's great. So signing a key with the GPG key chain. This is gonna work now. So the first thing that we need to do is get the key. I've already given you mine. It was included on the USB stick. But usually people will upload these to the internet somewhere, probably on their own server. Include them in a header on emails or upload them to key servers. And if they've uploaded them to the key server then you can find them by searching like this. So if you do command F or look up key right there, this box will pop up. You can search just about, you can basically just search for a name or an email address. It'll pop up a list of addresses. If you've got this person next to you then they can verify who they are. Otherwise you can probably guess correctly. Once you have that key, you can right click and view details and that'll pop out this side window. And what you need to do is confirm that that long string of text which you actually have to expand the window to see because software matches this. This is my fingerprint. And as I mentioned earlier, the last four digits are the key ID. So if you're searching for me you could search just on this or you could search for my name and that would get you the right key. So we're doing this now. Okay, next we're gonna right click again and we're going to sign key. It's gonna pop up a window like this. You are going to select your secret key. It's probably already pre-selected. And you're going to say that you've done careful checking from the other drop down. And the reason that you're gonna say that is that I'm going to walk around with my ID and I'm gonna show you that I am who I say I am. And there's not really much more careful checking that you could do than to check somebody's ID. You could do a background search, I guess, but it doesn't help. You're just verifying the person is who they say they are. You're saying that name is the name on your screen. So the other options are, I haven't verified, or I won't say. And that means that you may, you've done some amount of verification but you don't want to explicitly state how much you've done. The level above that is I have done no verification. If you have done no verification you should not be signing a key. The level above that is I've done casual verification or some verification. That means you're not playing, are you? That means that maybe somebody handed you an ID or maybe somebody has been your friend and you are pretty sure you know who they are. You've never actually looked at their ID, but whatever, you're willing to sign. That's the level that means that. And then careful checking means that you've looked at a piece of state-issued identification. Does anybody still need this? And you're ready to sign. So signing a key is sort of like going to court and saying yeah, that person is Caleb. Don't check that, I have no idea. Also don't check the signature expires. That's more for certificate authority style things that temporarily state that you're probably the right person, so that's not useful. So all we're doing is filling out these two things and then unchecking those boxes. And we can generate signature. All right, so after we have verified or we have signed we can go ahead and upload the key to the key server. So you can right click again and send public key to the key server. So do this now for both yourself and for me. Okay, we're done. This is the end of the talk.