 I already copied the template over for you. Thank you. I realized that when I had adjusted the page margins to close one of the tickets, it screwed up the table formatting. So then I had the page margins again. It was a nightmare. You know, I like, I see in a couple of places you use HackMD and I really like those. I like the concept behind it. It's just like, so part of the problem that I've been seeing with Google Docs is the more editors or the more content that you have or that you make changes to, it gets like these ghost things in it that you can never find and fix. Ghost things? Yeah, like weird formatting problems that take forever to try to track down. So today dealing with the margins and the table stuff, that was insane. I had to like undo a bunch of things, but it kind of makes me wonder if we should look at something else. I mean, I'm okay with Google Docs, but I'd also like to encourage people to contribute content and we rate things and mark down for our repo. So HackMD made sense. Yeah. Yeah, I like the HackMD a lot as well. Hey, everyone. All right. We are going to just wait a couple of minutes. We have Bob here. Hey, Bob. How are you? Great. Let's see. Morning, Bob. Okay. It looks like we have all the speakers on. That's a good start. Awesome. Do I have audio? Yes, we can hear you now. New machine and a quick zoom install and panic over drivers and mics. I'm surprised. I'm surprised you got that working on the new system. I feel like usually when you saw Zoom for the first time, you run into five different problems. All right. I'm going to put in the meeting notes in the chat if you could just sign in by putting in your names and if you have any updates or if you're new, put down your organization or what you do so that people that are interested in the topic can reach out if they want to have a chat. Brad and I've been hearing from quite a few folks who see the meeting agenda, but they're not really clear. They're new to the SIG. They might have not read the charter. What is it that we do at SIG Security? Okay. Yeah, yeah. Let's talk a little. I guess, yeah. Let's see what we can do for that. Maybe Andrews, could you open an issue? I can't open an issue. That's one of the things we do here. All cloud-native security things. Yeah. There's many of the things we do here. It's just open issues. We're working on issues too. Yeah, exactly. We also need to ascribe what to you if you don't mind helping out. I closed a bunch of issues last week. Yeah, Emily is on the top of the scoreboard right now. I've been getting so much email. Okay. So I think let's get started with kind of a round going through. Let's see. All right. We have an update from Jonathan. Jonathan, do you want to take? Sure. Just a very, very brief one. So we've had a couple of additional conversations on the back of the presentation on supply chain security and software factory last week. And we've agreed with the chairs to start up that working group. And the first meeting of that is tomorrow at 4.30 EST. I'll be putting the invite. Thanks Emily for sending through the details for that. So I'll be putting the invite into the GitHub and the chat channel as well. So come on to be part of that if of interest. That's it. Thanks. Great. Thanks, Jonathan. All right. So I think that's all the updates we have for today. So I think we should just go ahead. We have a good presentation today, our recall. And I think we have Luke, Bob, and Don, I believe that will bring us through that today. So I think let's go ahead with that. Okay. We'll do a quick introduction. That's okay. So I'm Luke Hines. I work at Red Hat in the CTO office and I've been working around the security space for quite a while. Last time I was here, I presented Keyline, which is since then onboarded as a sandbox project. And I'll go over to Bob. Everybody, Bob Callaway also with Red Hat in the CTO's office. And Dan. Hey, I'm Dan Lawrence. I'm in Google. I've been in the GNCF Kubernetes space for a while in projects like MiniCube and Kubernetes. And I've gotten more into the security supply gen space recently. Awesome. So it's all three of us that are working on recall. So I'm going to try and share my screen. Just give me a second. Let's just go for desktop. Allow Zoom to share your screen. Open... Okay. Hold on. Security. Okay. Sorry. I've got some sort of sandbox. You thought you could get away from Zoom? Yeah. Okay. So here we go. Zoom.us will not be able to record the contents of your screen until it is quit. Okay. Dan, are you okay to present? I have to quit Zoom to refresh the permissions. Oh, good stuff. Let me try. I have to use the web browser, not the desktop app, because I have restrictions too. If not, Bob will have a copy. So we should be able to do it between the three of us. Is it possible for you to just mime it out? Good day. Let's see. Is it problematic, Dan? Sorry. I think it's going to work. Okay. My internet's being a little slow. There we go. Okay. Something's instantiating. Oh, we're supposed to see something. It's a white screen at the moment. You want to have a try, Bob? Yeah, that was me. Oh, sorry. Okay. Dan. Mine says it's sharing. I think it's no. Yeah. We see the white screen again. Luke, do you think it might make sense for you to just quit and then rejoin? I could do that. Yeah. I'll jump off. In the meantime, you folks might have some luck. Okay. Oh, we got it. Sooner or later, it came up for me. Yeah. All right. I'll think. Can you move to slide just to make sure it's updating itself? Okay. Yeah. Okay. Good. Okay. So, yeah, so this is Project Recall. As said earlier, it's myself, Dan and Bob that have been working on this. We've been kind of under the radar for a bit and sort of power finding as we go along with the technology. And we're at the stage now where we're entertaining a soft launch as such and starting to share this with subject matter experts to get feedback on what their impressions are, possible collaborations and alignment and so forth. So do you want to skip to the next slide? Okay. You folks, you all have expertise here. I don't need to explain this, but we all know that software supply chains have their weaknesses. So there's various tax forwarded attacks, freeze, replay attacks, so forth. Keys get compromised. SSO accounts get compromised, which allow people to then piggyback onto systems such as GitHub, JIRAs, so forth. Militious hashes. So we all remember the Linux mint attack where somebody swapped out an ISO and put their own digest, their own MD5 digest onto the site and then like 10,000 people downloaded it. I don't need to give you folks a scare story. You're all experts in this domain, but it's a problem that we're all aware of. And Recall is developed to be conducive towards trying to help to solve this problem. Okay. So if we go to slide three. So we sort of agreed amongst ourselves that we could do with some form of transparency. Not an arbiter on whether something can be trusted or non-trusted, but a level of non-repudiation around what is the truth. Okay. And particularly for cases where somebody's private key signs artifacts. Okay. Somebody perhaps signs a release of some sort. Keys are compromised. Okay. So what is the blast radius? Somebody has claims to have signed a release or a binary. And then the old sort of targeted attack is everybody seeing the same as me. So when I go to retrieve what I believe to be the latest version of the piece of software, am I seeing the latest version that everybody else is? Or am I seeing an older version? Somebody's rendering the optics so that I see an older version that has some nasty CVs in the within that particular release. So this sort of sets the stage for why we started to explore this project. Dan, I think you're going to get for, we're going to do a bit of a tag team here as we go through the slides. Sure. So this is kind of a zoom in on the one point Luke made above. One of the biggest benefits of having kind of signature transparency here in a transparency log is the ability to detect key compromise. So if you're using something like PGP to sign release artifacts, one of the biggest problems is knowing whether or not your private key has ever been compromised or whether it's still secure. If it's been compromised, somebody might have it and they might be signing things on your behalf and distributing them. So this is kind of how a transparency log the three different groups here, the transparency log itself, use a software publisher and a user can kind of work together to help detect a key compromise. It kind of relies on everyone trusting and verifying each other. It's similar to the certificate transparency story. If you're familiar with how that works. But every time you sign an artifact that you're going to distribute, you would publish that signature to the recore transparency log and you would instruct your users to check that log before trusting a signature from you. At the same time, you're monitoring the entire transparency log for any signatures added to it with your public key. And then you compare that with an internal list of things that you think you've signed. If anything ever shows up in that log that you don't remember signing or you don't think you've signed, then you know that your key probably been compromised and it's time to rotate and get a new one and instruct your users that those particular signatures aren't to be trusted. So it also helps you control the blast radius there a bit. Back to you, Luke. Is this whose slide was this? Okay, so this is just an example of where people have found PGP to be problematic. One of the projects we were talking to recently, you can see they had an issue at the bottom where they had an issue with their computer needed to create a new key. And this particular project requires that you import about 20 public keys into your GPG to validate the signing of a release. And these are all people that have all left the project. So it just goes to show how there is a it's less than an ideal situation. So slide six, I can see is empty, but I can do this one by mouse, so to say. So I was meant to put something in here. So anybody that's not familiar, I'll go for it quick because I'm pretty sure you all are what a transparency log. It's essentially a structure called a merkle tree. And a merkle tree is components are hashed and then those hashes are concatenated together and a hash is created again. And it builds like a pyramid, a tree structure, all the way up to an eventual root hash. And then you can do things such as inclusion proofs. So you can validate that there is an entry within the merkle tree. So it's used by blockchain to sign transactions. Git has a type of merkle tree and also BitTorrent. So BitTorrent, they split the file into multiple parts. They hash those parts, those go out. And then as people receive those file parts, they can validate that they're tamper free by computing the merkle tree. So that's essentially a transparency login. And this is what recalls built on top of is a transparency login. And we're using the same backend as that which is used for certificate transparency, which is run by Cloudflare, Google, Facebook, various people. So slide seven. So yeah, Project Recall. We've kind of touched on some of this, but just to reiterate, this is centered on software supply chain transparency services. We have a public instance that's available and people are testing against. And we're looking to have this as kind of like a public good corporation. That's one of the models that we're receptive to. So think, let's encrypt essentially. We have server code and client code. This is all developed in Golang along with our backend, which we use for the merkle tree, which is a project called Trillion. And you can have a public instance, but you could also stand up an internal instance. So somebody wanted their own internal transparency log. Then that's very viable. You can do that. Now, once instances are built, they can be completely audited by what we call a monitor. So a monitor is a system that will pop entries as they come off the log. They will validate the integrity of the merkle tree and verify that it's sort of a Tampa Free State. So this is again along the lines of this is nothing new that we've invented. This is how the Certificate Transparency Project operates as well. So if we go to slide eight. So with RECOR, we're not trying to be an actor as such. In the way of say, for example, tough with how to take actions against a key compromise or notary or any of the projects around this sort of domain, all we are is we're looking to provide a the immutable backend for storing of these data sets. Okay. And to be able to do that, we have what we call a pluggable PKI interface. So when these manifests are signed, you as your we can have custom sign in interfaces. So one that we use typically as an example is GPG. We also have X509 and mini sign, which I believe is from free BSD. Is that right, Dan? Bob? Sort of. Yeah. BSD uses a separate tool called signify. Mini sign is another version of it. It's compatible. Yeah. So mini sign signifier kind of the same thing. Understood. Yeah. But essentially it's like a driver. It's a pluggable interface. Okay. And then the same comes for the actual manifests. Okay. So we're talking typically JSON here. Okay. You can effectively customize and have your own value sets in there. So we're not tied into any particular standard as such. We've got the agility there is to make a pull request with your own framework and include that into RECOR. So that way, like I say, we're not fixed to any particular type. The flexibility there is to customize it accordingly. So if we go to slide nine, so this is an example manifest. We call this the RECOR type. Actually, we call them types. I should make that clear. So as you can see, there's an API version. There's a spec. So we have a format where we've got the sort of a sign-in system that we use. The URL, in this instance, it's a signature, the public key. Okay. And then we have sort of values such as data. So here you can see there's a release and there's a sign-in of that release. Now, there is a client-side CLI that will generate this manifest for you. So developers could quite easily just pass in some arguments of their public key, the signature that they've just generated for release, and then an artifact, i.e., a toggle. So that could be locally on their machine or it could be on a a sort of an external face-in system. Okay. And then what CLI will do is it will receive this manifest, it will validate it, and then it will ensure the sign-in is correct before we let it come into the log. Okay. We don't change the data that goes into the log as such. All we do is we make sure that it's not nonsense that somebody's signing this. It's actually signed by the CLI, the key that it's claimed to be signed by. So as I say, here we've got this sort of generic example that we have that we use. And this will work with Intoto, for example. But we also can utilize XML and YAML. So we're not sort of locked into any particular manifest in type. And then if we go to slide 10, so you see this kind of goes back to the Merkle tree, which I described earlier. Okay. And so the manifest is hashed into the tree. And then we can calculate a root hash effectively for an inclusion-proof assigned tree hash. Okay. If we go to 12, so this is a kind of very, very high level architecture. I'm sorry, there's a bit of stuff on the slides. I should have been cleaning up. You can see to your left, you have your creators, so developers, build systems, tools. Okay. So that could be the likes of, for example, No Tree or Intoto. You then have your auditors, which are people that would monitor the lock. Okay. So these could typically be package managers, security researchers, somebody like a showdown.io effectively, antivirus vendors, so forth. And then clients would be software users or consumers of software modules and libraries. So they could then use RECOR as a means to ensure there's not a sort of forwarded attack underway. Okay. If we go to slide 13, so quite often we get asked, why not blockchain? Okay. We're fans of blockchain, but what we found is that most public use or uses that we know of blockchain, they end up sticking a gateway in front quite a lot of the time for canonicalization, validation, speed, authentication, and so forth. And transparency logs out of the box, they work for what we want them to do. And as said, Trillion is kind of tried and tested. It's deployed and used at large scale. So it's used for certificate transparency for GoSum. And it's the likes of, as I said earlier, Google run a transparency, certificate transparency server as do Cloudflare and various others as well. So if we go to slide 14, so we are effectively cloud native. RECOR can run on Kubernetes. We have an operator and we've actually got code that's available for instantiating on Kubernetes as well, the various YAML files that are needed. And then if we go to project status. So as said, we're currently in soft launch. So we have a public instance that's available. We now have no guarantees around it. It's a case of, it's a sandbox at the moment that people can play with. And then we're kind of, we're sort of kind of in an alpha stage still. So, you know, there might be bugs that require us to drop data and make fixes and so forth. Although we're confident we won't need to do that, but we just need this sort of bedding in period effectively. And we're seeking to onboard projects to start adding entries to RECOR. We're doing some integration with Fedora's packaging, signing infrastructure. They have a solution called CQL. And we're, at the moment, we're seeking, obviously, more people to contribute. They have an interest in this space, feedback. As I say, we've been pathfinding here as we go along. Okay. And there is in fact a open API that is within RECOR. So we have like a swagger UI where you can go in and see how the APIs work. And, you know, somebody wanted to develop a client. It would be very easy to do that. So every time we make a change to the API, it automatically renders swagger UI and an open API spec. So we, like I said earlier, we have a CLI, which can do everything that you need to do with the transparency log. But if somebody wanted to integrate into, for example, their build system, a call to RECOR, it would be relatively trivial to do because there's a REST API that's available. If we go to 16, so currently we have obviously Red Hat and Google are contributing. And some of you all know Santiago from Intoto. He started to contribute to the project. And he's also managed to get us four undergrads and a PhD student to work on this. So at the moment, we're just talking to who we see as experts to gain feedback and impressions and possible contributions. You might have a very valid question of why we talk into the CNCF. So we're not specifically looking, we're not here to seek inclusion into the CNCF. It's not to say we haven't outruled it. We're just sort of making our minds up as we discover and talk to people what would be the best approach. Because this is of course very, it is cloud native. It can run within that infrastructure, but it could also run on a non-cloud machine and be dealing with manifest that they're generated outside of a cloud context. So that is essentially an overview, just some other things. So this is not just slide where, as I said, we've got a full working solution. The code is all on GitHub. It's Apache 2 licensed. We have a Slack channel where people can ask questions and get support. We have kind of a website where we're starting to get decent documentation up there and the Swagger UI. You can see there, it's an example there. So you've got the API spec. Somebody's interested where you can try it out. And we'll be having documentation in there and kind of what is RECOR. And we'll also be providing a sort of a directory of service that people can use. So there could be multiple RECORs. In much the same way as there are multiple GPG key servers. So I'll conclude there, but I'll defer to Bob and Dan, just in case I missed anything substantial that I should have mentioned. I think that was good. Cool. Sound good to you, Bob? Yeah, sounds good. I think the only other thing I would mention is we do have thoughts around creating and kind of going back to the key compromise use case. Maybe even something like a have I been pwned website that you could ultimately upload your public key to and get an email or a web hook fired if there is an entry added to the log that used your public and private key. So in terms of trying to think of this as, again, the parallel of let's encrypt, this is a common service for good. And figuring out how does this ultimately evolve and adapt to the various artifacts that we can generate within the supply chain. As Luke said, we're trying to fill that out right now and just solicit feedback and ideas and contributions. Yeah, that's a very good point. And along the lines of that have I been pwned use case, I think you could almost sort of have a project like the tough that could benefit from this as well. So the key compromise was picked up within the transparency log. Then tough could enact its key compromise resilience and revoke and so forth. And we're sure there's lots of synergies with notary. And we also know key line could benefit from the having a source of signed digest and so forth. So, so yeah, I think what we could do is open up to questions if anybody has any. Yeah, I think it's a couple of questions in the chat as well. Okay, so this is vessel. Thank you for the presentation today. Just couple of small questions. So my first question is, is your project kind of, I mean, is it a direct replica of CT transparency log you're trying to do same thing for code signing or supply chase artifact signing? Or is it something additional as well in, in addition to transparency log, does it also provide architecture to sign and verify? Or is it just transparency thing that you handle? This is my first question. My second question is, with transparency logs, the Google transparency logs, you are only kind of pushing public certificates there or public certificate related data there. But do you have similar concept that all open source projects will only push the data here? Or you want every organization to deploy something internal for transparency? Okay, so I'll take your second question first. Okay. We're really positioning this as something that we want to be beneficial to open source communities. Okay. And which in turn benefits us all. But as said, this can be run internally. So somebody, if somebody wanted to use this within their own private organization, they could. And, you know, if somebody has information that they're willing to share, there's nothing to say they can't put it into a public instance as well. If it's, if it sort of meets that security context and, you know, and there's no issues around trust boundaries and then the information being public, we could certainly be receptive to that. And the first question is. Yeah, just to clarify that point a little bit, like the log itself is public and all data in it is public. There's no reason you can't store signatures for closed source artifacts. And as long as the artifact and the signature public we distributed, that's fine. Yeah, wouldn't make sense. Like you think for, you know, an artifact you build and run internally that never gets distributed publicly, it wouldn't make sense to stick that metadata in here. But, you know, even closed source executables you download still need signatures. And so that's fine. Yeah, good example. Yeah, for example, blobs and so forth. And the first question. So this was to do with the differences between certificate transparency. So as said, we share the same back end, but we're totally separate. We wouldn't be running on certificate transparency logs. We so with Trillium, it has a concept of a personality, which is the kind of the application that sits in front of Trillium. Okay, and recalls completely separate code base and project to certificate transparency. We just have a lot of similarities because of the back end and the sort of sign in and storing within the transparency log. Thank you. Thank you. So let's see what other questions. So yeah, that's the right URL api.recall.dev. Okay, yes, I can see Bob's been answering some questions there. So it looks like everything's been answered in the chat. Is there anything that anybody wanted to expand upon that's been put into the chat? So I guess I have a question kind of for the team. I know that Recall is interfacing with a lot of cloud-native technologies, like in total tough notary. Not as yet. We are interested in doing that. It's only a total yes, but with tough and notary, we haven't integrated as such, but we're very receptive to that. So I guess my question is around that. I think Justin isn't on today, but is there any communities that you would like to, if you're already not in touch with, to get in touch with them and we can help with that? What to be beneficiaries of Recall or to sort of collaborate on Recall? It's a collaborate. Nobody specifically comes to mind. Unless Bob, Dan, I think tough and notary are very interested and Spire, of course, as mentioned earlier. I think there's a lot of some really good synergies there as well. Yeah, I can't think of anyone. We're paying attention to the notary v2 work. I guess I would say a lot of cloud-native projects aren't really signing release artifacts today because it's not super easy or possible to do that with container images and OCI artifacts. So as that work progresses, I assume more CNCF projects will start signing release artifacts as that gets easier. So at that point, we'll want to interact more directly with people. Yeah, and there is kind of the chicken and the egg problem here as well. If we don't get communities to make entries into the log, then we don't ever get the momentum of gravity and changing the broader practices in communities around the software supply chain. So I think there's kind of the set of integrations that we could do with other projects versus just users of the log. So I think we're seeking both type of interactions here as we go forward. Yeah, very much. Which is kind of why we're conducive to the Lex and Crypt model, because their optics are it's very much a public goods service. If you see what I mean, it's not sort of a case of give your data to Red Hat and Google. It's seen as being something that's wholesome and for the benefit of everybody. And that's a kind of that's how we see RECOR perhaps standing a better chance of adoption within the public space. Obviously, internally, there are no considerations there as such around adoption. Yeah, I see Santiago posting something about the software supply chain security working group. Can you guys hear me? Yeah, I just wanted to add that I think that's also a perfect place to tie in the work that's starting to come on the software supply chain security working group and projects like RECOR that need to be framing around the threat modeling and the scenarios. The challenges of adoption that Lugo was talking about really remind me of the challenges in total has, which is pretty much a supply chain is as weak as its weakest link. And I know it's a very cliche phrase, but like the broader to cover an area more secure things are and that I think it's like the important push that I foresee in 2021 that it's getting the most open source projects participating so we can start answering questions about the cross-organizational ownership, about publication of trusted artifacts, bills, so on and so forth. I make a suggestion. I mean, I don't know if, again, it's helped us do a certain degree is do some presentations and in some of these projects community meetings like Aspire, TOFs, you know, Notary, kind of understand like what you all do. It's amazing after seeing this, but I kind of have to do like an internal kind of sell what you sell like on the community side. So it'd be awesome to say, hey, jump in, you know, whatever, you know, community out there and say, this is what kind of what we do. So then it gets the architects and the engineers out there thinking, oh, I can plug this into blah, blah, blah, you know, it'd be super useful. And again, just kind of that's a really good point. Yeah, definitely. And we would also sort of like to help projects actually sign releases because there's so many that aren't at the moment. I mean, if we take Kubernetes, for example, none of the releases are signed, GitHub sort of signs the commits, but then GitHub's keys are not accessible. So all you can really do is rely on a sort of a JavaScript component with a green tick to show that something's trusted, but you can't actually validate the trust yourself. So we'd also like to, you know, look at ways that we could explore making it easier for software maintainers to sign their releases because so many don't at the moment. Cube has an info team as well as, you know, the team that's working through like the releases, right? I mean, that's a perfect scenario where on a community call of some sort, it's jumping on and saying, hey, this is kind of what we do. You know, sometimes you got to give to get, right? So, you know, yeah. So some thought there. Sorry to cut you off. No, no, I'm just making a note of that. Was it the release team or the build? There's an info team as well. Infra team, sorry. Yeah. So if you go to the, you know, I think the Kubernetes contributors or it kind of shows all the various sigs that are there. It's great to see these sort of integrations as well, right? Because what I'm hoping we can also cover in that the supply chain working group is that sort of broader architecture of how this is all going to fit together. How would the architecture look like if we have in Toto in there appropriately set up within Toto and Spire perhaps and in the recall? I think that would be really beneficial to see that the breadth of what needs to happen to provide security within the supply chain and provide those best practices to people. And to Santiago's point, I'm starting to show that to some of the open source projects to say, look, this is a best practice approach to building and securing that software. Here's a sample architecture you can use and press a button and add it to your project, right? And then you start to see that community with something that you use in leverage. Yeah, it's good. I totally agree. Absolutely. Supply chain working group. So this is under CNCF. Under this group, yep, the six security group. We only recently started discussing it last week, but we're holding the first meeting of that on the 22nd, which is Friday, not tomorrow, like you already said. Great. So I would just a quick point. If you'd like any right away, you think you could get us onto a meeting where you're able to lodge an entry on an agenda, go for it. Just let us know and we'll turn up and present. That'd be a privilege. This is basically a working group, Luke, with some of the same people you're talking to, kind of discussing these same issues, but more focused on supply chain. I see. Okay, makes sense. Awesome. Do you have any more questions? Any other comments? Somewhat anecdotically from the experience of maintaining Spire, it's been challenging for us to integrate with single vendor open source projects. Can you share a little bit about your rationale around whether you pursue insertion into CNCF or you do not? What are you contemplating there? What's your vision for the future? Sure. So at present, I think it's fair to say we're multi-vendor. There's not many of us on there, but we've got Red Hat Google and Perda University with Santiago. Around which foundation we were landing, we haven't really made a decision as yet. We're just sort of socializing the technology and we're aware that we will likely fall into some sort of foundational consortium, but we're sort of open-minded there. We intend just to talk to people and what reveals itself to be the best fit would be the best fit effectively. That's cool. Yeah, we certainly found a lot less friction working with other CNCF projects. Sure, yeah, sure. Yeah, that's a good point. For us, the main thing is to echo back to what we were discussing earlier, which is the optics really. That's what we have to get right, because as Bob said, for us, we're only as useful as the data sets that we have. So we need open source projects to submit manifest to us. So that's where I know I keep sort of unparitined myself here, but that's where the sort of lexing crypt model, as we describe it, is a good way of rendering that. Yeah, to build on that one, the code is one thing. It's an open source project, but the real benefit here is kind of the operational service. CNCF operates a couple things like that, kind of like the CNCF hub and a few others, but making sure that we get that service set up in a sustainable way that can be operated reliably is the most important part. Very much, yeah. So that's why we've looked to build an operator so that we can sort of open source the operation of the recall as well. Effectively, that's the sort of model that we would like to have so that somebody needs to deploy recall. They can do so in a manner that's graph-native. It can scale and utilize resources as and how it needs to. Right. It's ultimately about reach and distribution and making sure that it's accessible. It is discoverable for people because you want to get those data sets. Very much, yeah. That's where we'll hold a lot of value for the overall open source ecosystem with all of these, as we know, there's so many projects that just have a very small amount of maintainers on there. They're perhaps not financed by a company and they've got their own private keys there, signing things, they're making releases and these small projects can be pulled into huge projects in their dependency matrix. So it's just sort of how we can have some transparency there around what's in that ecosystem. So one thing, this is JJ, that we led to Andrea's comment. One thing that's historically helped projects like this to become a little bit more successful is establish a project plan for your, how we are thinking about working with CNCF in an open transparent way and then track do it. So it helps people to identify, collaborate and interface and contribute. And you may stick to plan, you may not stick to plan, but being able to actually establish that and put it out and open will help you get a little more, I mean, it helps with transparency for sure and it helps you put the intent out there and then it helps other people to identify and be able to associate and collaborate and lend help as they go. Come to the stage, it's a good point. Look, and what you said last really to underline, there'd be great benefit to the ecosystem. You'd be boosting a lot of projects. There's even mid-sized projects of corporately employed people that don't do signed releases because it's an operational burden. And they have many maintainers of different companies. What kind of signing rituals do they do? How do they manage those keys? Et cetera, et cetera. Yes, very much. And I think there is an angle to this where people are nervous to sign things and to provide digest, because it almost steps them up as being accountable if something goes wrong. Whereas if they don't involve themselves, they're not putting their reputation at stakes, which is kind of doesn't make sense when you put it apart. But I think that's the sort of psychology that's playing out. Well, building releases themselves take a lot of dependencies. There's a lot of things. And so again, I think the mental aspect of it there is kind of making sure that people understand that your tool is not going to add a ton of extra overhead. It's going to do a certain thing that they can't do. You don't want a team to have to build their own kind of signing capability. So it seems like you're building a framework, right? Yes, yeah. So initially, the focus has been on the core technology, but we would like to make the tooling conducive to help make it easier for people to sign. How we do that? I mean, we don't really want to sort of recreate GPG. So we need to sort of weigh up what will be the best approach there. But we definitely want to make it easier for people to do this. And one thing that will really help them is knowing that anything that they do produce will be widely available. And others can, others can watch that particular space and audit that space. Would this make make sense to kind of, for example, if you could have it as part of like the CI badging, because they already have signing kind of like silver, I think the silver CI badge is like signing requirements. So maybe, you know, a goal requirement could be you would upload your sign manifest to a transparency server as well. It is, yeah. I mean, I've never seen that bigger adoption around the badge program. But I know when we're doing the, when we're doing the security assessments, we kind of, part of it is we also map it to the CI badging. Oh, okay. For CNCI projects for security assessment. That's a very good point. And the projects in the OpenSSF now, so I think we could talk to the working group there, because we plan to talk to them at some point as well. Awesome. So I guess to round it up, recall.dev. That's all you have to remember. On there, you can find the GitHub organization. There is a Slack channel. I don't know if I've got a Slack invite on there. If not, somebody, you'll find me in the CNCF channel. I'm usually hanging around the KeyLine channel. And yeah, it's, you know, if you want to stand something up, it's worth touching base with us, because things are moving fast at the moment. So docs are catching up. So you know, don't do getting in contact with us. And we can help you stand up an instance and play with it and make some entries, do some inclusion proofs, that sort of thing. So I'll be interested in that Slack channel if I can get a link to that. Maybe I can do that now quickly. Yeah. Well, Luke, could you put the slides as well as a second in the issue? At least we have it preserved so far that it's accessible. We'll do. I'll just quickly grab the invite, but I'll put it into the chat. Great. Thank you, Bob. Luke, what do you have behind you? Carbon tubeless, wireless shifters? Yeah. It's, I don't know much about it, so I should get on it more. I tend to run more. It's lapier. That means anything, but it is. It's carbon. All right. Awesome. Thanks, Luke. Thanks. Okay. Yeah. No, thank you so much for your time, everybody, and really good to catch up. Take care. Really interesting. Thanks. Thank you. Bye-bye. See you next week. Oh, Friday at the software supply chain booking group. Yeah, I will. I'll come along to that. Maybe, Brandon, you could ping me the... Yeah, I'll send you. Fantastic. Thank you, everybody. Thank you. Bye-bye. Cheers. I guess meeting adjourned. I thought Luke was leaving, not just everyone else. Hey, Santiago, are you joining that call Friday? Yes, I am. Did I not confirm? I don't know. I haven't seen the invite. I was wondering if you're going to be there. I'm sorry. It's super hectic. I had a family member in the hospital and then I'm starting teaching this week, so it's been super crazy. But yeah, I'll see you on Friday. Cool. Your place looks different from last time we spoke. This is my office in the university. Oh, nice. Are you all alone on campus? I'm trying. Are you all alone on campus? Is it like a ghost campus? I think there's some students, definitely not a lot of faculty, but I teach today and Monday, so I think everybody just calls on me to teach. Cool. Well, hopefully you're relatively diverse and everything's fine. I'll see you Friday then. Bye.