 First of all, welcome. Thank you for taking time out of your busy schedule to listen to my rant. Hopefully, it will be a fun session. I titled it Safe and Signed Git Commits with PGP. Like our wordplay on Safe and Sound. You get it, right? So this is something we started. I was working for a large telecom provider in Norway. They wanted us to explore signing of the Git Commits because consultants were coming and going from the project all the time, and they were like, well, we'd really like to be sure that the commits are from people that are actually on the project. And I thought, well, GitHub will surely make sure that the person is correct, but it turns out it's pretty easy to fake that. So, well, we went looking for solutions and we found that PGP was easily supported, so we went in with air. So first of all, a little bit about me. I'm Thomas. Hi. I work for Tietoevery. It's a consultancy in the Nordics and we're spread out over, I guess, 20 countries. So I become quite a grumpy old man, frequently yelling at the clouds and frequently sticking my nose where it doesn't belong. So that's why I made this call, this talk, sorry. So I work at Tietoevery, as I said. We are 27,000 people, I think, so we're spread out all over and everyone is basically doing their own things. It's not a lot of cooperation between the different projects, but that's okay. So they have graciously sponsored me to go to this conference and other conferences this fall. And also I shouldn't mention we're hiring, of course. So I love all things open source and I'm an eager advocate for open source. So this is kind of my 10% project that I do besides being a mobile developer during the day. I'm trying to raise awareness about how we should sustainably consume and contribute back to open source and also how we should create our own open source and inner source. So I basically love everything that runs on electricity. So that makes me purchase stuff from time to time that I probably shouldn't have. So I just want to gouge like the audience here. Who owns no Raspberry Pi? Who don't know what a Raspberry Pi is and how none of them? There are no hands up. Who has one Raspberry Pi? There are some hands. Who has two and three? There we go. Four? Okay. Five then? No one with five. I think I'm at three or something right now, so right in the middle there. Raspberry Pi's are beautiful. I don't really use them for anything, but they're so cool, so I just need to have them around. So that's fun. Well, enough about me. Well, you can contact me. I should mention that if you like. If you have any questions after this, we'll of course do a Q&A at the end if I have time. I haven't really practiced or rehearsed the timing here, so we'll see how much time I spend. But I will get queues from the back when it's over. It's time out. So we'll see. So this is the thing I want to talk about. We'll do a very light version about cryptography, because I guess not everyone are hardcore developers, but might need to know something about how cryptography works. So we'll do just no deep dive at all, just over the covers, above the covers. Look at a little bit about how pretty good privacy, which is PGP, how it came to be, and also later the GNU Privacy Guard. There are some fun with acronyms. The open source communities love their acronyms. And we'll look at a little bit how you can publish your keys and have other people sign them and vouch for your identity. And also, we could be using GPG for encrypting files and stuff like that, but I have left that part out since I'm not sure that we'll get through everything. If we have time, I'll briefly pop by that. Let's see. So very, very, very short version of how cryptography works. You have a, let's see if I have a pointer here. There is a pointer, a laser pointer. You can see that? You can see that, yeah. So you have a plain text that you want to encrypt. You use a key and you pass it through some algorithm, black box, don't know what it is, and out comes the ciphertext. So that's basically how it works. The reverse is the exact the same. You take the ciphertext and the same key and you pass it through the same algorithm and out comes the plain text. There we go. So this, we can use this for a lot of things, as you know. So we'll go through some of the concepts that make out, make up cryptography. And this is like, this is the symmetric one. So we'll do the asymmetric one and compare them. So symmetric encryption, one of the standards are called AES. Not really important here. The other is asymmetric. So the comparison would be that the symmetric encryption uses the same key for both encryption and decryption, and we can combine these. Asymmetric encryption uses two keys. While you keep one private, you can publish the other one, and we can do some things with that. And comparatively, you use shorter keys for symmetric encryption because it's stronger. It's not really, I can't really say that, but I'll do anyway for comparison. So with the RSA, the asymmetric encryption, you use longer keys then. And as symmetric encryption is less computationally intensive, you will use that for larger batches of data. And you will use asymmetric encryption and signing for smaller batches of data, like encrypting asymmetric key, like we'll see. So in common for this, it's like key management is the hard part for symmetric encryption. It's hard to distribute the key safely to someone you don't know because, well, you don't know them. With asymmetric encryption, it's you have your private key and you should keep that private forever, but if you don't, well, you're kind of screwed. So if someone gets hold of your private key, they can use it to decrypt stuff that you have encrypted before. Not good. So then a very, very short version of how public key cryptography works. You generate a key pair on your computer, preferably. The private key should never leave it. There's the point. The private key should never leave your computer. You don't copy it. You don't move it anywhere, but you keep it safe. Then you can post your public key on your website or public key server for everyone to download. Again, your friends can verify and you can verify that it's really your key and then they can download it and sign it. How you verify that is part of the distribution problem. Yeah, you can just call someone and say, hey, this is my key. Can you please verify it? And if they do, they're, well, they could be... They don't really know who they're talking to, right? There's a little bit of a problem there, but usually it works out well because you can usually verify someone. If there's someone you don't know, then it's not as easy. But with friends, it's easier. So that's the scope of this thing, is that we are using it inside of a team. So when you're working on a software project, you're using it inside of a team, so that makes it a whole lot easier because, well, you know the people on the team. So you can also make a certificate with that key and it holds your name and other details and by signing that using your private key, it's provable that the certificate is authentic because, well, you signed it, so you're the only one who can do that. So that's a good thing about this. It's very easy to do. It requires no infrastructure at all. And then if someone wants to send you a message, they'll download your public key. They can see it's been signed by other people because, well, you're forming a web of trust as I'm signing Marno's key, and Marno is signing someone else's key. I can implicitly trust them because I trust Marno, right? Marno is my friend right here. Hi. I'll be using you a lot. So, well, if you encrypt the message, only your private key can decrypt it, basically. So as I said, for larger datasets, you can... There's something wrong with the font there. I don't know. Something is skewed. It doesn't show up here. Okay, well, you can use the symmetric key to encrypt your data. So if you follow this schematic, you have a piece of data that you'd like to encrypt, and it's a big piece of data, so you then generate a random key, and you use a good pseudo-number... pseudo-number random... pseudo-random number generator. PRNG, yeah. To do that, so you're sure that it doesn't contain any patterns, and it's not easily forged or breakable. So by using that random key, you encrypt the data with this key, and then you also encrypt the key with your private... I mean, the receiver's public key. You don't have their private key, right? But you can encrypt this symmetric key with their public key, and then you can send the encrypted data and the encrypted key to them in an encrypted message. So the other side of the thing is that they take the encrypted message, they apply their private key to the encrypted symmetric key, and thereby they're getting the symmetric key decrypted, and then they can apply that using the symmetric key algorithm to the message, and they get the plaintext. So this is kind of best of both worlds where you get the lighter encryption, symmetric encryption for the large dataset, and you also solve the problem of distributing the keys. So... Any more points there? No, we are done. Okay, I was supposed to click through this as well. It just says the same thing that I've been saying now. Good. So there's another concept that we could talk about for a little while. It's a concept of a hash function. It's a one-way function. So as you can see, in this example I'm doing... Echoing a hello world into a short 256-sum tool. It returns a hash, and I do the same thing with almost the same message, but if you notice that the w is now a small one, it returns a completely different message. So any small change will completely change the hash, so it's impossible to guess what it is. Well, theoretically impossible. So what you can... Okay, let's see. Return the same ciphertext for any... Anytime you do this, you will get the same hash, right? Anytime you send the same message to the hash function, you will get the same hash back. So changing a single character completely changes it. And there's no really any conventional way to return this, so reversing it doesn't really apply. But if you use a weak hash function, like what's it called, a 40-bit DES? No, not DES. Anyway, a weak hash will of course be susceptible to a brute force attack where you can try every single possible value and guess the original message from that. But the cool thing is a matching hash value. If you calculate the hash value again and it matches, it's proof that this message has not been altered. So that's what we're using for signing. Right. Quickly again, signing is how you do this, is that you want to enable other people to verify that message really came from you. So what you do is that you write a message and you calculate its hash value. Then you can, with your private key, you can encrypt that hash value. And if it's possible to decrypt it with your public key, then they know that it came from you. If the hash doesn't match, it's been changed and it wasn't the original match hash, so it's not from you. And then it can't be trusted. So yeah, again, going through this a little bit quickly. But I guess it's something most people know, but maybe don't think about. So I guess it's okay to have a little repeating of it. So let's see. Yes, that's the last point. So this is what a public key looked like. I guess you have seen it before. My public key is placed on the Keybase. It's an online platform. It's open source, of course. And well, it's just a nice way to publish your keys. And it also has a lot of other functions. So you can go to Keybase.io and slash angunis, which is, yes, it's a game character I made once upon a time. So that's just a name. But that's me, and you'll find it there and you'll see the exact same key that I listed here, I think. Yeah, probably not. But this is how I show the key. The command is on top there. Use GPG and export it. And it's connected to the mail address. You can have many, but yeah, that's not going there. Pretty good privacy. It's a fun acronym. And it was made in the 90s by a guy called Phil Zimmerman, leveraging, well, cryptography and assigning, hashing algorithms to encrypt and decrypt text in email and file and whole disks and whatever. And this software was made, or the protocol and how it works, it was made into an open PGP standard. So it's the RFC4880. If anyone's interested in that, you'll find it on the internet. And I mentioned before, it's a web of trust model other than the hierarchical models of certificates like we know from SSL or TLS certificates. This is more based on I'm signing your key and you're signing my key and we're doing the web of trust. So then later, the Free Software Foundation created GPG. Also based on the same thing because the original package was, I guess, proprietary software by Symantec. So the Free Software Foundation wanted to have an open source version, so they did this. And Werner Koch was the guy who did that. Same thing, it's used for encrypting and decrypting. And I found that poor Werner almost went bankrupt doing this because he had no funding and it was like doing it in a spare time but the popularity exploded and, yeah, we know these sad stories, they're all over the internet. So support your local open source guy. Quickly about GPG, installing it, it's not hard. Whether your favorite package manager is, yeah, any of them, I guess GPG has been ported to every known platform known to man. So you just install it. I go brew, install GPG and I'm done. It generates a key ring for you and all the keys that you later generate there will be put into a database and it's quite transparent once it's set up. You can export it, of course, and move it to your new computer if you like and you can download other people's keys and you can sign and do all that thing. So instead of now showing how it's done, I'm just going to skip that. So I hope it's okay. So this part about signing other people's keys, right? You need a way to verify that they are really who they say they are. So people have been arranging key signing parties. So the top photo is basically what you think a key signing party looks like and the bottom one is what it actually looks like. A bunch of guys with paper and this is my key, can you verify that and here's my key, yeah. So it works, I guess. It doesn't really scale globally, but I met a guy a few months back. His claim to fame, as he said, was that he had a PGP key from the 90s somewhere signed by the original author of GPG. So that was like, yes, this is my thing. Just keeping your keys for that many years is kind of good, I think. So yes, again, mentioning the Web of Trust because you can accumulate a lot of signatures over time and the more people who have signed your key, the more likely it's trustable. And so, well, again, the Web of Trust, it's like I tried to explain earlier, if you're Ingo and you trust Eva, then you can also trust Manuel Stranger because Eva trusts him. You can trust that he is who he says he is, but you can't really trust that he has good intentions, right? But the Web of Trust is built like that. So, oh, it's just a key signing party again. I thought we were done with that, my problem. Well, within a team, like we did in the client software, in the software team that we were working, we just signed each other's keys and we uploaded them to these key servers. There are several of them on the internet. You can choose which one you want to trust and you can upload your keys there. And I have a quick example also how another team did this. It's CalSight, I guess. I don't know who they are, but we can trust them to at least let's see now if we can just pick that up. Oh, I got a new version. That's nice. Yes, I would like to join. No, you can see this. Okay, so I'll try to, for a moment, just stop the presentation. And we're back and we have issues to decode. And this file isn't formatted. It's not highlighted as it should be, so never mind the coloring. But this team has, like, gathered all their keys. You can just list them up here in one file. They upload that to their website, and anyone who needs to verify all the keys for all the people in the team can download that file and see their thumbprints and the full keys as well. And this can, of course, be machine read, and you can import this into your key ring and you can sign everyone's keys once you verify them. And so on. It works pretty well, I guess. So when people leave the team, they remove their key, and basically everything they've signed before will still be signed by them, but the key will still be there, but it won't be one part of the team. So going back to the presentation, I bet it's going to reset. Let's see. No, it didn't. Excellent. So there we are. Is this making sense, by the way? Yeah, good. There's at least one node. You got my back mono. So that's good. So it turns out there's no safety check when GitHub... Well, if you upload your... You push your commits to GitHub, there's no safety check that the SSH key that you're pushing with actually is any kind of match to your user on the GitHub account. So if I wrote another name and email address, I could easily forge a commit like that. And in GitHub, it would be that person's profile image if he's known or not. Her is known, she is known. So it would look like them, and their name would be right on the commit. So that's a kind of... Well, it's not really like a security breach, but it's confusing, and it could be leveraged, I guess, for malicious purposes. That's the point I was making. So, and there it is, and that one. We tested it on GitHub Enterprise. So, well, there are some issues about this. On the internet, you can go and find and read about. So it's a real thing. But then, we can also... With the GitHub Enterprise, you can enforce signed commits and branch protection. So you're not allowed to commit directly to the main branch, and also you have to sign all the commits. So if you try to push an unsigned commit, it will just say, no way. This makes it a little harder because you can't go in the web UI and just merge things. You have to pull it down and merge it locally because that commit also has to be signed, of course. And again, every team member, public keys, shared, signing. How many of these are there? There we go. Yeah, that's the last point there. Minor inconvenience. Well, it's not a big deal, and you should also not just merge things quickly, so you should really pay attention to what you're doing and download it and actually check where all the things are changed. So, and one point is, yeah, once you set this up, you can start it because Git will just sign it for you and as a user, you're just doing the exact same commit as before. There is a parameter like dash big S where you can, capital S, where you can force it to sign a single commit, but you can also use that setup in the configuration that it should always commit. I mean always sign the commit. So that's nothing you have to think about. So enforcing this on the server side, unfortunately the ordinary GitHub will not have the enforcement. It's only enterprise and protein plans that have that. GitLab does it right, so everything can be signed. You can force signing and I also check the GITI. I don't know GitT. I don't know if anyone uses that, but it will also do the same signing like force the signing to be possible. So that's good, right? But I guess you could, even if you just have an ordinary GitHub account, you can make it like a list of those public keys like I showed before and you can have the build process break if there's unsigned commits or there are commits that don't belong there because the public key is not in the list. So I haven't actually tried that, but I guess it should be an easy scripting problem to solve. And possibly there is already GitHub actions that can do this for you. There are a lot of those I see around the world. There we have the pros and the cons. GPG has a reputation of not being very user friendly, but it's like any other CLI once you start using it. I think it works great. It's quite okay, but it's got some bad reps. Some people don't like it. I was at a talk yesterday. He was talking about Git sign, which is another way to sign your Git commits with using ephemeral keys and you don't really have the key locally either. So you're just generating the key through a process. So that looked good and cool, but there was the login issue. Like login to generate new keys and stuff like that. So there's some give and take, some good and some bad about that as well, I guess. But yeah, other things, it's a little more work to complete a PR because you have to download and merge locally. Key management, still the weakest link because if your computer gets stolen or broken into and all your keys are in the slash SSH directory, then well, that's a problem. You still have no guarantee that a commit is legit. I set up that with a question mark because while there are no guarantees in software, you can be pretty sure that it's legit, but well, there's always something and you still don't know the code. It's bug free, of course. So there's that. But on the other hand, you can't really fake the commits anymore because once you demand signing of them and once you have a list of people you trust within your team and you do that, well, I don't see how that could be faked then because it would show up that you're trying to be someone you're not. All of this is, of course, completely free and open source and transparent. So it works pretty well, I think. We never had any issues with it and we used it quite extensively. So well, that's that. So I included at the end here a little bit more about the advanced key usage because if you're really serious about this, you will make your master key and you will write it on paper and you'll lock it in a safe for different keys for different usage, for code signing, for email, for disk encryption and they can all be linked to your main key. So that's hardening it even better and disarming or locking your master keys. You disarm it so that it doesn't contain the private key anymore. So even if someone stole your computer, they couldn't get your master private key. You can also create revocation certificates. I'm not sure how you would distribute those, but possibly within your team. That's doable if you can just, you can commit it to your Git repo, I guess. And then there's the moving of your GPG installation. You can take everything with you, of course, move to a new computer. So that's also a little more advanced topic. I don't have time for that to go into that now. And then it's when you start using this and you start using it and for a while you've been using it and then you realize that, no, we have to stop and we have to go back. So you may have to rethink the solution once you really understand how it works. But it should be possible to then just remove the keys that you already had and generate new ones and do it right instead of having the one key. Then you're making a master key and you're making a sub key for signing the Git commits in that project and that project and that project and you can go on and on, so many keys. How many keys do you want? And also the issue of offline key safety, there's one thing to keep it private, but the other thing is if you drop your computer and the hard disk dies, then you have to throw no fault of your own. You don't have the private key anymore. There have been some Bitcoin wallets, I think, that have had some issues around that, people searching in the junkyard for lost hard drives. Well, I think using a vault tool like HashiCorp Vault or Azure Key Vault or something like that, that should take care of that. You can store keys in there and they're pretty safe. So if that's not safe enough, of course, integrate a hardware security module like an HSM and really go to town on that. But I guess that really is so secure that we have so many other problems to solve that. That's okay. So that's... I want to do some Q&A on the end here, so that's all I had time for. Thank you for listening. If there are any questions, we can take those now. And if you want to reach out to me, it's also the email address at the front, but I'm on Twitter, my last name on Twitter. And I'm a signal user. I don't know if you use Signal. It's a great messaging app. I made a group there. So if you scan that QR code, you should pop right into the group. It's like a lobby where I can vet people and take them further into my domain of people I know. You can verify identity, right? Trust, but verify. So any comments? Yes, in the back. Oh, yes. The question is how does it really work with Git? Git has already support for GPG. There's a configuration command you write and just say this is the program. Point to the program. GPG and Git understand each other, so it just uses it. You also add the key that you want to sign that particular repo with in the config, so it will use that. So it's pretty easy to set up and pretty transparent. Good. Any other comments or questions? Yes, Marno. Yes, so the question is with the team that we were on and the throughput of people coming in and leaving the team, how do they manage that? Yes. I think it was like someone had an idea. We should sign commits and then they threw it all over to us and we said, okay, we can do it like this and they said, okay, good, let's go, let's move. So everything was done in Microsoft Azure, so the Active Directory identity thing was not connected to this, but people coming and leaving were controlled by their access to the Azure. So when we are signing commits as well, then we are like doubling up on the security, so I guess they thought it just a good thing to do. That answers your question. Good, thank you. Anyone else? Can't really see? No questions? Okay then. Then I think we're done with six minutes to go. Thank you.