 Good morning folks. Derek said he was going to be a couple of minutes late and we're waiting for Niaz to kick off the agenda. Let me post the agenda. Great. There's Niaz. I didn't get the agenda up till this morning, so total fail on me. So I expect others will watch online if as they grab the time for the other things that were scheduled. So, we'll give another minute or two. And then we'll let folks, we'll let Niaz kick it off. Oh, Jesse, sorry, other issues. Okay, well, you can hear. All right, good deal. We will watch for the chat sessions for comments as well. Niaz, you want to kick it off? Yeah, sure. I can give some brief updates. Can everyone hear me okay? Yep. So, on the key management side, we published, we had a pull request for specs a while back. We've been working on refining those specs based on the feedback that was provided and added in some architecture diagrams. I'll be publishing another round of the close to final specs this Wednesday. I'll post an update on the Slack channel once it's out. That's something we plan on reviewing this Friday and closing out any opening issues. This should give us a spec to kind of work backwards from for the design. In addition, there are a couple of docs that I plan on presenting next Monday. One of them is to look at the different approaches for certificate authorities. We've had some conversations around whether we want to use GPG signing, whether we want to use X519 certificates. This one is something that we feel should be discussed with a larger audience to decide what's the path forward there. And then the other doc looks more into trust or distribution. One of the things that we've come out across in like with Notary, the initial one since you had a signature repository, you didn't really need to think about how to configure keys. Here right now, the initial design for the signing management relies on the manual mechanism. We think there's a potential here to morph the Notary repository into a trust repository that can be hosted by individual publishers, could be hosted by repositories. There's a few different options we can take there, but we want to put together a doc for a larger discussion with the wider group. Sweet. And there was a comment a couple weeks ago. She always does have a PR for an idea for what we were thinking about with Tuff and registries. It was really, I wouldn't say it's a complete idea, it was really just a capture of the state where he was as we did the split. So it'll be great to kind of make some more progress and then we'll hopefully be able to come back shortly and kind of converge some of those things. Any other questions for key management? Marina, you're the one that pops to mind the most here. I think I need to read over that latest version to fully form questions. I'll try and make the meeting on Friday and come with us. Okay, great. And Derek, perfect timing. He has just finished up key management. I was going to talk about some of the stuff we've been talking about with the distribution stuff. So let me share my screen. Yeah, that one. So as mentioned, for a couple weeks now we've been active on how to persist signatures in a registry. And as we made progress on what the prototype one for signatures could be, and we talked about how we'll defer and look at the update framework as a second wave as we work out some other issues of it. The thing that we've been spending the last couple weeks on is how do we actually persist, discover, and pull signatures in a registry. So we've been looking up in the things we've been looking at with artifacts, OCI artifacts, and how we store additional things in a registry besides images. And we took to kind of summarize it. When we first were proposing this, it was kind of anarchy, if you will, not anarchy, what is it here, here's heresy. And we've been able to make, so we really made sure we took advantage of what was already in place and not making any impactful changes. In fact, the spec says you can store additional types in this media config, for instance. So we made good progress, we've seen a bunch of other implementations happening with that approach. And there is one that was sitting out there for a while with CNAB on collections that we've been struggling with. And we kind of deferred it a bit until we had more thoughts about it. So what we've been talking about signatures as something I want to store in a registry that is obviously referencing another artifact, an image, or a home chart, or other things. It's teased up a couple of things that while we assume we were just going to put a way to define index to have a type. It's kind of asked the questions, what exactly are we thinking about with these collections. And then there's some interesting questions around how do I, how many calls do I have to make to a registry to get the data back out. So that's the thing that we've been spending some time working on Sam, who's out today for holiday. Derek, Jesse's joined the conversation. Cormac has been a big part of that as well. And then a bunch of people behind the scenes that kind of feed into that information. So we can give a little status of where we're at and you know we can do a little bit of a working session by trying to capture some things that I think summarizes the questions we've been having. Let me just kind of do the PowerPointy thing because this is what I was able to scramble with this morning to kind of summarize. In a distribution, we can store these individual types, which for the most part have been container images. And then without it being a particular order we've talked about how we can now not talk about people are storing singularity wasm now so low was the latest one that's using wasm for just replay, not for actually running it is on a browser but actually plug in. So we can do an extensibility model with that. And then there's this interesting collection that we're spending more time on whether it be helm charts or even Terraform we don't official have Terraform yet but it came up in the original conversations. And whether it be an Azure resource manager template or a cloud formation template and so forth. That's how we've been thinking about the individual types and we've been thinking about these collection types being seen have been signatures. We've been challenged on how you're thinking about it. And the more we've been thinking about it and questioning some of these, especially lately with the helm chart stuff that's been going on with this progression from Helm we pose, which was the initial incubation that we did for chart museum implementation in a registry, realizing that didn't scale very well so we wanted to move to the artifact approach. It was that it was one of the initial incubation that motivations to get things to be in a registry. And when I thought about these more because recently we've been talking about how do we deal with Helm chart dependencies for instance. It teased out some things that the conversations Derek and I've been and others just seeing Derek's picture here's reminding the bothers I've been talking about that make me wonder a little bit more about this. Because these are all artifacts that need to reference something else as well. And if I think about this a little bit differently. If I've got an image, which is of course the first thing we put in a registry, and I want to have a collection of signatures refer refer to it. If we think back to one of our principal requirements for artifacts is or signatures but all of these is I can't change. Well, the thing that's awesome about it is that it's immutable by design. Right, you can't change the digest by definition that is a solid thing. We can use tags to be a thing that we can refer to that is updatable but the actual thing we put into a registry is absolutely immutable by design. And then what we said is when somebody's doing a deployment, whether it's an image a Helm chart or other things, we want to make sure we can honor that the thing that they reference doesn't change. And the one that's the bigger problem is of course a digest. If I reference a tag or a digest, as it goes through the workflow that deployment chart shouldn't have to change because I've added other information. I've added other signatures throughout the like workflow so the net monitor is built by web at network so they might they could technically put the signature at the same time if they wanted. But as that image propagates the Docker hub and they want to make it certified or it moves into the active rockets organization and they want to put a signature on it. Those are additive. An interesting way of way these collection types can point to something else, but the net monitor image itself doesn't know anything about these other types. There's a directionality there. If I think about a helm chart, it gets interesting as well is one of the problems that we're sitting with home charts today is a home chart is treated in a registry as a chart. And they'll take JSON object or YAML actually. We actually don't have anything about that from a registry perspective that knows the helm chart is actually referring to a couple other images. And interesting there is it is pointing at the images. Again, the images don't know about this thing. But if we look at these two, well, and that would be very helpful for us to do to know it helps us to know for a vulnerability scanning. Is this chart secure. Well, does the chart actually refer to secure images. Does the chart maybe have some configuration information that violates some policy of ticker company. So being able to express more about the types of information that's in that and how the linkage between these becomes pretty interesting. What we see between these two is I can have a thing in a registry, and it has either one to one. So a signature can only point to one artifact, at least that's our current thinking. I am signing the single thing. It's kind of weird for it to says it signs a collection of things with a signal signature. That's a reasonable thing. Whereas the chart refers to multiple things. So there's an interesting ordinality there. So we, I've kind of breaking this up now instead of just two, there's actually three, because if I think of some of these artifacts, you know, a signature has a reference to something helm charts references terraform arm and AWS confirmation Azure CloudFormation template might reference other container images, or I might reference other scripts for how it deploys the database resource let's just say in the cloud, or where key manager key key references are made. So I was playing a little bit more a CNAB and to be fair, I was trying to do this just before this call so we'll see how this works out a CNAB. Today is designed in a way that conforms to what registries can support. In fact, it was designed around a lot of ways around Docker hub, which doesn't get support additional artifact types, although it's in the works and Justin's been asking me to vote up the request for it. But the way it is CNAB works today is it makes a reference to an invocation image which is basically just the Docker image but it could be a VM as well. And it today, you know the other images that it might reference are actually other ones in that list so they actually use an OCI index. And that's changed because the helm chart itself or the other thing that they're trying to deploy. They actually stuff it in the invocation image, which means that just because I update my home chart I have to rebuild the invocation images as opposed to saying I have a, an image that I trust that I verified for my environment, and all I'm doing is just referencing a different chart. And that was based on CNAB was being built at the same time we had started OCI artifacts actually we started OCI artifacts because of we see we saw a pattern of helm chart CNAB Singularity Terraform blah blah blah. And I were to rethink the well I if I if the CNAB team were to rethink it, you know, what they might be able to do, assuming we couldn't support this is a CNAB actually references the invocation image, which references the helm chart which references the images So now I'm starting to see this chain of dependencies that can go through, which are no different than any package manager does for referencing its dependencies. So that's kind of honestly that's as far as I got for the PowerPoint today. So I'm actually just wanted to use that as the tease up to how we might think about these in how we do these dependency management, because today a manifest knows how to reference a collection of layers and a config object. And those are just other blogs. And the thing that we've been talking about is, can we leverage that infrastructure to reference other things. The last piece I mentioned for discussion is the piece that we've been spending that, you know, as part of this. We see where I captured it. I think I did I put it in here. Let's talk about garbage collection. Basically, though, a registry today knows how to reference collections, because it needs to know those for garbage collection reasons either eventually somebody's going to have to delete something. Or. Well, the other part is when I upload in a, so the way a distribution works is you don't actually upload a bunch of things as one transactional boundary. I would upload a blob layer one layer two layer three sonar that three independent uploads of blobs, and then would upload the can an optional config object. And then I send up this manifest that says, by the way, here's all these things that I just uploaded, and how they all linked together. And the manifest that stitches those things together. And if anything happens and the manifest doesn't get uploaded because the network went down. It got routed to long direction. A machine blew up whatever that the registry has logic that says hey I haven't after a certain amount of time. I haven't gotten any linkage to these objects. So it's going to garbage collect and toss them. And the collection and maintaining those references extremely important to registry and that's the approach that we took for the original artifacts design was to leverage that infrastructure. Today registries know how to upload manifests, which is a config and a collection of layers which we've argued are really blobs, or an index collection of the collection of manifests or indexes that have reference. What we're really talking about here is, do I have this other thing that I can upload into a registry and if we can do it in a standard kind of way then we can support signatures we can support help charts in a better way. We could support basically any package manager into that registry infrastructure. So that's, that's where we've been at is the stop there and terrorist was the most obvious one was part of this conversation recently. So I guess from what I was advocating for last time is, I agree with the change of that in a collection type that is not index. I was advocating more that we kind of separate that a little bit more from the image definition and maybe move it toward the artifact definition. Just because as people are coming in, they're coming to the wrong place and there's some confusion confusion over like, which manifest type they should use and whether or not these stuff that's defined under as no CI image is really truly generic for like Helm charts and everything else and we know that the types are defined in a generic way. But they're not really documented as such and it's, it's, it's really confusing. I agree with that approach. And, but yeah, I think if we can separate it into the artifacts types we can get away from some of the issues we've had within with images such as like indexes referring to other indexes like some registries and some clients don't support it today. And just because that's that's not what they expect. And there's a fear that if I supported saying index point an index, like where does that stop like can, like how many, how many levels deep should I go and fetch these, these objects. So there's there's been those kind of issues of like from an image perspective or an image client perspective how do I understand a structure. So we have an index that's referring to another index. So, like, yeah, we have these two types that are that are fairly generic and design the image index and the image manifest. But the relationship between them is not so generic today. And that clients expect to handle them in a certain way. So yes, we can reuse those types. But then the question is like, well, what do you do when you come across that type you just does that as a client just intended to be confused and throw up it's. Throw up its hands and and not understand it. So yeah, I think the adding the config to the index is a good start. But I think we should further that which I think we should further separate that from the image definition completely, rather than trying to use the index, because yeah image image clients. Okay, that's, that's the bulk of what exists today. So, like, I'd rather almost not touch, touch that part of the definition and let's define something that's, that's generic. The other aspect is the signatures. And honestly, I'm not convinced that signatures need to be an artifact. They even need to be an artifact they do behave differently than everything else that we defined here like even the one to many relationship. We're talking about an object that has some eatable tag and then we have signatures, which point to that objects. But we don't necessarily have tags which point to that object so that was kind of the garbage collection issue we talked about or if we, if now we have these like dangling artifact types that are signatures and we have to treat them especially and we have to have special endpoints in the registry just to fetch them. What's the point of like, they're not really generic, anyways, we might as well just have. We might as well just consider having endpoints in the registry that are specific just for fetching just for fetching the signatures. The reason I like that approach is I just think it's more optimal for clients to say they have these signatures, give me these or put these signatures on this, on this hash, and I have this hash give me all the signatures for it, rather than like tracing down a bunch of like artifact types in order to like, like, yeah, it's a nice structure, but I'm not sure that it really fits in with like that it's that a signature is really an artifact rather than a signature is metadata on an artifact. And if, if we should separate the two. So, at least that's my thinking on what you, what you talked about. Yeah, I mean, the, that was kind of what I've been teasing out in the. I think there's a lot of confusion that you kind of, well, there's two parts. One, there's the untagged manifests thing. You know, there is, if it's untagged, is it subject to garbage collection, or should registries store those as one. It's a very nuanced I get it's not the main focus what you're saying it's but there's definitely a new ones there because I can't think of a good scenario, not a good. I can't think of a common scenario where the signature itself needs a tag. It really is just an additional piece of information on an image or any artifact. And when I look at a repository and I want to see the stuff that's in that repository. I want to see the artifact with a be helm chart an image, you know, a singularity. The fact that it's signed is like this attribute that's on it. It's not really the signature itself isn't something I want to see I want to see that that artifact has a signature. The question I'm struggling with a little bit is how much the special case, any one of these, because that's, that's actually how we got into this in the first place was we were special casing helm repos in ACR. And you have done CNAB singularity and others came along what. So we decided to generalize it and we found that that was more valuable what I'm wondering here is that are we hitting the next plateau of that same generalization, because I definitely don't want it to be such a high compute network process to go get signatures and you know defeat its own purpose. Other signing security is always supposed to be hard to where wouldn't be used secure I guess but I don't really buy into that. The thing that I'm, we've also been starting to think about this metadata services, and I've had this draft that I've been starting on, because if I think of a set of attributes that I also want to be able to add to an artifact. I wonder if this is just another one, if it fits into one of those. And the, the main piece that I'm struggling a little bit with. And this is what came up in the call last time that Sam and Derek were pushing on this and Jesse as well is if I push a thing. Do I need to push if I push a thing as a blob, or whatever I push it as. Do I need to push a manifest that describes the relationship, or can I just say, link this thing to this other thing. That was the core of what was coming up because overall who's been implementing this for ACR or for notary but to the ACR team was also kind of, he actually built that API to begin with and I was kind of struggling with that. I think that's almost the core of the question is, do we need a manifest as the way that you link things together, or can I just say I uploaded this blog by the way link it from here to there. Regardless of what the thing is, whether it be a signature or something that says by the way this is my production, you know, all the other metadata APIs that can put on it. Yeah, so I was just just thought about the order of signature discovery. And I think that I don't know like the answer just kind of the thought I had was, if you discover the like the artifact and then the signature. I think you then have to take another step backwards with with whatever key management system to discover, you know, who created the signature and whether or not you trust that signature. So I think you'll end up having to take that step for every signature of the artifact. If, if you go in that direction, rather than saying, this is the person I expect. This is their signature. This is, you know, the artifact that was signed. There's something about the overhead of all that discovery. I don't know. Yeah, help me with what you're there's an ordering thing you just mentioned I'm trying to like the idea is my deployment script says this is what I'm deploying. But to your point, it can't be deployed unless it has this signature whatever that signature is. So what, what was it that you were kind of getting a point that we have to know if that signature is valid right. Yeah, exactly and I think that it might just be missing a step in the order somewhere but I think that, because once you find say this like 10 signatures on an artifact. Maybe there's only one or two of these that you actually need to verify, but do you have to download all 10 of them, you know to see who signed them whether you trust them. You know where in the process are you downloading each of these things just to prevent, you know, downloading all 10 signatures when you only need this one or two. We can just put it back and actually, you know, yeah, and that's exactly what we were talking about in this ordering is because we've generalized it so much. All we know is it's a descriptor. And the self doesn't even say whether it's a signature or not much less the signature is signed by active rockets versus web networks or anything like that. So, there's an interesting question around. When I see a collection of something, and I'll bring back our the actual one here. So when I see a collection of signatures, how do I say that if I'm an active rockets this is this is the only signature I really care about so don't make me download all three. Just to find out that yes, it does have the one I care about and then there's a whole bunch of other checks, whether that's the battle signature also. Yeah, I think that's what makes the whole idea of a signature as another artifact. Yeah, because then you showed that possibility of having like an artifact kind of discovery URL or you can say hey I have this, I have this manifest or I have this, I have this artifact show me other artifacts that are related to it. And yet, yeah to read this point that gives you a bunch of stuff, you still have no idea what it is. Now you have to go and download each of those. And, and some of those you'd have to actually do to download to even get to the signature before you can like verify whether or not you need it or not. Yeah, for a minute. This collection doesn't actually give enough information to be no attention to this is an extension to what. Okay. I mean, I guess like you use the word attribute earlier but I think that's good because I think we've done a good job defining what a artifact is. But to me I have a hard time seeing signatures fall under that definition attribute almost makes more sense there and you know then it then it can make sense to add other properties on those to do filtering if we needed to like, if you like, if you have a bunch of attributes. The, the hash of the artifact is could be one of those attributes the tag associated with it could be an attribute the signer of it could be, could be some of these properties that maybe we filter on to even get these signatures. generic way of the collection of things that could be associated with the thing I care about. How do I get only the subset that I care about. Because I could have lots of signatures I could lots of metadata on it. I only want the subset to come back. Yeah, I think that's right. And I think from the standpoint of. The API like signatures could still be treated like blobs but maybe. Maybe just need a different way to actually like that's them. So it's like, I just, we can try to generalize it just, I think we're going to have a hard time generalizing it as an artifact to try to treat signatures. We can see now in, like, with the same API, just because they're inherently different things like, like, and are they. They are as we said like, like signatures aren't something that are tagged signatures have kind of a reverse one to many relationship is, you could have one artifact that has many signatures. Signatures can go away it doesn't change anything about that artifact. But it's referring to, and yeah, maybe there's other properties, or maybe there's other types that are similar to that like S bomb, for example, or some of those. Some stuff that are signature like any anything that we'd say was what like in something that attests to the quality of of an artifact. Or can it just be some kind of other information. I think the pace that gets very interesting, which is what the key management part will be really helpful with is if I am told that this image was released on this particular compute node. You know, on Monday, when it was built three months ago, you know, that information is really helpful because I may not delete it because I know it's deployed. Whether I how much I trust that information could be nothing more than it came from the registry and the registry hasn't been violated, maybe can see what pushed it because the who was not involved. It's probably some CI or CD system that put that piece of metadata there. And as opposed to a signature, there's two parts one is who pushed it or what pushed it to know whether it's valid but there's also this other thing that says well, is the key still valid. Now, whether the key still valid part actually goes through the registry as a persistence model or there's some kind of key validation thing outside of it is the interesting part. I'm just seeing my mind go a little journey here of like, where is the generic versus the specific thing like what makes a signature so much more important or different than any other additional piece of data that I want to put in the registry about a thing. Because we don't put information in the registry about a thing we put things in the registry. Not yet. That's what this whole metadata thing. There's been so many different efforts around putting metadata registry and we're all doing it in a weird not weird we're all doing it in a way that makes sense for our clouds. But there's no generalization of it. So something I've been working on. I haven't even gotten to the point where I feel like promoting it to the main branch but it's how do I store a set additional information in the registry. But in a common way so the same way when an artifact moves between web networks the Docker have to act the rockets that the metadata can travel with it. Or from a development registry to a production registry. I'm not trying to boil the ocean here I'm just trying to see where, where's the right pattern, because I do believe that signatures are important enough that the very if we decide to come up with a unique API for that just supported that's an important enough scenario that I think the other registry operators will implement it because we all have the same need where come charts. I'm not saying that I don't necessarily think it has to be something that only supports signatures like yeah maybe the approach are on here. Search said seems like a decent search API could fix this like, like this true it could just be where we need some way to handle objects in the registry that like they need to be associated with something but we need to be able to find them. And that's kind of what Rena was saying is just like, well, what do we just like go through everything and then till we find something that works, or is there a way that we can just constrain what we're looking for. And, you know, if that if all this metadata is a separate artifact and those like, yeah, maybe that's fine I just I think the API still looks different. Looks quite a bit different from how we normally use artifacts today. And when I say artifacts today I mean like, we have a tag and from a tag we get a immutable hash and then from that hash we walk down a tree of objects that are related to it. Yeah I would just add those are all very good points thanks thanks for raising them, both of you. I would just add that sometimes you do want to so not not we also I think a good reason for adding a new API is that we don't want to unnecessarily constrain ourselves it's certainly possible that what we have there can actually do what we want it to do. So that's that's but that's one possibility we need to consider that we might need more flexibility. So new API will give you that. But the second thing is sometimes it's conceivable. It's possible that it's a use case where you actually want to get this metadata first whether it's a signature or whatever it is you want to associate with an artifact. You want to get the metadata first, whatever it is, whether it's say I don't know scan results compliance scanning results or signatures or what have you graph yes metadata. You want to get all of this first before you get the artifact, you don't want the artifact to tell you where to get it. So this direction might become important. Does that make sense. I'm actually the scenario scenario has got a little confused on but the idea that I want to go use the metadata to figure out what artifacts I want makes total sense like this is one of the auto purge thing that we've been working on is because I put stuff in a registry I want to know when to delete it I want to differentiate the stuff that's deployed versus the tough that I just built and happened to put there. So in that case, I'm looking for what content is supposed to get deleted today, because we set these expiration dates on it which could always be extended. So your point is I want to say give me all the things that say delete TTL or deletion date now, whatever. And now I get a list of artifacts back so there's this bidirectional referencing that today registries are really good and really optimal because we just have gigatons of data that has all these references that there's this really great, you know, one way reference. That happens. What we're really talking about here is the ability to store bidirectional references. And anybody that's built anything at scale is always like I'm not using a database that doesn't scale which of course is not completely true but it's the challenge we all face. I think the point here though is, I think the point here though is like the, the ordering like yeah we talked about the relationship but yeah if the ordering is, I have to fetch tag and then from tag I fetch manifest and then after I fetch manifest I fetch signature, maybe the ordering that is ideal for client and I think it'd be great because like how we do things on container D today is we have a explicit resolve step where we start with a tag. And what we get out of that tag is a digest that we trust. And it'd be nice to have an API where we can say, hey registry I have this, I have this tag. And I'm looking for a manifest or I'm looking for a digest, an artifact is associated with this tag. And the registry could say, here's a set of signatures that attests that this, that this tag is associated with these. These are artifacts and I could verify that and then once I verified it I can actually fetch the, fetch the artifacts. I'm not a huge fan of the tag API today I don't think it's, it's not really a great approach. So if we could solve that along here like, I mean that's that's kind of what node review one was, was solving a little bit just and then we'll solve some of the other parts of the problem. I'm just kind of making a note here that there's actually like these three different things. There's artifacts there's metadata signatures with what we've been taking the approaches everything's an artifact. And it creates strangeness that why do I have tags for this, it's really not its own artifact. It's, it's metadata or it's a signature, and whether signatures become that special metadata is the question that they, the main thing is that there's differentiation between these two, which are additional elements of the core thing. I don't think of a helm chart as metadata I don't think of singularity as a metadata. I do think of signatures and what date something's going to be deleted as additional information I put on a thing. And tags to we should, we should put tags in that same categories. Exactly, sometimes you want to trustworthy information, right source of information to get attacked in the first place totally agree you may not have. That's interesting though because tags are tag itself is a pointer to a digest that can be updated and arguably should be blocked from being updated in certain circumstances. Until the break glass scenario is allowed. Not notary to be one, that's, that's the point. I mean if you're using notary to be one you don't even use the tags of the of the registry. And the tags are a collection of signed objects or it's a signed collection essentially. But the funny part is that's that is one of the fundamental reasons why we're in notary to conversations because they were too tightly coupled. Well, they were tightly coupled yet in separate stores, which made the experience really confusing. Yeah, I mean I think we want to unify the storage but I don't think that the problem with notary to be one is that it was signing tags. I mean I think that was review one string. So many pieces. I was more referring to if you the sign tag was stored somewhere else like I can reference that same tag and if I didn't say I want the sign version I get something completely different. That's kind of the part that's broken or the, the fact that the, well it's not really a tag problem the fact that the repo, the path of the repo. And the registry were part of that signature was also part of the problem, because you couldn't do movement. I mean I guess for me I just want to see. I don't think we need to couple these. This work here so tightly with like the generalization of the artifacts work like I think that work should continue but I, it's clear that we need a extension to the distribution API. Once we do that like we're not so we're not tied to the way artifacts work today, like, we don't need to do like, said it's kind of like a half measure I want something that that's kind of like artifacts, but you have to use it in a completely different way. What's, what's the point like what are we actually gaining from that like we should be optimizing for the scenario we're designing for which is, which is signatures basically like, and if we can design it in such a way works it's generic. Then we should do that that we still need to like design for like the optimal scenario. So the good news is that so overall she way have been continuing to make some progress, there's been a couple of things they've been dealing with that had some delay was hoping to show more updates on a signature persistence and retrieval with the conversation we were having. The thing that we've been trying to do is make sure we always have a track moving forward, while we're having these additional conversations. So they were actually implementing the APIs that we had in this PR where, yes, this one where it basically has the refer metadata, which we know we've got problems with, or concerns with. It actually is kind of halfway it actually persists the, we find the right storage yeah so what it actually does it actually persists the config object, which so it's kind of a halfway optimization. So it allows us to test some of this and allows us to think about how we can better optimize some of these calls. So I'm hopeful by next week will be able to demo this although next week I'm taking off or whatever that means in covenland. I'm making a progress I'll die I'll dial in on Monday morning. So here's here's where I'm kind of hearing let's continue to make the prototype efforts on specific around more signatures. Todd he's going to start helping me and he's another PM on our team he's going to start helping with some of the metadata API stuff. We'll kind of treat that as almost a third prototype range to see if there's something there around some generalization API but we won't stop doing signatures. Because we think there's something else the same way we shipped a home repo work while we did artifacts. So let's consider that approach here. So we can definitely get some something working and learn what we don't know, while which continue to iterate on what we do now. Yeah sounds good. Yeah I think the, what I would suggest at the last time is we talked about having this API to read back references, but just a notion of having the API. You should have a read reference you should have an API that kind of puts those references. So like yeah if we can generalize that to metadata and use that for signatures that'd be great. That'd be great as well. But yeah I think it was also an interesting idea. I know we don't want to. We said you want to avoid boiling the ocean and like search API is definitely that but we should take some of those ideas though around like how, like if we have if we generalize the metadata we might want to generalize the way that we actually read back that filter that data I guess search API in the end is just kind of a filter API. Yeah exactly. Exactly. I think it gets more interesting when I can do a couple of parameters. But that's where it gets even more complex but the idea that I can do a basic filtering and ordering is pretty important so. Yeah just within a single repo. I mean the search API I think was designed to be like cross repos and that's certainly out of scope for for here, I think. And for this it is like the metadata that scenarios I want all of the all of the artifacts that have to get deleted today. So that is, you know, a multi repo kind of query signatures is not to be completely fair and even metadata. Because if I want to get the metadata for an artifact when you're starting from the artifact, then it's obviously sculptor repo because it's the thing and I want to look to associated with it. What I'm doing the opposite is let's give you all the artifacts based on this metadata. That's a little different. And maybe that's a good way to separate out. Is it pronounced surge or Sergey. I don't want to mispronounce. What's the name. Search. Search. Okay. So I could see getting signatures from different repos. I think we, I think we discussed some of that early on about the notion of like, kind of cross like sharing signatures across repositories. Anything that's cross repository is it's has inherently different like access control model. So I mean, I could see having an API that's almost exactly the same across repository as it is for within repository, but I don't see them as being the same endpoint. Because you have like a search within repository, maybe like a global one, but the access control would definitely be like much different, I think. Yeah, I didn't mean to imply that we need to do that now just meant that we don't need to rule that I don't think ruling that out is something no one ever wants is right. That's all I'm saying. Yeah, but I, I guess the thing is, yeah, as we get more generic we need to think about more possible use cases. I think it's good. I don't know how generic really want to get here but I mean, the conversation is the first places we don't want to make same as just signature specifically. I think it kind of is the question like what the cross repo stuff comes up a lot like I do. Obviously a helm chart is a perfect example of a cross repo scenario, because you're not going to put all the images in the same repo that's kind of by definition are the more press image and my sequel image or by definition separate because I wouldn't want to put those in the same repo just because of stuffing into helm chart. So I think we will need to support cross repo references. But I see those references are different than metadata. And maybe that's something to put here is metadata data on a specific object where references can must be capable of cross repo scenarios. Chart references. WordPress. I mean we have a notion of this today with the cross cross repo mounting. It's almost the same situation where, since everything is is just a link. You can create this type that links to something else or that points to something else like you want to link it locally. Like, you mentioned like, can I have a image that points to another repository or a helm chart that points to another repository. Maybe that's good, but what if, what if you don't actually have access to that repository, like what's what's the registry supposed to do. Are you supposed to allow you to do that reference so somebody pulls that helm chart that does have access to it and now they kind of like a security issue to allow like cross repository like linking that you haven't proven access to. So that's the whole idea between cross repo push is like, we don't just say, when you download the image Oh go get this layer from this other repository. We say when you upload this manifest you must first do a cross repository mount to say hey I have access to this layer. And then that will be linked but it will not be uploaded to your, to your repository. Now you're really good point because it's also up for the, the, an object pushing image with the collection layers is an immutable thing in the sense that those don't don't ever get dealt with stuff. The fact that we have these cross repo links is an optimization thing that you know registry implementing different ways for various reasons is good. What you're seeing here is a helm chart or anything like that is the example references another image. The person that uploads that helm chart might have access, and I'd be perfectly valid. Later, the end because registries implemented security at repo level repo levels, you know, for because they're referencing things but owned by other people or there's tighter security put within the same organization. The next entity that comes back and pulls this graph back may or may not have access to each. So, and I understand one of the reasons behind that is like, I want to say I want to point to WordPress. I think your example is 3.1 but you know there's there's also like a specific patch level that you know you don't want to necessarily tie it to a specific release when there may have been updates. At the registry level like usually that level of metadata is not even considered like if it's pointing to to a tag that the client has to go then and resolve like the registry doesn't necessarily consider that a link, at least today. Oh, that's a good point. It's because today we really turn linkage straight to digest so they're hard links what we're saying here there's a loose link because we want to be able to support a servicing event without having to update all the helm charts. And that was a recent conversation here for a CNAP or helm where that came up is they are converting references directly to digest and that I flag that as a bit of a concern because it means that you literally have to update everything. If a servicing event happens, but Okay, people started to drop off probably a good time just to bring it to a wrap for this week. And I am, I am hoping to make more progress on this this was an excellent conversation to not feed into that. And sounds like me has made some good progress getting started up again. And we'll continue the conversations. I do recognize a lot of these things are conversations we really should be having a distribution, you know, the OCI call is supposed to a note of the call. And for those that are trying to figure out. Hey, I'm just trying to get signatures talking about a lot of other stuff. We recognize that it's unfortunate it's it's been the unfortunate dependency is that sometimes to build the thing you need some other infrastructure in place to make this valid. And that's what we're trying to The artifact conversation can be moved back to the regular OCI meeting, at least And the problem is if I did that, I wouldn't have anything else to talk about in this call. So I have been struggling on saying, yep, still working on distribution will come back. I feel bad about that but at least there's some folks like yourselves that have been able to join so they're trying to make progress work. But we will bring it back. In fact, let me check with the agendas this week. And maybe I'll queue this up again for more conversations we can use the call. So, with that, I'll thank folks for their time this week. And till next time. Thanks.