 All right, hello everyone. I'm Lily Sturman. I'm a senior software engineer at Red Hat and we have 10 action packed minutes to talk about Rust in supply chain security with Sigstore and Ferris, the Rust mascot. So why are we all here? We are here today because we care about securing the open source supply chain in software and open source software. And I won't belabor this too much but I do want to set a little bit of context. So we are here because we know that the software supply chain can be quite complex and we know that each step in this chain matters because each step can impact the end resulting application. So what we don't want is those nasty green things on the screen representing vulnerabilities to enter any part of the supply chain and end up in the end product or application. So that is why Sigstore is here. Sigstore aims to make software signing ubiquitous, aims to make the signing of artifacts involved in the software supply chain ubiquitous. And it does so by offering all of these tools that the other talks today have already done a great job of summing up so I'm not going to go into depth on each of them. Thank you to the previous speakers who went into those deep dives that were really good on these technologies. I do want to point out that if you go to github.com slash Sigstore you will see an interesting phenomenon which is that under pinned repositories we now have several repositories that are language specific. So Rust is not the only one. We've got, for example, Sigstore Python, Sigstore Java. And the idea behind these is that in order to make signing more ubiquitous we want to offer these libraries to developers who are coding in all of these different languages so they can pull that in to their source code and use these tools and make them available for a wider variety of use cases. So why Rust, though? Well, obviously it's because it's the language with the cutest mascot. That is not the only reason. So traditionally there was this awkward tension between when you're choosing a programming language you had to make the choice between languages that are speedy and reliable in their performance and are really good for systems programming for that reason versus other languages that have memory safety capabilities through mechanisms like garbage collection but are much less performant and that's not really a choice that anyone wants to make. So Rust actually offers the best of both of these worlds. It has good reliable performance and also built in memory safety mechanisms enforced by the compiler among many other things that it offers. So this is why many security conscious projects today are already using Rust in some capacity and this was the idea behind making SigStore and some of the SigStore tools available in Rust so that they can be pulled in as a library into those projects. And this is why we have introduced SigStore RS. This is obviously complementary to the original tools which are still available in Golang and these other language tools that I pointed out earlier as well. So we have, even though we're still very much an active development, we have a lot of features available that people can already use. For example, we have signature verification for OCI images. We've got integration with Fulcio using the OIDC flow. And recently in the past month or two we've actually now got a key interface that has key generation and signing for blobs and we've also got integration with the Recore transparency log. So that is pretty exciting. And the other thing that I noticed when I was creating this slide is that the last time I gave a slightly different version of this talk which was just like two months ago, the crates.io downloads for SigStore RS were actually I think in the low 1,000 so that's actually a 5x improvement since that time. So that's pretty cool. Ferris is really happy about it. So the moment that we have been waiting for, we are going to show a quick demo and first of all please tell me whether I should make this larger or if you can see it. Thumbs up for I can see it well. Okay, great. Thank you. You all actually respond. So I will first explain. We have basically a demo repository that we call Ferris sign. It is not part of SigStore but it pulls in the SigStore RS library to basically show how it can be used and we're going to go through a flow that will take an example file, generate some ephemeral piece to sign it. We're going to go through the full SEO flow that we covered in the earlier talk. So we're going to get a full SEO signing certificate and create a re-core entry that has the signature and the signing certificate embedded in there. Then we're going to turn right around and we're going to do a verification of that same blob using the information from the re-core entry that we're going to pull back down. I do want to point out just for the purposes of this demo, we're not going through the six-step verification that you should do if you are actually being very security conscious that we were talking about in the earlier talk. This is really just going to extract the signature and public key and verify that the signature is correct just to show the full SEO and the re-core integration in SigStore RS currently. So first, we're going to run this command and what you see is that we will first sign. We're going to sign just an example file. This could be anything on the system. I think this says foo in it, but we're going to pretend that it's important and we're going to sign it and then this flag is telling us that afterwards we will also verify it and these other two flags at the end are optional, but they basically dump out the full SEO signing certificate as well as the signature in case we want to look at them. But we're going to just ignore that because we're going to get that same data from the re-core entry that we will upload. So here we have the OIDC flow. I'm going to use my credentials to log in through GitHub. This will give us the full SEO signing certificate and you see there is a lot of output here. So we're just going to go through it and see what happened. So this was the OIDC and we have received an OIDC token for the email. This is my email that you see here. We request and we get a signing certificate from full SEO that has the email embedded in it. We dump out the certificate data and the signature to the local system and then we bundle this all up and send it to re-core with a created entry. So this is going through six store RS creating this entry for us. We've got lots of data here. I do want to point out the UUID so it ends with an FAA2. That's what we use to pull this back down. Now we're going to switch and do the verification using this UUID of the re-core entry. We pull down that re-core entry and then what we can do is parse out the full SEO signing certificate and the signature and so those are dumped here on the screen so that you can visually see what happened. This is the certificate. It's in the re-core, hash-re-core, hash-re-core de-entry as the public key. We parse the certificate. We get this public key and then we use that to see that our blob was signed correctly and as you can see verification did succeed, which is fantastic. That's what we want to see. So that is one of several flows that we can go through. This one was nice, I thought, because it shows both the re-core and full SEO integration and that's pretty much it unless I don't know if I really have three minutes. Okay, okay. All right, there's a shorter demo but I think if I start that we're going to run out of time halfway through. Okay, let us slightly go off script and see if this one still works. So this is going to show a keyless flow for an OCI image. So last time we signed a blob and we verified the blob. This is the keyless flow and it is caveat. It is still using cosine to sign the image but then it's going to use the rust version to verify it. And just for context, I think, yeah, here, this is just in GitHub container repository. I have this image, it's very simple. It's just for the demo and this is where we're going to push that signature and where we're going to check that it was signed correctly. Oh yeah, so I had signed it earlier. So now we're going to use six store RS to make sure that this can be correctly verified and it does say image was successfully verified. It has all of this other output which looks alarming but it's actually okay. So image successfully verified with rust OCI image as well as a blob, it does work. Thank you very much. I will do one more thing which is to let you know that we have an overwhelming number of ways to get in touch. This is the one that is rust specific. So we have a channel on the six store Slack instance that is six store RS. And then there are all of these other resources if you're interested in six store in general. If you're not already joined up to these, please do so and get in touch if you have any interest. Thank you very much for attending my talk and for being here today.