 All right, everybody. Welcome back to Monday AMA. Today we have a new topic to me, Sig Store. Luke Hines is here with us from Red Hat and he's going to tell us about software signing for the masses. This is a new to me and probably to many of you project that I thought would be good to get a one-on-one and introduction to and then answer any questions you might have and let you know how to get involved. So with that, Luke, introduce yourself and rock and roll. Great. Yeah, thank you, Tyne. So yes, it's exciting to be here looking forward to doing this. And my name is Luke Hines. As you can hear from the accent, I'm in the UK, although some people say our sounds Australian. I don't know why. I work in the Red Hat CTO office. So in there, we have a group called Emerging Technologies and I'm a security engineering lead. So it's team of about seven of us and we're all working in different areas of security. And yeah, today we'll be doing an introduction to Project Sig Store. Okay, so ready to roll? Great. Okay, so Sig Store. So the problem that Sig in attacks, some of the ones that have caught mainstream news are SolarWinds attack, which affected many U.S. government military systems. We can expose those systems to risk. And there was also another one around the a gas line pipeline. And these led to President Joe Biden releasing an executive order to address the secure supply chain. So this is an area that I've been looking at for a while, but it's got some significant attention on eyes on this space. And essentially supply chains are there's so many actors that constitute a secure supply chain that it makes the amount of the threat surface greater. Okay, so there's all these various build systems, components and humans and packaging systems and different artifact types that containers, tar balls, binaries, files, text files, etc. And I won't really do a deep dive into the attacks, but common ones that we see our account compromise. This happens quite a lot. So somebody will compromise a developer's account, a compromise of build systems. We're particularly exposed here as open source projects, because a lot of our build infra is public. Okay, so we have our how our CI systems, perhaps not the passwords, but how our CI systems operate. Anybody can go in and look at various config files that dictate how a build system should operate. So there's a lot of is you've got very easy recce around this recounts. Pipo squatting happens a hell of a lot in packaging. Okay, maintain our accounts are taken over. There's a multitude. I could have put a lot of bullets here, but it would have been over. But the problem is the general consensus is we have to improve things here. Okay, so so the supply chain is really where six door is hoping to improve matter. It's a it's a multi heavy beast. Not one project can solve this problem entirely. So we're focused on a certain space, which is around software signing and software verification. So if we look at who is actually signing code today, we look at some critical projects, critical projects is open to interpretation. People might feel they're other projects that aren't listed here that are perhaps more critical, but we pick some of the ones that we did some due diligence on when we look at who is signing code. So when I took about signing, I'm talking about generating some cryptographic keys that will allow you to sign. So that there's non repudiation around who signed it. So you know who you're getting it from. And you can guarantee the attestation integrity of that particular artifact that you've received. So if we look, it's kind of quite a dotted landscape. A lot of people are using PGP, quite an old tool set. Okay. And most of the time they'll do something called tofu trust on first use. So you just assume the key that you've got is from the individual who you expect it to be. You import it into a key chain. And that's it is then in your trusted circle. Others tend to store public keys in GitHub repositories, which is in a very secure method. It's a mutable, editable area to store a key as such. Okay. And others have them on websites. So I have them on like a WordPress login platform. Now we've got Kubernetes there. When we originally put this slide deck together, Kubernetes were not signed in anything at all. Okay. So there used to be a a sad Miley face there, but we've actually managed to onboard the Kubernetes community now. So they're actually using Sigstore to sign and verify destroy list containers that are coming in. And we're also looking up to help them do releases. It's the same for package managers. It's a very dotted landscape. Some are using PGP, some are using X509. Some are using absolutely nothing at all. I'm quite concerned about crates. If anybody doesn't know crates is the rust packaging system. And they currently have no sign in at all. So when you pull in dependencies using crates to build your own blob, your own Rust application, you're pulling in the code untrusted. Okay. And that kind of negates quite a lot of the security, lovely security guarantees that Rust and its compiler can bring. Effectively, you don't have really any trust or assurance around the packages that you're pulling in. So yeah, it's a very gothic landscape. A lot of some people do have these tools, but they don't really use them. Users don't use them. And the reason they don't use them will start to explore soon. So when you sign software, this gives you, like I said, it gives you integrity of the content. So if I sign a table and I pass it over to you, you can verify that. And you can be sure that in transit nobody's tampered with that particular table. Using non-repudiation. So if you trust my keys that it's me and I sign a table and I pass it over to you, you know it's come from Luke. You can then leverage authentication from that. And then you can also get some sort of assurance around time with timestamp. But then you can be protected against certain things like replay attacks and so forth. But the problem is with this technology, it is challenging. So managing the private keys is difficult for a lot of folks. There are security geeks out there that find it no problem, but they're generally the sort of 3%. And it can get expensive if you're going to do it properly. You'll need something like a UB key or a HSM, some sort of cryptographic hardware storage. Security standards can be quite complicated and difficult to understand for some people. The UX of the tools leaves a little bit to be desired, really. Revocation is difficult. So if you lose your key, it can be quite difficult to clean up the glass radio. And existing mappings of identity to key pairs have their shortcomings or cannot be trusted at all. Really, we're something like GPG. You're looking at a web of trust, which is where people actually get together in person, look at each other's driving licenses, and then use that as a means to establish that this key pair that I'm getting is from Ralph, Mike, or Jane, or Diane, or they can sort of meet the person physically and then establish trust there. The other thing you do is you introduce an intermediate trust, sort of like a certificate authority, so they can vouch for, yes, I believe this to be this individual. Now, looking around again, examples of people trying to use technology, and this isn't to blame these projects at all. These projects are actually trying to do the right thing and trying to sign things. If we look at the example on the left, this is a screenshot from the TAILS project. Anybody who knows TAILS, it's a Linux distribution that's meant to be used by whistleblowers and journalists. So their privacy and the assurities of their security, those are the utmost important. As you know, it can be a hazardous area to operate as a whistleblower. And if you look at this, the keys are actually stored on a WordPress site and WordPress sites are hacked all the time. So if somebody was to hack this site, they could just swap out those keys for a netfarious pair of keys and then essentially compromise a load of whistleblowers. If we look at the right, this is a screenshot from the Node.js release page. And again, Kudos that these folks are trying to do the right thing, but there's a lot of keys to manage here. So there's these various keys that have to import the GPG. And then you have to import some users that used to be on the project but aren't on the project anymore. And this is troublesome. How many users would actually do this? That's the thing. I mean, I was speaking to somebody that works in a container engine of a Pogman and so forth, Daniel Walsh, or somebody you might know. And he said, look, how many people still use GPG in their email? Very, very few. And that's a kind of a good kind of capture, really, of how these tools have just not got the utilization. They're just not being used by users. Just a very small amount of security and very people that are very sort of vested into this sort of technology. So we thought, imagine a world where signing was just a lot easier. There wasn't the propanes and the headaches around key management. And how could we increase the adoption and the proliferation of cryptographic signing and verification of things in the software supply chain? So we came up with this idea of project of Sigstore. And like all things, we tried to borrow a good idea and then sort of re-spin it into the particular area that we're looking to address. So we looked at Let's Encrypt and what they managed to do where you had an internet where a lot of sites used to run on HTTP. Let's Encrypt came along and they made it free and easy to get HTTPS certificates for your website. And then where they did that, they changed the optics. And then browse has started to get assertive against HTTP sites and show them as being something that's less than desirable. And it managed to shift the idiom. It changed the whole optics around signing. So that's what we're looking to do with Sigstore. So Sigstore is actually a group of open source projects to provide the infrastructure and the client tooling for this signing. And it's also going to be a free public public good service that anybody can use. There is no payment for membership. There's no tiers of membership is free to use. So the idea being that this will be a service that is for the good of all, because the more secure the supply chain is, the better it is for everybody. I think this is something that goes above any individual company. And coincidentally, all of this stuff runs on Kubernetes. You can run this in a cloud native environment. So we'll have a look at what the various projects are that Sigstore, the constitutes Sigstore. So we have a project called Falsio, which is a certificate authority that provides code sign and certificates based on an open identity connect identity. Well, go into a little bit more of what that means shortly. And we have RECOR, which was our first project that we worked on. And this is a signature transparency log. So this is you can feel a bit like a blockchain. Okay, it's a system that when you enter data into it, signatures and digest and so forth, they're append only, they're immutable. So you cannot change them. So nobody can tamper with that. So it makes a good public point of accountability around signing. And we have a generic container signing tool and we're working on other clients for signing other things. Well, so we have one like a Maven plugin, a Ruby Gen signer. And there is also, we're starting to look at something within crates of the Rust community. So there's a lot of work going on around building these various client tools. So we're kind of a quick overflow of how we manage the keys. So I've spoken about the private keys. And we have this technology, which we call keyless. Now, it's not really keyless, but serverless isn't really serverless before. The serverless folks can use serverless. And we're talking essentially here, the keys are ephemeral. Okay, so once you've created the private key, you do not have to worry about it after. You can discard it. It's a one shot job. And then after that, there's no worrying about storing the key or revocation. But we'll show you how we do that. So we have a user, okay. They have an artifact, let's say a container, which they want to sign. Okay, then we have our CA, full CA. And we've got two transparency logs. So these are the Merkle tree systems, the blockchain system, the certificate transparency log and the signature transparency log. So what would happen is the client would generate a key pair, a cryptographic key pair. So a private key and a public key. And these do not even touch disk. These are encoded to memory. They're very, very short. After that, what they'll do is they'll make a request to our CA. Okay. And what they'll do is using the public key, they will hash their email address. Okay. So this is a challenge to show that they have the public key. The email address is just a nonce. We're not even nonce, sorry. It's just a value that is easy to use for the challenge. So we're not actually pulling out the email address and then making a decision that this email address belongs to this user. It's really for us to have proof that that user has that public and private key pair in their person. Okay. And then what will happen is we'll then send them back. If they're doing this manually, we've got stuff to work in CI as well. But if they're doing this manually, they'll get a screen then where they can log in with an open identity provider. So GitHub, Google, Microsoft. We're looking to incorporate lots more as well. There's about 20 of them. Okay. So then I could then click log in with Google. Okay. And then there'll be a screen where I can grant access using my Red Hat email. Okay. And then what will happen? The system will query the open identity provider for the email address. Okay. So you grant us as an application the permissions to get your email address from Google or GitHub or Microsoft or wherever it is. We then take that email address back. Okay. Which is the same one that you did the hash challenge with. And we then put that into an X509 certificate. Okay. And then that goes into a system called a Certificate Transparency Log. These are actually used quite widely as well by browsers. Okay. And this is actually timestamped as well. So this there's a timestamp in service. So we know that the moment that this happened. What will happen then is the user will then sign their container. Okay. And they will send across a signature and a public key and a digest to the Signature Transparency Log, which is this project called Recall. Okay. Now what we have is from this, we can now discard the keys. Those don't matter because we've frozen in time this particular moment that an individual had a key pair in their person and proved by a third party identity provider that they have access to a certain account. So they're associated with that identity. Okay. And then those went into the Transparency Logs. And this then gives us a trust route. Okay. So any user can perform a lookup to see that lhines at redhat.com generated a signature using a certain public key or certain artifact, example of container digest at a particular time. Okay. So you have all you need then to verify the signing event of a container image. So we actually have this working with OCI container registries. So you can sign a container using your email address. Now, some people want to look at, they say, that's great, but email is that really secure? Well, it arguably is because with all of the open identity providers, you can utilize two-factor authentication. And we're looking at having means to check that 2FA is enabled. So then you do have some good security protections there. Okay. But the other key thing is the email address is in the Transparency Log. So you can then monitor the log for people using your email address. So if you see your email address occur within the log, you know that somebody's compromised your account. So this is where we get this public transparency. So it can protect the user as well. Okay. So to go into a little bit more about, I've been talking about these things called Transparency Logs. So we'll try to understand what they are a bit. So it utilizes an algorithm called a Merkle Tree. Okay. And the Merkle Trees have been around for quite some time. Git actually uses a form of Merkle Tree. Blockchains use a Merkle Tree. Fedora Core OS and Silver Blue uses a Merkle Tree. What a kind of that the Fedora folks might not agree with me. But it's essentially very similar. So the idea is that you have an immutable structure because it's built upon this tree of hashes. If you look to the right, you'll see that there's four hashes. Okay. And then each of those two hashes are concatenated together. And then the hash is computed with those to make a new hash. And then this continues until you eventually equate down to a single root hash. And that root hash represents the integrity of the whole tree. Now if I was to try to tamper with any of those, it would change the root hash. Okay. So somebody can effectively know that the integrity of a tree has been compromised somehow. And this makes it a very good system for public, accountable integrity. Okay. So another technology that I don't have listed here that utilizes this is BitTorrent. So what they would effectively do here is you've kind of downloaded a, you have a torrent file that you wish to download with a torrent client. Okay. And what torrent clients do is they will split the file into many, many file parts. Each of those file parts will be hashed. A SHA256 hash of them will be captured. Okay. And then they will, all those constitute parts will create a Merkle Tree. So all of these hashes will have a root hash. So as each file part is pulled in, you can capture the hash and construct the tree and then compare the root hash. And then, you know, if any single real file has been tampered with in some way, it will obviously change the entire cryptographic computation of the tree. So it makes it so that all of the clients that are part of the BitTorrent network that are deeding or leaching a particular file, then all verify the integrity of that file. So you don't have to worry about one evil client trying to, I don't know, provide a virus. So these are Merkle Trees. So this is a project we call Recall. Okay. And transparency logs help us answer questions like, is someone using my private key or my identity to sign artifacts? If some keys are hacked, leaked or lost, what is the brass radius? Okay. So we can do due diligence around attacks when they happen. Who has signed the particular Reese? Is everybody else in the same as me? Or am I facing some sort of man in the middle attack? Okay. And how can I be sure that an audit source is tamper resistant? How can I be sure that the data in there is tamper resistant? Well, because it uses Merkle Tree technology. So just to kind of a little bit more background on why we leverage the transparency log. Now, it's used in another technology called a difficult transparency. And this is run, these are utilized within a majority of browsers now. Some browsers are yet to fully implement them. Okay. And let's encrypt runs one. I think a few big providers, Google, Cloudflare, they all run a transparency log. And we'll have a look at how that works. So you kind of get an idea why we use this for software signing. So you have a website admin. Okay. A browser and a certificate authorities. So this is how things used to be. So what would happen is if you wanted difficult for your website, what you would do is you would send a certificate signing request to the CA. And then the CA would say, okay, let me do some checks. I want to see your credit card. I want you to make some sort of record to show that you own the domain. Do some various checks. This all happens behind closed doors. They'll say, okay, we're good. Here's your difficult, which you can use to run on HTTPSBigBank.com. Okay. Then the browser says, Mr. CA, using the root CA, I'm going to visit BigBank.com. Is this safe for me to do so? And the CA will say, yep, sure. Here we go. There's a chain of trust. You got an ice cream padlock and everything. Great. Okay. Now the problem with this muggle is we're essentially putting all our trust into one single authority and expecting them to do the right thing. Okay. And a lot of what they do is behind closed doors. Not to say they're doing the wrong thing, but they're not auditable. There's no public audit of that. Okay. So this is where difficult transparency came about. So it was difficult transparency. We had the same flow again. Hey, I'm BigBank.com. Here's my certificate signing requests. CA does some checks. They say they're good. Okay. But there's an extra step now where they now have to send the certificate train into a difficult transparency log. So we've got this difficult transparency log as the new app in this flow. So what would happen is a browser would say, okay, I'm going to visit a site. Difficult transparency log. Do you have an entry that there's actual header expect CT that's utilized? And if the certificate transparency log says no, then there's a problem. Okay. So I'm not sure that's the actual browser area that you'll get, but you'll get some sort of a lot of browsers will give you a kind of a beware types. Okay. So we now have this certificate transparency log. But what this means is anybody can monitor that for domains being signed or certificates being provided for domains that they own. Okay. So red hat.com could look for people signing or say red hat.com could look for people requesting signing certificates using red hat.com. So if somebody totally unrelated to us was to request the difficult for red hat.com, we would be able to monitor and see that. Then obviously tell us that if there was one, we know something bad has happened. Somebody can pretend to be red hat.com. So that's the history of certificate transparency. And you can see where this technology was already quite conducive to secure supply chain. We just had to obviously make quite a lot of changes to make it specific for a particular use case. Okay. So I'll do a quick overview of some of CIG Stores project. So we have Fosio, the CA. Okay. And this is the software sign in certificate authority. Okay. So here we have a system that can generate the certificates. It can query and make grant requests to be open identity providers and it can interface with a developer. Okay. So this gives us this keyless technology where we effectively have an ephemeral key pair. Okay. And a few interesting things about this, the root DA for this project was actually created in the open. So we have various key holders as myself and someone else from red hat. There's somebody from Google. There's Professor Santiago from Purdue University who does a lot of research and secure supply chain. And we also have some folks from NYU, New York University, and they have a research department that's looking at this. So we went through a good balance between academic and corporate. Okay. And then all of us together using some keys, we created a root difficult. But this was actually all done on a live stream where people asked us questions like, what's the weather in Italy? What's the current price of Bitcoin? A bit like holding up a newspaper. And so this was the first instance of an open source, open CA root certificate being created. So you can see the whole creation on a GitHub repo where people verified all of our actions. So we made ourselves fully accountable. So it's quite interesting that this was quite the first where we had an open source and openly audited root certificate that was generated. Coincidentally, the other projects are interested in using our root CA now. And that's the CA that appears. We then have Recor, the transparency log. So you can see all of these projects are in our organization stick store. So anybody can come along and contribute to those. I'll go into that shortly. So Recor again is the transparency log where we store the signed artifact, the signatures are published to Recor. So Recor will only accept records that have signatures that verify. So we know somebody can't just put junk or nonsense in there. We don't store the artifacts. So if somebody tries to send us a binary, that's not stored in the tree. All we will do is capture the digest of that. And that is what we'll go into. We have a REST API, which is available to make entries to the log, get consistency and inclusion proofs. And so Recor is actually starting to get a lot of leverage outside of stick store, like their keel of sign and stuff that I told you about. Lots of people are starting to use this for means of firmware, binary transparency, and all sorts of other interesting security cases. We run a public good instance that's there for anybody to use. And just to repeat myself, as I say, it can be run independently of our project. So Recor has what we call a pluggable PKI interface. So you can send X509 certificates, GPG, SSH keys, mini signed, and we plan to add other signing systems as well. And we have these what we call pluggable formats. So you can kind of set your own schema and contribute it to Recor. And then Recor will start to utilize that. So we're getting quite a lot of interest from folks that are working in Sbom, which is a secure bill of material. So an example of one of the tools is Cosign. So this is what the client would use. So the previous two were part of the public infrastructure, the service that supports this. And this is an example of a client. So with Cosign, what you can do is you can generate an ephemeral key pair. Or if you wanted to, you could use KMS, so we support Vault, the AWS and Azure and GCP KMS systems. The exciting case is the ephemeral key pair. You generate an ephemeral key pair, you request a signing certificate from Fawcio, the CA. You download the container manifest from the registry. You generate a signature. You push that signature up to the registry, okay, to an OCI registry. And then that also creates an entry in Recor. So then you have that app should sign in. So what somebody can do then is at a later point, they can verify that a container has been signed by my open identity account. Or they could be particularly stringent around policy and want to see three different individuals sign that container. So you can stack consensus of your policy. So there are a lot of other projects that we're looking to on board. We're working with a Python community, so that PyPy will implement a form of six-door signing. Also, RubyGems, we've recently started to work with Recor, sorry, with Rust, RustLang, to improve crate signing. And there's a lot of other projects that are prototyping of six-door. Some of the recent interesting ones were Bitcoin is actually looking to use us for their Bitcoin releases, use the transparency log. Arch Linux just built a binary transparency system. Has been speaking to different people in Fedora to try and get their interest. And then the youth folks, the key part which is how will this fit with OpenShift. So we very much plan to leverage this in OpenShift. So I spend lots of time speaking to different people that work in the various silos of OpenShift. So Quay 3.6 will support six-door signatures. So as our Quay 3.6 you'll be able to do this keyless signing and have a registry attached signature. Advanced cluster security and advanced cluster manager have developed a six-door admission controller. So you'll be able to verify your Kubernetes YAML is signed before you deploy it or rather verify, sign in and verify. Work is underway. So we're working with the folks in the Podman engine team who implement all of the cosine six-door coding to Podman. And then we also have a project that we've worked on called Tecton CD chains. And this allows you to sign Tecton pipelines and task rows. And that will of course likely downstream into OpenShift pipeline, so that's our hope. So all of these technologies are planned to be productized in OpenShift. And they're not as yet guaranteed, but the work is happening upstream. That's as much as I can say at the moment. So there is no official release. We tend to sort of go through a process where we have sort of developer preview and tech preview before things are productized, but the work is happening upstream to make this happen. And then the idea is that what somebody will be able to do is sign any containers, any deployment config files, all of these you'll be able to sign with six-door and you'll be able to verify as well. And we're doing lots of work around SBON as well, Secure Bill of Materials. So you have a kind of a signed ledger or invention. Different systems have interacted with an artifact that's constructed within a supply chain. So if anybody is interested in more information, we recently got a really nice new website put up. We currently are in soft launch. So we have public systems that are available for you to utilize. If you wanted to, you could download Cosign now and start signing the containers by using the admission controller. This is all working code that's available. And we have public services that are free to use at the moment. And we also have an open API. So if you fancy writing your own client for your own use case, then all of our open, all of our APIs are openly documented, relatively easy to interact with. Those are all RESTful APIs. And our next plan is to launch a public service. So we have a soft launch at the moment. And we're currently in discussion with Linux Foundation around launching this full public free to use service. This is where there's guarantees. There'll be people around to ensure everything is up and running. And then we will be fairly close to the model that Let's Encrypt have. So you'll be able to utilize the service to sign any particular artifact that you have. And we've worked quite closely with the Let's Encrypt folks. They've been really helpful towards us around feedback on design and our architecture and how we designed our CA. So a summary, 100% open source code, Apache 2 licensed, all of the tooling, a lot of the operational code as well will be open source. We're already under a soft launch. So if you want to have a play, you can do. There will be a free to use non-profit public service. Okay. And the current members that are involved and it's expanding quite quickly, and actually need to update this is Red Hat, founded members, Google, and Perdo University. And that brings me to the end of the presentation. So I did have a bit of time for questions. All right. Who was that asking a question there? I have a lot of actual questions. And I'm really psyched that this is actually happening now and that the soft launch is going because everyone can go off and check it out. Can you tell me a little bit about how the the certificate authorities are interacting with you? Are they adopting, go all the way back to that slide you had with the certificate authorities on it and then utilizing it? Are they using it in production now? Have you had conversations with them? Is it being adopted by them or do you need to do some outreach to certificate? Good question. So the certificate authority side is covered. That's already up and running. It's a sort of separate effort that's been established for quite a while. What we did was we looked at what they did and then we thought, hold on, we could use that for your supply chain. So in a lot of ways we're borrowing some of our ideas from them. So that's actually there now. So I believe like a Google Chrome, I'm not sure about Mozilla, but when you go to visit a site in your browser, it will expect the certificate to be in a certificate transparency log. So that's already up and working. Yeah, so we're looking to cover the software side. All right. And tell me a little bit about the soft launch and the relationship with the Linux Foundation. I mean, they're hosting you. Are they the people that we're trusting to host this or how is that working or is that just where the code is stored? That is a little fuzzy for me. Of course, yes. So the code will always be open source. It will always be community developed. We need to run a public service. So we will need site reliability engineers, folks with pages, if the service goes down, a DevRel project manager type individual. So we need some staffing to run a service. And so we didn't really want to do that as any particular company. We wanted it to be a neutral body. So let's encrypt are actually nested under the Linux Foundation. They have an intermediate entity called ISRG. The internet security was such great. So we thought LF would be perfect because it's a neutral body. And then anybody can sponsor SiegStore, like you sponsor the CNCF or any particular project. And then that money will then be utilized by the LF to pay their staffing. So we sort of inherently trust the Linux Foundation to remain neutral. So that's a good thing. And that's a good placeholders and lesson crypts have got a long history with them. So technology-wise, in OpenShift, my phone decided to ring. Hang on a second. That always happens right when the Q&A is going on. That's when I remember that I didn't turn off my phone. And so I apologize for that. So OpenShift is coming. It's going to adopt this approach. Yes. Well, the technologies are being implemented upstream. So there is no official guarantee this will be productized. But looking at how Red Hat typically works, I've got to be careful how I trade. I know. Yeah, it's public trade. Generally like when the community is strong and a lot of people that develop OpenShift are excited about this technology. And who wouldn't be? Because we are creating Container a second, basically. Constantly creating containers in the CICD workflows and the pipelines that we create with OpenShift. And so that's going to be an interesting adoption channel to get it embedded into the Tecton and into the pipelines and do that. So you talked a lot about the client side of things, like so an individual wanting to sign an individual container, but from an enterprise point of view. So say some big bank that's using OpenShift, they would have their admins using and creating a pair of keys that would get embedded into the OpenShift pipeline and used over and over again for signing it. And that would be that'd be huge. It kind of begs the question of why we didn't do this ages ago. Yeah, it's very clever. I mean, somebody that I work closely with at Google, Dan Lawrence, he was the one to come up with this keyless idea, which really that was just that was the killer use. But I mean, we had the interesting technology around the transparency law, but he came up with this idea of leveraging open identity connect. And that was like, amazing, we don't, you know, we don't have to worry about managing the keys anymore. And so it was very much like a real sort of open source success story where somebody created something and said, Hey, I've got this thing. And then somebody else said, Okay, that's interesting. Have you thought about doing this? And he just blew up from there. And then right project at the right time, suddenly, you know, supply chain attacks became daily news. So, yeah, I think it's going to be a really interesting, because we've definitely gone over the tipping point with creating containers, like the wall, you know, with the advent of Kubernetes and, you know, all of the different just distributions of Kubernetes in all the different ways and flavors that we install it everywhere on the, you know, every different cloud provider. So I think this is one of the things that should have been, for me, it sounds like it's something that should have been part of parcel of the original ideas around containers. And, and so I, and having worked in Python and PyPy and other packaging things, it always makes me scratch my head that we didn't think of this ages ago. So our sort of, our kind of, our sort of a dream, okay, our kind of what would just be the most ultimate implementation of this is that anything not signed is just rejected by default. See what I mean? So users are constantly protected, you know, and really to sort of, you know, like I said towards the start of this web conference, if you look at how it is with HTTPS now, if you go to a blog that's just HTTPS, it kind of, you feel like, you feel like you've done something. It feels a bit dirty. You see what I mean? It's socially unacceptable and we want the same thing for containers and artifacts really. Yeah. You know, it's not even if it's not ours that's signed. It's not about we want to control everything and nothing runs unless it's done. But it's just, if we can help that momentum, you see what I mean? Then, yeah, not that I want to pile anything on else on the certification programs that we have here at Red Hat for containers and other things. But it seems to me that Red Hat is in the business of being trusted too. And a lot of other companies are and a lot of the FSI and the government agencies and all those folks. I mean, there should be a tsunami of people who want to embed this beyond Red Hat and other folks and make this happen. So I think it's a huge project. Where do you need help as a project? Where are you looking for additional contributions, testers, people to help you do dev rel, all those kinds of things? Where do you need the most help? Everywhere. We're very poor at docs like any group of developers. We just launched a new website and a new documentation systems coming up. So we definitely, there's a lot of, a lot of contributions could be made by technical writers. Translations will of course follow suit. Development-wise, we're reaching like a cosine hit 1.0 and we're looking to release recores 1.0. But there's still lots of work to do, improve, have to prove our CI testing coverage. Sorry, not code coverage, but integration tests can be improved, I'm sure, and client tooling really. So we've put up this public infrastructure and it's just begging for people to come along and be creative and create their own tooling around. We have the transparency log. So people could write monitors, interesting sites that can query the systems and gather metrics and look for suspicious patterns. When you were going over the stuff about the transparency log and monitoring it, notifications if you're, for like some sort of push out notifications to say a red hat or a big bank.com or an individual if you're, if you're, if there's some like a fraud detection app was the first thing that sprung into my mind is when the bank called me. That's a great idea. We were actually talking about how it'd be good, you could build, you know, have I been phoned? Yeah, that's, you could build one of those, see what I mean, where you can monitor for the domains or your own email address. Yeah, that I think would be one of the most useful first little apps that I would hope someone would write and I would download and use or help document. And the other thing that massively helps us is if you start using six store because the more open source projects we have that are adopting us, if that I mean, of course, somebody does the assesses, it's useful to them. Okay. But if they do, then they let us know that helps us then say, look, you know, important this service runs because people are relying on us. So that brings me back to the Kubernetes side. I mean, we talked a little bit about OpenShift because it's an OpenShift comments briefing and all of that. But what is the, how does Stig store and all of your projects, how do you interact with the Kubernetes community? Are you heading to KubeCon in Los Angeles? We work very closely with the community. We work especially closely with Stig Release. One of the Stig Release, one of the release managers from Kubernetes is our release manager in six store. So there's quite a lot of Yeah, there's, there's a lot, we have a lot of synergies with the Kubernetes. And, and we will have a booth. This is hot off the press. We're going to have a booth at, at, I'm sorry, I've been talking all day. You're in the UK. We will have a booth at KubeCon. Yes. So our plan is that we hope to have a laptop, anybody can come up and see how they can sign their own containers. And then we'll give you a sticker saying I signed. Oh, cool. All right. Everybody loves a good piece of swag or a good sticker. It'll be in KubeCon. People can come up and we'd be really happy to talk to them about six store and how they can contribute or use that plan. Is there any tracking that you can, or metrics you can do to show adoption of six store? What is, how can we, how can we track your meteor rise that's going to happen? Yeah. So probably the best bet is the website, which will be improving. But we actually have a repo called six store, github.com six store friends. Which we actually borrowed the idea from the tech.com CD, where, where companies and individuals and projects that are using us can put in a testimonial about how they're using us. That has been a benefit to them. And also our Twitter as well. So at project six store, Twitter is very much where we're very, very active on Twitter. There's a project six store Twitter account and it retweets all of my tweets that I make about six store or my sort of partnering crime, Dan Lawrence over for the Google open source security team stuff that he does gets retweeted and anybody in the community that's doing something on mentioned six store, we try to sort of to let people know. So that's a really good way to stay on top of us. All right. Well, maybe to end this a little bit, take us to that wonderful new site that you have. Share your screen again just one so we can end on that so people can see the work that's going on and hopefully join you. And if you have any sort of regular community meetings, we do. Yes. Yes. If you were to go to six store, the six store GitHub, so github.com slash six store. So this is our site. You'll see there's a little link to our GitHub organization. Okay. And then here you'll find there is not actually on the front page, but there is a community. Okay. And then in here, you'll see there's a Google calendar invite. So if you click on that, you'll make an entry where we have our weekly meeting. Okay. And there's also an invite to our Slack channel. Make that a little bit bigger. So we have a Slack channel. There's 600 people in there. Welcome to come along and ask questions. And then we also have our new website. So this will give you some idea about you'll get latest news in here, an overview of six stores architecture, how it can be used, the various people that are talking about six stores. So we were recently in wide.com. They did a piece on us. Yep. That's what I was using events. Okay. And so you'll see that actually links to our blog, a blog that we have six store blog.sixstore.dev. And there's various other things in here as well. There's, you can deep dive how six store works. Okay. You can sort of see the ecosystem. So how it would look as a developer parts that you'd interact with for a security operational professional for project maintainers and FAQ. There's lots of stuff on the website. So the website is probably the place to hit six store.dev. And that will tell you everything you need to know about how to reach us and where our code is and so forth. Well, awesome. And I think what I'm going to do is I'm going to have you back again. When this gets a little bit more integrated with some demo going with the demo gods will handle us. And yeah, I can easily do a demo. What we could do is I could come on and we could create our own container from scratch a hello world and upload it to a registry sign it and then verify it. That would be great. So let's let's plan on that and do a follow up and get people more involved in the project. And thanks for doing all this work and making it happen. I love the Dan Walsh component of it. He's been at the forefront of a lot of great security things for us here at Red Hat. So shout out to him and the key list stuff. And I'm looking forward to being able to trust all of the containers and for everybody that we create. That was a huge, huge step forward. So thanks for all the work that you're doing. And we're looking forward to more great projects coming out of the CTO office there. That's a wonderful hotbed of inspired innovation. Thanks for having me. All right, take care. And we'll get the slides from you and put it up and as a blog post on OpenShift.com shortly. So anyone listening along can go grab the slides and please do check out the SIG Store site and we'll make this one of the hottest projects, hopefully, because it's necessary. All right, thanks.