 Okay. Great. Okay. So, yeah. So, I'm going to start with a quick overview of Sixdoor and a demo, and then talk about one of our latest projects called Git Sign, which Billy over here has been working on, which is using Sixdoor to sign Git commits, and then just a little bit about what we're working on in the community. So, before we talk about Sixdoor, I just wanted to talk about signatures in general and kind of what signatures guarantee. So, the main purpose of a signature is to guarantee that software has not been changed since it was signed. So, if the verification comes out correct, we can be sure that the software has not been tampered with since the signature happened. We can also use signatures to know what producers a piece of software came from, and they can actually be used as points of validation in a larger pipeline. So, I think a lot of times we think about signatures as being signed by a maintainer and then verified by an end user, but you can also think about using signatures as part of a build pipeline, where maybe you can verify certain attestations along the build test. So, if signatures are so useful, then why isn't everyone verifying their software today? And the reason for this is that signing software is really hard. So, we have this key management kind of problem embedded into signing software traditionally where you would use like a private public key pair. So, the thing about having a private key pair as a maintainer is that keeping long-lived private keys is not easy. Safe is not easy. It kind of assumes that you're not going to lose them, and it also means that they're not going to get stolen. And so, it kind of puts a lot of the onus on the maintainer to keep their private keys safe. It also puts the bird on the maintainer to figure out how to distribute their public keys to end users, and then it also means that end users have to figure out how to verify software before they use it themselves. And this can kind of be really difficult to do, especially if you just want to run software and you don't want to think too hard about how to verify it first. Code signing certificates are an option if you don't want to manage public-private key pairs, but often you have to pay for these types of certificates, and that might not be an option for everyone, especially maybe like an open-source project. And so, that kind of puts us all in the position that this is fine talk where we just sort of sit there and it's too hard to get out of the fire, so we just accept it. And this is where Sigstore comes in. So, the good news is that you can use Sigstore today for signing your software, and you don't even actually have to manage keys if you don't want to. So, how does this work? So, part of my drawing skills, you can tell I'm a really good artist because I have to label every single thing. But as a maintainer, the nice thing with Sigstore is all you need is your software that maybe you've already compiled and Cosign, which is our CLI tool used for signing and verifying software. So, you can see the maintainer doesn't have any public or private keys on them, just the CLI tool and their software. So, what do they do with this? So, with Cosign, you can run a simple Cosign sign and sign any sort of software that you have. And under the hood, Cosign is going to use the OpenID Connect protocol to verify your identity. So, it's going to basically take you to this page in your browser, log in to Sigstore, where you're going to log in with your email address. And we support a lot of the big providers like GitHub, Google and Microsoft. You basically will log in with your email and Cosign will retrieve the identity token associated with this protocol. And that's basically how you prove who you are by signing in with your email address. This is where one of the core Sigstore services comes into play. So, this service is called Foolsio, our code signing certificate authority. Foolsio is completely free and accessible to use for the public. And what Cosign is going to do is it's actually going to request a certificate from the Foolsio certificate authority. Foolsio is going to verify that identity token and then embed the associated email address in the certificate. So, you know that the certificate has been issued to this particular email address. Under the hood, Cosign is also going to generate an ephemeral public-private key pair. It's going to use the private key to sign the software and then that public key will also be embedded in the certificate. The ephemeral key pair actually just always lives in memory, never hits disk. So, we kind of call this keyless signing with keyless in quotations because while there is a key pair, you really don't have to think about it or worry about it. It all sort of happens under the hood and then disappears once the signing is done. So, at this point, we kind of, with Foolsio, we kind of have removed the need for public-private keys and we're just using these free code signing certificates instead. And then this is where the final core Sigstore service comes into play. So, we have free core, which is append-only immutable transparency log. So, once you add entries into the transparency log, they can't be changed and they're there forever and they're completely publicly accessible. So, anyone can kind of look in and see what's in an entry, get all the information about it. So, what Cosin will do once it's got the signature and the certificate is store both of those things as an entry in the transparency log. And this is kind of how we solve the key distribution problem that I was talking about earlier. So, instead of the maintainer having to figure out how do I get my public keys to my end users, they're just going to store the signature and certificate in the log, which is publicly available for everyone. It's basically a centralized place to find this information that we need. So, signatures are great, but it's not really useful unless we actually verify them. You could sign everything in the world, but it's not really going to matter if nobody is doing anything about it. And so, as an end user, end user is different because they're wearing a hat. As an end user, really easily you just need Cosi and you need that software and you can do your verification. So, under the hood, Cosin's going to retrieve that entry from the transparency log, verify the signature against the public key that was embedded in the certificate, make sure that the signature happened while the certificate was still valid, and it'll print out a nice, like, verified, okay, if everything works out. And so, basically, the only thing the end user really has to do is take a look at the identity embedded in the certificate and decide if they trust it. So, yeah, simplifies a lot of this process. So, signing with Cosin is pretty easy. I've got some of the sample commands here. So, you can sign images, anything that lives in an OCI registry. There's also support for signing arbitrary files or blobs, and then specific support for signing attestations and S-bombs. So, if you have an attestation or an S-bomb, especially associated with an OCI image, you can actually sign it and Cosin will upload it to your OCI registry where it'll live alongside the image. Verifying pretty much exactly the same, but with verification as an end user, run verify for images, verify blob for blobs, and verify attestation for attestations and S-bombs. And then we actually have a six-door policy controller as well. So, this will basically, the policy controller is basically a Kubernetes admission webhook which you can run in your cluster and supports Q and Rego policy definitions. So, with this you can basically say, I only want to accept images into my cluster that have been signed or have been signed by this particular identity or images that come with an attestation. So, this is basically like the verification piece for Kubernetes. So, I'll do a quick demo. Hopefully this works. Just a siding like an image that I've already pushed to my own registry. So, at the moment the key list in quotation, signing flow is still experimental. So, I'm going to set this experimental flag. And if you don't want to rely on experimental features at the moment, you can totally just bring your own public-private key pair as you normally would or use like a key KMS system. But I am just going to run cosine side and then sign my image. You get this little warning that your email address will be stored in a public transparency log so everyone will be able to see it. And I'm just going to sign in with my email. Now, under the hood, Cosens can do everything that I just showed in my amazing artwork. It's going to request a certificate from full CO and then store an entry in the log. So, you can actually take a look at this entry. And we should be able to see the base. So, this is the base 64 encoded certificate that was issued and the signature as well. So, say I have an attestation as well that basically gives some information about how this image was built. So, I have this custom Solacea Providence attestation. It's not super helpful. I built the image with Docker. But with Cosens, we can actually sign this attestation and then store it alongside the image. So, it's pretty easy. Co-sign a test. I'm going to pass in the name of my image, pass in the attestation, and then say that it's an attestation of type Solacea Providence. And we're going to go through the same flow. So, we have signed our attestation, stored an entry in the transparency log, and now everything is kind of available for people to verify. So, as an end user, I should have brought a hat. I could have put it on now. Thank you. Thank you. As an end user, all I have to do is just co-sign verify. Pass in the name of the image, and it'll grab the entry from the transparency log, do all the verification, make sure the certificate is valid, and you can see that the certificate has been issued to me. So, at this point, I just have to decide if Priya at chengar.dev is trustworthy. I guess that'll be a fun exercise for all of you later. And then we can also verify the attestation with the verify attestation command. I'm going to remember to pipe this one, so it looks a little prettier. And, yeah, it looks like it checked out. A similar really certificate subject is me. It's issued by Google. So, quick demo of how you can really easily sign and verify things with co-sign. Cool. So, yeah, don't keep track of your private key. Keep track of your email password instead. So, okay, I'm going to move on to one of our newest projects in the 6-door ecosystem, which is called GitSign. So, you can use GitSign to sign your Git commits using that same keyless signing flow that we just saw with 6-door. Once configured, you can either choose to sign certain commits, or you can set it up to sign commits by default. And it's really cool because you can basically have this additional guarantee that the person who actually wrote the code also owns the email address that was signed off with. Philly, who has been working on this project, I stole this little screenshot of his commit. So, at the moment, there are a couple of limitations with GitSign. The 6-door CA route is not in the GitHub Trust route, so the commits still kind of show up as unverified. But hopefully that will be worked on in the future. And at the moment, anyone with access to the commit can still do the verification and make sure that the commit was, and see what email a commit was actually signed with. Another quick demo of this. So, I have a little repo. I'll just add in a little file that we can add. And I'm going to sign it, or commit it, sorry. And we go through the same flow. I'll sign in with my email. And we're good. The commit is done. So, if I wanted to actually see the signature on this commit now, I can do this command. And under the hood, GitSign is going to grab their relevant entry from the transparency log. Say that the certificate was issued by 6-door, that it was made by me, pre-chainguard.dev, and it'll just verify everything. We can actually take a look at the certificate, too, which I have stored somewhere in here, because I can never remember this command. And certificate is pretty much what you would expect. The subject is me, issued by Google, by 6-door, and valid for about 10 minutes, so I can do that. Yeah. We can actually do the verification ourselves with Cosign Verify Blob as well. So, I can grab the required entry from Recor, print it out, and we can see what's in it. So it's kind of the same thing as what we saw before, the encoded certificate and the associated signature. If we pull the signature and the certificate out, we can use Cosign Verify Blob to actually verify the commit shot here. So we're going to pass in the certificate, the signature, and then the commit shot, and this should hopefully verify. Yeah. And so it looks like it all worked out, and we know that the commit was signed by me. So, wrapping up, I just wanted to talk a little bit about what I and a bunch of people in this room have been working on 6-door GA. We're working on general availability for the core 6-door services, so it's a lot of work to do, but it's moving along really well. And some cool things that'll come with 6-door GA. The keyless signing, which I just demoed, will no longer be experimental, so you won't have to set that experimental flag anymore. We'll have to find SLAs for core 6-door services and increased reliability. So, something to look forward to in the coming months. Thank you, everyone. If you're interested in 6-door at all or in GA, there's any meeting which happens every Tuesday. Yeah. Thank you so much.