 All right. Hello there. Hi Steve typing. Sorry I was putting the so people didn't have to use their finger and count how many sevens it was I added the five times seven into this one as well. It's winter in Seattle so so I'm hoping. So she's going to join because she way and so she had been in overall been busy with the end to end. I think we just check here. You know what when I dialed in the zoom it didn't ask me to enter the code. It asked me but Is that the first time. I don't know it's so complicated you can get URLs that include the code as well. It just takes a moment. I can't tell because it's just like a good kind of thing. Yeah, I just say password. So maybe. Yeah, I think you might have the URL with the password. In that case, which is kind of convenient. It's kind of convenient. The same token kind of defeat the purpose of the past. Yeah, exactly. All right. So, let's folks can join. Hack MD. Sasha he was scrambling to get things working. Let me start with kind of setting context on it. It goes in this one generic look up. Here we go. Okay. So basically what we've been doing doing a bit of fill but this is the right context. This is what happens when you don't get an agenda early. Yeah. So he's been working. We've basically been trying to get make sure we can get the persistence discovery and, you know, signing a discovery model getting in and out of the registry. We know we want to evolve the registry API is a little bit more but this will get us closer. So what we've been working on was basically in the. We've been working on the envy to client. But we wanted to show what this experience could look like with the Docker CLI. Assuming it would be the Docker CLI in this case. So we were taking advantage of the plugin model. Apparently you can write a plug in with a bash script, which was kind of convenient for mocking up. So that's what we've effectively done. I feel like I'm doing the, the vamping thing while the, the person behind the stage is getting ready for their act. Cause I'm really clearly dependent on Saige here to do the demo. So basically what we wanted to do is let me just pull up. Have you got a link? Sorry. Can you link to that? Yeah, sure. Love you. Yeah. Why they bury this up here. And to be fair, was this the chain? So there's a couple of different changes. There's the distribution. Changes also was this one. So basically what he's doing is creating a temporary structure, which looks like this here. Where we're basically storing the config object. So while we, I know people want to drill into the details here on how we're persisting it. I kind of look at this as, Hey, we've got some fake walls up that kind of give us a feel of what the bathroom looks like. Pay no attention to whether the walls will actually hold as do we like the, the feel is the next level of the sketch. Now it's time for me to look behind the curtain. And you're like, Hey, are you coming out or not? So give me a second. Channel communications. Let me pull up. So what we were trying to do is basically say, look, let's pretend this was in the Docker CLI to kind of get that experience because we, and the NV two client knows how to sign and validate, but it doesn't do any pusher polls that would kind of be in your native experience. So what we were doing, let me just find this here. Was doing this demo script, which I'm going to paste up here in a second. Hey, Sam. So basically we wanted a, there's the Docker trust API. And we actually didn't, obviously didn't want to say Docker and be too, because that would be kind of silly to have to have a version there. We totally cheated. And I'm not suggesting that you guys would even implement it this way. But we just said, look, there is a Docker notary API that if you enable that, when I do push an action to be first. So here's the same. Basically do Docker build. And you give it a signature, sorry attack like you would normally do. Then you would say Docker notary sign. And you can sign this tag with, there he is. Okay. With this cert. Hey, Sasha, tell me when you're ready. I'm just kind of doing the, the prelim walkthrough. And then because I've already enabled this. So that's what I say. I could probably say it this way. Because notary is enabled that when I do a push of that tag, it would push not only the image, but the signature as well. You shouldn't really have to enable it because like, if you don't sign it, it won't, there won't be anything to push anyway. Well, there. So is the, so this was wrestling of it. So it was the theory that if, if there's a signature, we just arbitrate. Well, how, which signature do you push? I guess if you have any signatures, you would push. Yeah. Yeah. I mean, I mean, maybe it was the poll scenario that we needed it. Maybe, Sasha, do you remember this conversation? I'm trying to know what we debated here. Were you still scrambling to get it going? Yeah, the poll makes more sense. Sasha, I can see you in the car, but I can't hear you. He's probably still compiling. Okay. I can see the performer. He's walking towards the stage, but he's not ready yet. All right. So let's keep vamping. So that's a good question. I think I'm charmer of how we came up with why we did it enabled versus something down below. So the idea, and we definitely wanted to make it simple so that. The whole idea of pushing signatures between registries should be, should just work. So. If I pull and push, whatever I pulled would pull all the signatures related to it and push them as well. All right. You ready? I think I might be ready. You need me to vamp a little bit more. Let me give you another minute or two. Yeah. Let me just see if. I don't want to waste everybody's time just fumbling on the keyboard. All right. It's, it's still early for the, the dev species. The, all right. So then on the poll. In this case. How did I do this? Sorry, hold on. Oh, I see what we did. So we're starting to merge in some of the keys validation scenarios. So the idea here is I've got a brand new ephemeral client, right? There's nothing on it, nothing up our sleeves. So if notary is enabled. That when I do a Docker poll. Because it's enabled and there's nothing on the machine, this would fail. And the key acquisition model is, it basically says, Hey, you've got no to be enabled. I'm pulling this thing. You've got no keys. This thing is signed. So, you know, no, no, no look. Now, if I get the key and we're ignoring the key acquisition model for now, this is part of what. That the Niaz and Ian and others have been working on. So let's just say somehow the key got on the machine in this case, I'm just using as your key vaults could be AWS Google something key vault. I just get the key on the machine. And now if I do a Docker poll, because I've got the ACMI rockets. There's a big amount of hand waving there, like, how does Docker know about a key that you got with AZ key vault, get key. It's in the right location. I'm not sure that's the behavior you want. I think you have to, you probably have to be a bit more explicit about. Oh yeah, definitely. Because I want to actually use not just keys that I happen to have lying around for other reasons. On some keys, as long as they fit the lock, what's wrong with it. I have a bunch of keys in my, my, my window there. But here's, but let me go a little more deeper to not just laugh at it. The theory that we're doing for the incremental model is there is a key store somewhere on the, on a machine. There's an expectation of where keys should be. I don't know exactly what that is. I'm looking for the experts to say where that should be the, and there's a couple of different policies teams should be able to implement. The most simplest would be if I pull an artifact and it has at least one of the keys locally. So remember in our example here, we have three keys to this one. All right, so we'll just use this one for now, or there's another one that shows the other keys. Where is that? Oh, to the requirements. That's right. I'm going to get these in sync. Right. You ready? Yeah, let's just go through it. And I think I can take questions and maybe we can, if you can just recap to the questions, we can then finally kind of go back to address stores as well. Okay. Let me just close out this thought process. So, because I think this is what you want to build in for the demos. So web networks has one key. Docker hub says, oh, I certified that content. So now I've got a second key. And then acrockets uses one of those two keys to decide whether to leave and pull it. And then after they run their tests and then, yep, this net monitor software is good for my environment. And then they add the third acrockets key. So the thing, the most simplest policy that we've been thinking about, as you can say, that's just not good enough is if the client has at least one key. Of the required of the signatures, it passes. That was the most basic policy we were thinking. Not, is that valid or not valid? Or is that good enough is what I'm asking. Yeah. So it depends on the signature layout. So it depends on if. For example, in tough, it's not just the single developer signature you want. You want to make sure that you got all the way down to that developer signature correctly. But as far as like, you know, people signing one file, I think, yeah, that should be, that can be configured. Down to one or up to like, you know, 100 depending on. Right. New use cases. Exactly. Yeah, that we, we definitely acknowledge that there might be a policy that says you have to have at least two matching keys, or maybe even two specific keys or things of that nature. But we wanted to get the basic flow working. Justin. Just because you were poking at this one. Sorry to say that again. That what do you, what's your thought on at least having at least one key as a most basic policy. So in this case, we have three keys that are available on the artifact. I have the Acme rocket ski on my local machine. So the most simplistic policy says as long as the artifact has at least one of the keys that I currently possess, it's considered valid. And then to Marina's point with new policies, which we haven't gotten to yet, we could say not only that has to be at least two keys. And I think it should probably be like these two specific keys to correct people are assigning it, but yes, in general. Yeah, the thought processes, because these are a few more client scenarios that I'd only bring the two keys I care about, but to your point, I might be pulling two different images. And image one has a policy that needs keys one and two and image two for whatever reason has a policy needs. And image two and three. So even though it's got three valid keys on the machine, it needs to make sure it's the right keys for that particular artifact. Yeah, I mean, I think that, um, I mean, the question is whether, um, for say Docker pull, you want to be able to configure policies at all, or it just has some vaguely saying default policy versus doing some sort of complicated APA policy, which probably doesn't make sense for. Why, why do you say that? Well, I mean, well, maybe you might want to, I mean, yeah, maybe you want to point, have the option to point to a specific policy. I think you bring up a question is there should be some kind of policies engine that Oprah could implement, but it shouldn't be dependent on Oprah. Yeah. No, I wasn't. I just went over as an example, but the question is like more informational straightforward thing that we could do just for, like, in cases where it's a more exploratory, like perhaps like Docker has a different need. And you might not necessarily want to be in, effectively with Docker, you might not even want to be in enforcing mode. You might just want to be, but you can just be Docker content, Docker, notary false. That's the current, effectively the current setup is not very helpful in the sense that it does. The whole thing. It doesn't give you any, any, I'm trying to follow either that if I either have an honor off and if I have it on, I have the choice of policies. So I was anyway, ideally, I mean, ideally we have it on, ideally the same major way on. Otherwise everyone will have it off all the time as we've seen with naturally V1. It's, people had it off because it just didn't, it wasn't fruitful enough at the time. But it, if we're not doing a tow, a tofu model, then there has to be a way to get images before I've got any keys. Yeah. Yeah. Yeah. Yeah. Maybe I'll let you off the hook. Sasha, are you ready? We can, because this is a great conversation. It's kind of like, how do we manage policies? Yeah, I got it. Yes. Yeah. I'm going to bring up our stirring act. So the stage is yours. Am I audible? You are. Right. So, um, apologize ahead for any fat fingering. Yeah. Yeah. Yeah. So it's kind of like something that we've just put together last night over the weekend. But we just wanted to get kind of like, get some feedback so that we can make the changes necessary. And Steve script that he just showed kind of like walks through the idea. So I still want to just look at it more like an idea and not like any implementation per se. All right. So first things first is, we're going to use that registry to kind of like run the Docker commands against. Um, all right. So before I start with anything, there is a hijacked command here called orderly and docker notary. Uh, which is right now it's. It's got just, uh, a sign command on it. So we'll get through that right now. So first thing that I want to do is, uh, on this enable notary. All right. So this doesn't hold up. It's enabled. Oh, let's see. Maybe not. This isn't. Enable. Sorry. There we go. So all this does is it creates a file. Yeah. Hold on. Where's this file? It's good. You have to show us where the fact that's right. Oh, this is. This is just a backup of the file. Basically what you get is the NV two is enabled. And under that you specify. Uh, I have a specific file. That can be loaded for verification. So this is a cert on the disk that needs to be present. Um, this sort has to be in a quite out of band and it has to be present in the specific location. That's what the whole, um, the requirement of this plugin is. Uh, so. Let me see. The next thing that I'm going to do is, um, Steve, just give me a minute. Because if the file, no, if the file is empty, then the poll should fail, right? That's the whole idea. Yeah. Oh, I see what you're saying. Yeah. Yeah. So I need to show an empty file. Otherwise it doesn't. Did you, did you do a push? Can we do a sign and push first though? Sign and push. Yeah. Okay. So I just have a dummy doctor file here. And the idea is that. See. So this is my registry. That I have. And then I'm going to show you the file. This is my registry that I have. And then I'm going to create an image. Let's say whatever this is. So this is the image that I'm going to create. Let's build this image. Now the next thing I want to do is actually sign this image. Right. So for that, um, I need the search and in the certificate folder. I'll go through argument by argument. Basically, this is my key file. This is my third file. I'm going to create an image that I'm signing. And so hopefully they should generate a signature. All right. So this generates a signature. And then finally, when I push this. And that NV two that Azure websites.net. So basically what we did is we took the changes overalls been doing to distribution. And just hosted that. In an Azure website, just so we have something to push to and not just have it on a local machine. So this thing is going to scale to any limits. It's just a sample registry implementation. So this is going ahead and pushing the image followed by pushing up the signature. And then let's see if we can pull this thing. So this one is because in the original file, I don't have the, um, the certificates in there. Let me see if this works. There are no search installed in the original file. So that's why the pull is failing because I don't have any of the certificates. So let's go ahead and actually add the full part of the certificate in there. Hopefully it should work now. Sweet. Yep. So this is kind of the rough flow. I think Steve can share the source to, if folks just want to take a look at how this is implemented. There are a lot of rough edges on this, for example, how the commands have been mod, I mean, how the commands have been modded into Docker and things like that. But roughly, I think the, the idea is, um, I think the idea is to address certain points of, Hey, we need some kind of configuration. We need some way to pinpoint the search. Uh, we need some way to, uh, kind of like, make sure that only if the search are present in the policy, can it be loaded? Those are the basic ideas that we want to show through. Um, I'm just handing it off for now. Thanks. Let the folks digest that and let me know what do you think he actually got for it. I didn't realize that they had done the, um, config stuff as well, which is great. You know, Yeah. The config can get like pretty complicated if we wanted to kind of like say this repository or this registry uses only this certain things like that. Right now, we just assume that it's applicable machine wide for all registries and things like that. all registries and things like that. So that's definitely an area where we don't know how you wanna narrow the config down, that I wanna use only this cert for, only this image maybe. That's kinda how maybe you wanna ensure that just because a cert is present in the list, that all images don't get validated against a certain things like that. And I just paste it effectively what he did into the meeting notes. No questions? Okay. So the thought process is just, this gives us, remember we're doing that model approach. This isn't the final thing, it's, hey, here's a model of what we're building. And as we're staring at the model, we're finding the rough edges and deciding what we wanna fix before we go and write the blueprint and build the full thing. So the, and I think, Sajji, is this still hacked together with the bash scripts? No, the source actually uses the packages that you can, it's a single go binary at this point. Oh, cool. I just shared you the... Oh, yeah, I do see that. Yeah. So, all right, there's, we'll get this posted up, I'll just share for here now. Let me just share my screen again. Is that a screen too? There we go. So it's got this set of code. So the idea is this is just the latest model that we have and allows us to start testing some end-to-end experiences while we continue to iterate on some of the things like the APIs that we wanna do for distribution. So there's been a couple of good sets of feedback around how we wanna do the lookups and the persistence and we'll continue to go down that path while we have this kind of branch enabling some scenarios. What I'd like to do is the Harbor folks have offered to help, where can they help? So they were gonna help with likely some kind of go client that we could actually enable this, whether we actually take this to the next level with a Docker extension or a continuity. Ultimately, what I'd like to get to in this sketching is the ability to have an open policy on a Kubernetes cluster, implement some very primitive set of validations. The idea is we wouldn't yet do the more complex stuff that Marina was talking about. It would literally be like, in fact, he's already gotten further than I thought with this configuration file. But basically, if at least one signature exists locally, then it would be considered valid. Even the key acquisition would be extremely lightweight at this point. I was looking at what Ian and Niaz have been working on and there's some great progress happening there and there's some good questions around key rotation and others. So we'll continue to have that also converge so that we can keep on seeing these pieces come together. So with this, I'm hoping with this, we can actually start engaging the OPA folks to start implementing a policy so that they can start testing that and give us feedback. And then what we'll do is with that functioning, we'll start looking at the underpinnings and look at how we would change the distribution APIs and propose there. All right, that makes a lot of sense to me as a path forward, kind of making a minimal working thing and then adding all the pieces. If we have a little extra time today, I have a quick thing I wanted to show, kind of circling back to some of the conversation we had today and earlier about how to balance the client configuration with some defaults on the registry side. So if we have time, I could. Yeah, sure. Yeah, that was all I had other than just giving room for people to digest and have questions when we got plenty of time. Okay, yeah, I don't want to interrupt that if anyone else has questions here, so. Sam, Justin, anybody? I don't recognize FGO. I don't have any questions other than I, can you make sure all the links are in there? Yeah, sorry, are you okay with I make this available? Yeah, it's public, it's just a prototype at this point. Okay. Yeah, absolutely, but I just want to just take a look. Here we go. I just paste it in the hack and desolace so we don't have to worry about losing. Great. And Sam, questions are too early for you. Sam's always reminding me that it's also early or he might be busy. Okay. And I'm sorry, I don't recognize FGO Farav. Hello, Fulcott here from Ericsson. We're picking you to the project and we're just following it. So, yeah. Well, welcome. Thank you. If you want to, just if you sign in on the Slack channel, sorry, sorry, the hack doc for your name, I won't sound so stupid and even if when I forget, I can go look at this. Yeah, I did. Okay, great. Thanks. Oh, yeah, you did. Sorry, I was looking at the wrong week. Oh, and I was putting, I just noticed I put the notes in the wrong one. So let me fix that. Dr. Marina, why don't you take the floor while I fix my notes? Okay, cool. I'll go ahead and share. It's just basically just a diagram that I've made nothing to elaborate. So you can, can people see that? Yes, no? Yeah. Okay. Cool. So basically the idea here is just kind of a simple idea about how to split up a little bit of the key management and a little bit of the delegation, specifically for things like private repos or other things that don't want to be delegated directly from the registry while also supporting default things as a registry for kind of public projects where that's not as much of a concern. So the basic idea here is you have the, you know, the basic tupperials on the registry and we'll ignore time stamp snapshot for now because I know there's some discussion about how to make sure that those are protecting the privacy of repositories and we'll, we can get back to that, I think at a future point. The idea here is basically that you have the, you have a root key on the registry and then this could be distributed to clients, you know, using an out of end process and the whole key management discussion, I think comes in there about how to distribute that. And then that delegates to this target's role, which then delegates to any public repositories that you want to be available for anyone who has access to the registry or just that aren't, you know, where it's not like secret where they are, just to make it easy to find and access. And then the client can alter, alternately they can either just use this targets, access these repos, use the keys that are specified there or they can specify their own targets file. So they could still use this route on the registry for things like timestamp snapshot or any other general properties, but then you could use this targets here, kind of as the configuration you were talking about where you just have, where you list, okay, so these are the keys and I want to trust for these particular repositories. And it could additionally point to repositories that aren't publicly available on the registry, but they're like hosted on the registry. So this, you know, this we before is still hosted on the registry, but it's not like publicly available and you'd have like access control and all that backing that, but then this targets file would have the location of this repo for as well as the keys needed to sign it and any other information. And kind of an added benefit here is the client can do key pinning. So basically they can say, I trust this key for repo three. And then if the key changes on the registry, you know, with the key that the registry says is trusted for repo three, the client will still have this pinned key that's trusted. And so they'll say, oh, you know, this key changed. Do I want it to have changed? You know, should I do anything or do I just need to update my key? Yes, that's kind of the general idea of this. I don't know if anyone has questions or anything. This is kind of a rough sketch mostly, but just wanted to share and get some feedback. I mean, it doesn't address the case that, or at least not directly and maybe it could be a bit, but could probably be adapted to fill things that you might get from the same repo from... Hey, Justin, I don't think it's me. I think we're all hearing you talk about... Different registries. Yeah, my... Yeah, I think you're cutting out a little bit here. Said my entry and passing out, sorry. Can we take your video away and put mine also and see if that helps with bandwidth? Is that better? Yeah. Yeah. So I was wondering what we would do for the case where something was mirrored, whether we would, would the root key of the mirrored registry same target key for repo one, like so if I move, if I take something from Docker official image key and I sign through the root, would you re-sign that root in Azure if you imported that content into Azure or something? Or how would you expect that to work? Or would the client have to always... Yeah, so I think what I would expect, and I don't know if this is just off the top of my head, so I'd... Override the target, in this case. But that like, for example, this repo one would always be signed by the same keys. Like whoever's in here at this company or this organization is responsible, that would sign it and then they would publish their public keys to the targets file or to the registry, which would then put it in the targets file. And then any mirrors could just copy that. And the mirrors could choose to use a different like root timestamp snapshot keys, but they would just still delegate to the same repo one. Yeah, I mean, yeah, they would have to have a different root key. But yeah, so yeah, I guess it is a question of whether... I mean, there's a bunch of issues around what registries are kind of prepared to do here. Which I think I'm clear at this point, like which, I guess we've got to work out. But okay, that makes sense, yeah. Yeah, I think this doesn't like solve, I think all of the issues, because you still need the registries to handle these things. You still need ways to host all of these pieces, which I think is what a lot of what we've been working on. But this was just my kind of quick idea about how to handle kind of the separation of concerns between how much control the client wants versus how much you want to be automatically available and automatically working. Yeah. And I think the biggest piece that I'm still struggling to, we just need to figure out is the... I mean, I was trying to make out. I'm sorry, I think I was just saying that what I was trying to say earlier was that I think that having a set up where the client can get a sensible default that works for a lot of staff and always be turned on is really valuable because that was one of the problems with the current setup is like, most clients didn't know what to, most clients didn't have a reasonable default. Oh, they got one via trust on first use that was not. There was not easy to distribute to other people because there wasn't a good idea like how many keys should be in it and things like that. So if we had some kind of thing where you could have a reasonable idea of a reasonable subset of a policy that's not a stupid starting point that you might still want to tweak, but at least would give you some benefits if you didn't tweak it. I think that would be helpful. Yeah, cause I think one thing I see, advantage I see here kind of over the node B1 is instead of each repository having a route that has to be trusted on first use and kind of building that kind of issue in is that there's just this one single key that chains the automatic trust. And so they can find one way to get one keys with using the key management or whatever. They can then use that to build this automatic system. And then if they need more fine-grained control that can be built on top of it or whatever. Yeah, I mean, that makes it more like the kind of the next package manager where you come install, you know, you install the Debian keys when you install Debian, but you can add other keys for other repairs yourself. But at least you've got something to start with that works for some stuff. And it's one, it's a key. Whereas the problem about distributing the keys for naturally V1 that like, even when we were distributing just the official image keys there were still hundreds of them, which really made it very inconvenient to distribute them. I mean, I guess it, you know, even with like CA routes, which people do distribute, there's only 30 or so of them. But even then the prices of distributing those has been a bit, well, I guess it made it easier by the fact there's only a small number of browsers and other places which have to have them, but an operating systems. But whereas here we've got a much more diverse set of users. So I mean, I think what you're kind of describing is there's a great, there's a general place where there's nothing configured because I don't want anything yet. And then there's like the Docker scenario where it's a, you know, it's a specific stack that I'm choosing and the Docker client could know how to pull the Docker Hub certs for the certified images, let's just say. But if I want to pull in the Wabbit networks or the Acby rockets keys, there's a way to do that but it probably not on by default kind of thing. Yeah, so like if you have like private repos, maybe you don't want those in the automatic default system. So you can have, you know, your own system for getting those keys and trusting those files. But for anything that's just publicly available, you can just have a default system that makes it easy for everybody to access all of the keys that they need and all of the delegations that they need in order to trust those things just by default people are using some amount of security even if it's not quite as fine grained. So the thing that I would really, you know as we split off parallel work streams is the place that we got hung up on with the notary stuff and amongst others was the ephemeral client scenario. Cause, you know, if you look at the notary and tough update framework work docs, they kind of say, look, this is out of scope kind of problem and it makes sense but we need to bring it in scope to figure out how do we securely take an ephemeral client and all of a sudden have some kind of timestamping information to know how to roll forward and roll back or, you know, protect from rollbacks. So I guess I would encourage. I think here is that this ephemeral client only needs to get this one, probably, you know this one root roll, roll's keys. So they have to get maybe one or two keys to then develop this whole thing which would then be, you know which would be part of the key management solution and those ongoing discussions of how they would get those couple of keys. They could even be kind of hard coded into the configuration because there's so few of them and then they can use that to build out all the keys they need by automatically. That's kind of the idea. Well, I don't understand the timestamp reference cause my understanding is I need to have some timestamps so that when I pull an image I know whether it was rolled back or not. Oh yeah, and that would be stored on the registry. Well, but if I'm pulling, if I have a client with no reference information that I pulled from the registry then if I've hacked the registry assuming I've hacked that too, so. Yeah, so the client does still need a way to get these root keys which then delegate to things like timestamp, et cetera. And that is definitely something that we need to solve. That's a really important point. That's what I'm saying is that would be a great area to focus on and how do we do, what is the proposal and how a client can build up some kind of state in a standard way because it shouldn't be here's how you do it in Azure, here's how you do it in AWS, here's how you do it in Google, blah, blah, blah. It's here is the way that you do it. And by the way, in my environment I get it from this location but all the APIs are the same. So that would be a really good. There's kind of two main options I'd say there. The one option would be to hard code the root public keys into the configuration files for the informal clients. And then those root public keys you don't need like a couple of those and they can be used to establish trust in everything else on the registry. Or alternately you can- How does that establish trust in it that solves the public stuff? But like in the Acme Rockets scenario I need to get the Acme Rockets key to know that and my Acme Rockets registry. Oh God, you mean in this scenario where you're doing the non-default configuration? I'm not sure what you mean by non the, like I think this is the case where we continue to be too heavily focused on public registries which we're continuing to see those are great sources but that's not where I run my workload from. Yeah, so like if you wanted to get like, yeah the Acme Rockets or some other private repository keys that wouldn't be stored on the registry you would need those to be stored in some file and downloaded using something like the key management solution that I know Nia's and folks have been working on which I think would work pretty well for getting that in like kind of an out of the end way out of that secure way. Yeah, I think there's a reasonable argument for own key management for private repose and it's public content where we want to pre-distribute known content probably but for private stuff, arguably you want full control over what you trust around your own private content and you're not gonna delegate that to someone else. I just, I'm asking, can we get someone to focus on that and say here is what you should do so that when the update framework folks are looking at the like, yep, I agree that you've actually got rollback protection with this flow and not wavehanding, hand waving and say, yeah as long as the keys are there, you can do it. It's a brand new client. What is it that the customer, the user has to do to be able to get that in a trusting state? Yeah, so they have to have the root keys and then they use the root keys to look at the snapshot file and verify the signatures of the snapshot file which then tells you the current state of the registry and all the repose on it. It's the general idea. Yeah, I guess I'm not asking to try to list it out exactly in this call cause I think there's a lot more work to be figured out. I'm just saying that is the scope is, I've got a brand new client, walk me through step by step the APIs that and what would be extracted and configured for how a user would get a machine into a stable state. And that would be the great, you know just kind of like we've been mocking out here is how you sign and push and discover and pull images to a registry is how would and we're completely punting the key how it gets to there. That would be great to see here's how we can do this with the update framework on taking that same empty client and getting it into a reliable state. Yeah, I'm happy to map that out and share it with everyone. Awesome. Okay. Well, I don't have any promises on what we'll get done this week because we've got a couple of things going on. I'm hoping that I'll get some time with the OPA folks that they can start getting that end to end part of it going and I'll check with Saje and Avaral and Shilwa and see how we're doing with the distribution API updates to kind of rev that under the covers. In theory, the experience that we just showed wouldn't change. It would just be when somebody who cares is looking at the distribution API stuff. They go, oh, I like that better. That is what we talked about. It's not as many round trips and it's got the configuration persistence that we like. So that's what we're trying to do is reinforce the walls behind the demos that we're looking at. And if there's no other questions, we'll end a few minutes early. Just trying to remember how to pronounce the persons from Erickson's name because I wanted to say thanks for coming. So I guess I just said what I intended. So thank you folks and we will see you next week.