Add a meeting Rate this page

A

Hello, there good day.

A

I can see you, I think, I'd even hear you yeah, I hear clicking. That's not my clicking.

B

No, that was mine. I had to swap the headphones back and forth.

A

I think I try to tune out over the weekend as much as I can, but I did see you posted something on the weekend that I'll go back and look at.

B

I lose track of all the stuff I post sometimes.

C

Good morning,.

A

Good morning, wait, how do I pronounce your name actually.

C

Joel.

A

Okay good day joao, because I have no idea what time zone you're in, I will make any assumptions on the pronunciation of your name of where you live so.

A

We'll give another minute or two yes is first step, but we'll wait a moment.

A

If folks could sign in that would be great I'll paste. The message.

A

Here.

A

Yes, you'll be up to go through your pr, so whenever you're ready we'll just start there.

D

Just setting my.

D

Windows.

D

All right, can everyone see my screen.

C

Yes,.

D

Okay, um so this one is uh revisiting uh some of the key management scenarios that we had discussed earlier.

D

um I know that there's a lot of uh new uh folks that have joined the conversations since we last had this chat, um so I think it's uh it's worth reviewing some of the overview and definitions and personas that we had here. uh The link is uh is in the meeting note um and I think we can take like 10 minutes to read through.

D

We should stop reading um at this point, which is right after requirements for a discussion um most of the requirements that are listed here in previous discussions, we were all aligned on the one place that we didn't have. Alignment on a requirement was a having a mechanism for rotating a root key there's both pros and cons here and we've kept. I've captured some of those in the document. Here we I'd like to kind of, at least in the 20-minute conversation figure out.

D

Are there any additional considerations we need to take into place and if any, what other data do? We need to kind of make a decision here and move on so I'll? Give folks 10 minutes to read through the link and then we can start discussions.

D

You.

D

I wanted to do a quick time check. uh Do we need a few more minutes, or is everyone done.

D

Reading.

A

Maybe a thumbs up for people when they're.

A

Yeah.

E

I'm.

F

Done anyway,.

D

Okay, um does anyone need more any more time.

D

Okay, I think we can uh go ahead and get started.

D

Share my screen again for the.

D

Comments.

D

All right, let's see, let me refresh okay, see a few comments from steve uh should not to become, must not see the same comment throughout think both of what's the difference there steve.

A

uh Just there was two: um I think it was two of them. um This one was, uh let's see, signing an artificial requirement to perform additional actions yeah, it must not. So basically we want to be able to support offline signing, and it's if we say should I'm worried that somebody would build a cli that somehow enforces uh communication with the registry and kind of breaks that flow. So it's more matter to support offline signing. um We need to be able to do it all locally.

A

There was an interesting conversation in the distribution working group related to that and then the same thing for multiple signatures. um I think that was that was the other one.

D

Okay,.

F

So.

D

This doesn't seem.

F

To address the question of um some, if you do it offline, of course they could be revoked in the meantime. Is there some time frame like you? Should you need to be online every so often, or is that just ignored or.

A

Oh sorry, the offline was sorry you're you're you're, bringing the air gap environment. So that's a good conversation too. This is more of I'm an underworld, build client and we've been talking about the consumption of thermal clients and recently, we've brandon's brought up some good conversations around in the build.

E

Environment.

A

You'll be able to build in an ephemeral, isolated environment, that's kind of like the one of the twists on the protecting from the solarwinds kind of scenario. um So it's it's science built and signed, and then, but it's not sitting there for weeks or months, it's built and signed and then pushed through a registry in a secure uh channel.

A

That there's no real-time note into your point. Sure.

F

Okay,.

A

Signing.

F

That sense does that need to be spelled out here or is it? Would it be clear to everyone in that case.

A

In such a way, that's basically saying the offline I'll have to go back and reread it and it's a great it's a great point.

D

I think we should.

A

Track that as a scenario.

D

um We do have a list of detailed scenarios that covered some of those used cases. I wanted to go back and visit requirements first before we do that, but I think that's uh the the use cases so far have really looked more at um deploying in the air gap environment, not necessarily building in an air gap environment. So those are some additional use cases. I think that can be added in.

E

I think one of the concern I have, which I think I've brought up before it's just the um the phrasing that about the validation shouldn't, be perform any additional actions with the registry, because, obviously, at the very least, you're gonna have to pull the signature or the file that that has that information, as well as any any information about how you get that key and other things. I just think it's a little unclear exactly what that.

E

Means.

A

Yeah, it.

F

Sounds like maybe the term it sounds like. Maybe the term validating should be clarified by breaking it into more than one part, because I think you're talking about validating and then okay, we have we we've got keys, we're comfortable with that they're up to date, and then we want to validate versus I've got this new image and I want to validate it.

F

I have to, of course, start by getting the keys so.

E

Yeah exactly, I think, I understand what you mean, but I feel like it could be very easily misunderstood. There.

D

Right, yeah, I think that's a fair point. Do you mind uh putting in a comment, so we can track that.

E

Yeah sure.

A

I think to catch like we want to be able to say I'm trying to deploy this thing. Can I get the signature before I even get like you? Don't want to pull the in a container image scenario. You don't want to pull the image and bring the trojan horse into the environment just to find out whether it should be there right.

A

The idea is, let me figure out, find the signature get the keys, maybe discover from the registry where to get the keys from that's something we haven't actually resolved, yet um I think the pull well. Sorry, let me finish the thought so you'll be able to get the signature, get the keys somehow discover the key somehow get the key somewhere and then be able to validate locally, probably there's something in there about. I shouldn't have to pull the artifact itself to validate it um to move forward.

A

The the the concern that I was trying to raise is probably more on the push side, because there was this conversation that today the way the container clients work is the digest, isn't actually computed in typical workflows until it's pushed to the registry and that kind of breaks the workflow that we're trying to articulate.

A

So, I think the build the pull and the air gaps got co-mingled in here in a way that we should try um to do and do in a clean.

A

Way.

D

So steve for your next comment: uh the additional signatures. I hadn't tracked this as a key management scenario requirement. um I think this fits more into the signature format itself. Do we have a separate doc? That's tracking that.

A

Can you help me with what the difference is, because I don't know how many signatures a publisher would put on the same? Artifact versus multiple entities would put additional signatures on a single artifact.

D

So being able to add in additional signatures, that's really dependent more on how you are formatting and storing the signature right and then I think that's that's something that we want to capture in a requirement that says um what are the requirements for the signature format itself. I think we have some requirements there in terms of where a signature is stored, how a signature is retrieved that don't necessarily tie in with the key management scenario, so we can create a separate uh signature uh format, dock and I think that addresses some questions uh around.

D

What exactly are we designing in terms of what bits and what does that mean in terms of like how containers get packaged? So I think that is an area we need to dive into, but I think that's probably a better place to capture this. This requirement than in the key management scenario.

A

Fair enough, that's.

A

Fair.

D

Which makes the question: do we have a signature requirement stock.

A

We don't have a signatures required in stock. Is we have the the requirements for the notary and then workflows which that is captured in it?.

A

The signature is there to support the requirements, so we didn't really make a requirements. A signature requirement.

D

um Can we track this in the overall dock, then for now, okay,.

A

Yeah I'll pull.

F

This.

A

Out I'll reject this one.

A

I I am curious, why do we need multiple signatures, though, from a publisher like is the is the requirement there that in this same signature file, I'd have multiple signatures or can an author like what I'm still a little? I can throw a sample.

B

Yeah, I can throw an example. I can think of some client environments that might use signing as kind of an auditing method to say this. This artifact that they've signed has gone through the ci build. Okay, now went to the next step of it went through a security team that went through a security scanner on that and it passed the security scanner that might have its own signing on it. So I could see something like that within a single entity where they use sign. For that.

A

Okay, so that's more of just the multiple signatures, as opposed to specifically multiple signatures from the publisher.

B

It would be a single publisher, but multiple signatures. There different roles within the publisher. What I'm trying to figure out is there's.

A

Something unique that it's the publisher, that's signing, multiples.

B

Can we also be looking.

A

Inside your tags, I'm sorry brandon.

B

Can we also be looking at one publisher, signing different tag names for the same artifact.

A

uh

A

All right what I, what I think of here, just the sake of moving forward, is I'm thinking, I'm hearing things more around multiple signature scenarios as opposed to something to do with the key. So I guess I'm we can move on. I I just I'm a little confused by this one like is there something specific around the publisher versus everything that brandon's talk about is completely valid, but I don't get it that it's tied to the publisher, so it I don't think, there's a difference.

A

I'm so curious who's, cncf distribution, because I thought I was I'm curious. Who else.

D

um Can you elaborate a little bit more on the? uh What this uh comment is about the ephemeral clan.

B

Want me to chime in on that one steve yeah, please yeah. So in another one of the discussions I forget, where we were talking about supporting ephemeral environments and being able to inject the keys into that ephemeral environment, and this is kind of hidden on the point that I put back to steve over the weekend, which was that you not only have ephemeral environments, verifying signatures, but you may also have ephemeral, build environments that are creating signatures, and so we probably want to support both of those scenarios.

D

Is there anything that needs to get added to this requirement to make that clear, um because the way I was reading it, I thought it would cover that.

B

I think it's covered um steve.

A

Yeah, I think we might just want to tie it back with those words. Okay, just create the loop.

D

I think uh maybe this is something we need to add to scenarios to kind of go into more.

D

Detail.

D

Okay uh and then marina on your comments, um I think the the clarification here is once you pull a signature and once you pull the artifact, um those two should have you shouldn't you shouldn't need to pull. Anything else from the registry um is what this was getting at uh beyond just sort of like being able to uh pull artifacts from the registry itself.

D

Okay,.

E

I mean I'll.

D

Make it understand.

E

This requirement, like is there any technical reason why that would be a problem to pull additional things from the registry.

D

So we don't want registries to be a dependency for validating a signature. um Registries can serve the signature, but they should not be in the validation path.

E

Okay, but so there'd be additional, so you'd have to have an additional dependency outside of the registry. To then pull that information- potentially yes, okay, but there's, but is there any reason like there couldn't be the option to have that also on the registry um just to centralize things and make it easier.

D

So I think this this is this is one we've had uh previous discussions are. Registered operators can act in multiple roles um in the sense that they could, uh depending on how we align on the key management designs, there may be roles that they take on as part of it, but these should not be part of like what a core registry needs to provide.

D

The goal here really is to make sure that you can move artifacts from one registry to another and have the signatures still be intact and having a registry dependent workflow. There means that you'd also need to replicate additional things beyond just the signature and the artifact. So this is really um staining your requirement to make sure that step is not needed.

E

Yeah, but I think that the requirement there is that images are able to move and that registries don't have to do any additional work. I don't know if the requirement is that you can't use a registry to do anything else.

D

um If you're using the registry to do something else, wouldn't that imply that there's additional steps the registry needs to perform to validate a signature.

E

Well. The registry could be one option for additional steps like you know, because if because I think I could see some situations in which um in which you know, you wouldn't want to interact with the registry, and you want to do a third party service, but I could also see situations in which you wouldn't want to set up all these dependencies on third-party services and it'd be easier to just have that all in one place. I just feel like forbidding.

E

It um doesn't make as much sense to me, even if it's not like the go-to solution,.

A

Yes, what was what was that we were trying to protect with you with this sentence.

D

Okay, so if, if you have, let's say an additional api or additional information that you need to go to a registry for um then when you move one artifact from one registry to another, you need the second registry to support similar functionality right, and so this is essentially where we're building in um additional workflows for signature validation.

D

um I think the probably one way to address this is calling this out as optional, um in which case we can say that some registry operators may decide to kind of provide this additional functionality, but that would sit outside of like you know what a registry operator is required to provide, so a registry operator there's nothing preventing them from potentially operating as a ca.

D

If that's the right, like you, know, design forward, but that doesn't mean every registry would need to be a ca at that point right and we need to kind of make sure you're going back to the original ca that issued the search to validate them.

E

Yeah exactly, I think that that makes sense. Basically it's not um whether they can't do it, but they shouldn't have to do it. I feel like that's. The distinction.

D

Okay, so I'll clarify the language to make sure this is optional.

C

Isn't the should not already a sign that this is optional.

C

If we convert this to a must not.

E

That.

C

Is a problem, but if, if we, if we keep the should not it shouldn't it, can it's up to the implementation right, but if you're gonna be more specific, we can add an optional on in front of.

A

It so basically we'll just try not to have that very coupled thing we did with no rewind is that the goal here.

D

Yeah, essentially you you wouldn't want uh every register to have to set up a notary implementation and then plug signature data from one artifact from one registry to another. For that um I'll, explore making this uh clarifying this language a little bit more optional. I think we're aligned on what this requirement needs to say so I'll track this in the comment, and I think we can move on.

D

Okay, um were there any other comments on the uh requirements? I don't see uh any other posted in the pull request.

B

Some in there, but that might have shown up in a different place, because I think I probably clicked review instead of comment.

D

See.

D

um I don't see any more, um could you maybe go through them and I can.

B

Yeah they're over in the requirements file itself, but it's just not showing up in the comments. So I don't know if I just click the wrong button.

A

Yeah, I see a bunch of comments from marco trishonk.

A

And brandon.

D

uh Can you send me the link to your.

D

Comments.

D

You.

D

uh I see comments from the previous iteration. uh Let me pull what brandon put in I've got.

B

A yeah I've got everyone in there where I was putting the comments directly in the scenarios file.

B

I'm sure I just clicked the wrong button. Github. Does that to me now and.

B

Then so on 28th, the only comment I had there lan28 um just that the push is going to limit the number of apis. We can call- and I know we have apis for things like querying and other things like that- that we might want to be able to run for some of these things, so just want to capture that little piece in there, instead of saying just to push an unsigned artifact, but there might be other things to query or pull or fetch an unsigned artifact too.

B

Okay,.

A

To elaborate like the pulling or pushing- and we definitely want to solve the problem with note review when we're, if you, if you're turned on signing or not you shouldn't get different content like type, should always be the same content regardless. Whether.

B

Yeah, the the actual manifest you pull back will be the same, but the scenario I'm thinking of here is that signing an artifact may require that we query the registry to say: show me all the tough um targets metadata for this thing. So you have to run a query against it to pull that back so that you can send update for the newest, tough art. You know metadata.

A

I would worry about that when we do the implementation, if we did that that way, but I'm not that's what I'm trying to figure out like if we were to do anything with time. Stepping and other things like, I assume it's the registry that have to maintain it.

A

Yep.

D

Yeah, I think, maybe that's also something to cover in the uh signature specifications in terms of what we actually end up signing um an ideal situation is where you're able to sign the bits before they've even gone to the registry right so having to query registry for data before you sign it um might break, uh might reduce some of the things we want to cover there. So I think that's uh that's. Definitely something we want to push up in the signature formats. Discussion.

B

And this that that's a good point where we might be separating the pushing of the signature from the doing the signing itself, so you can sign it locally, do all that and when you push the signature that might involve a couple back and forth of saying. Okay, not only do I want to push the signature, but I also want to push an update to the target's metadata on all the signatures up. There.

A

Right, even that I would say it's an implementation in detail. They I'd still think that would be a there shouldn't. Be any client interaction to do that like what do we want to capture from requirements again? We're not trying to spec an implementation, we're trying to make sure requirements are capturing the constraints we want to work with them.

A

I think part of what niaz was had written around the additional integrations with the registry we're trying to protect from us building this.

A

I don't know that I don't know how to describe the sidecar dual implementation thing. I think we just stick to the requirements. I think we'll be okay, yeah.

B

And I think I found the button that has missed so my changes might show up now or my.

D

Comments.

D

Oh, yes, they show up now yeah.

B

When you say start a review, suddenly, there's everything goes into a holding state another one of my comments line 37 for signature validation must be enforceable in an air gap. Environment kind of goes back to another comment I had earlier of.

B

Does this handle checking for the key replication.

D

Yeah, it needs to um the what we had done when we jumped into the scenarios in the previous iteration was call out what air gapped environments would need to do. Additionally to enable that signature, revocation, whether that was copying, replication data over uh and a push versus pull model. I think there are design considerations there, but the overall design needs to make sure that it can be enforceable.

D

I think there's a trade-off decision here in terms of like you know how quickly we can refresh that data, but a mechanism to refresh that data needs to exist.

B

Okay, so it's it's not immediate as soon as you revoke a key that it's immediately discovered within the air gap, environment, you're, saying, there's going to be an extra process that could be done in that scenario to make it possible.

B

Okay and then, as we're moving between different repositories, make sure I'm on the same page. You.

B

Are.

B

As we're moving artifacts around the the concern I have, there is more when you're assigning tags and it's I think it's possible. It's just something. That's on the client side, so I just want to make sure that we have the same thought process that there'll probably be a clients.process to handle verifying uh tag. Signing just trying to do that on the server feels like it's almost impossible or in in the api itself.

D

Yeah, I think we we had questions around tag, verification before uh around sort of like you know whether what does that offer uh do, we want to enforce digest verification only, um and that might be more a conversation to have um in the um in the overall requirements, um because that does, I think, leads to some challenges. um Yeah.

B

And we've got an issue for that. One opened up already, so that's probably best handling that issue. I just want to make sure that we saw that we were looking at this one, because it could have an impact for this.

B

Okay and then I'm getting into the root key rotation stuff.

D

I will save this comment because I think that's going to be the larger conversation we want to have yep.

B

And then back to the push comment we already. We already discussed that one.

D

We've already discussed. Okay um did anyone have any comments on the uh up to sort of like the requirements here that we haven't addressed it's before the requirements for discussion.

D

Okay- um let's move to this this requirement, then um I think there's there's both sort of like pros and cons here so brandon. Since I had a comment here. um Do you want to elaborate on what your thought process here was.

B

Yeah the thought process that once you lose access on that root, key you're, pretty much hosed in terms of security, someone can make any number of delegated keys, they want to do signing on and they can sign any artifacts they want to, and so your repo is pretty much done at that point. You're going to be forced into some kind of out-of-band update of the root key and getting that pushed out to all the clients and doing the replication. Everything else on that.

B

So you've got that headache, no matter what, and so I'm trying to understand the value-add of not allowing an m-band rotation of a root key. If the concern is someone could also potentially hey, they can potentially use that hijacked root key to make new root case angers. I I think you're already in trouble at the point when your key gets.

A

Compromised.

D

Yeah, I think, there's a that's a fair call out. The way um we were thinking about this earlier is that your route also comes with certain information uh associated with it right.

D

So, um if you think about uh standard x, 509 roots, there's potentially a crl there that you can go to and that crl can give you an invalid response, where you now know that that root has been compromised, so there's a mechanism that exists in tying a specific route as long as that route also has some kind of like a mechanism for sharing, revocation data, where you can notify everyone. That's using uh that route that hey something's broken. You need to go update this the challenge with having an automated update mechanism.

D

There is that now the attacker could potentially have a new route with the new crl, which now they're vending, which means that the you lose that that capability of breaking um your end users, whenever you have that compromise, so that's the. I think the trade-off to kind of consider there um is that. um Do you would you from? Would you prefer to have that automated mechanism of letting your users know something is wrong and then have them decide what next steps they need to take versus?

D

You want to take that step on their behalf, and then you know if something does go wrong. You then have to kind of do a mass communication to kind of get that messaging out. So that's really where that trade-off boils down to.

B

So there be a way when you're thinking of doing these m band rotations that you could say hey if this, if we revoked one root key that that also revokes all the other ones that got pulled into an inband rotation process.

D

um I think we need to think through that, because what you're, what you're, essentially doing in that rotation, is technically not a rotation as much as you're issuing an intermediate. That's also acting as a root right, um and so then, yes, you could you could revoke the original root and that could potentially trickle down, but that rotation doesn't really do much in the sense that you still have to go back and check what the original root is signing off on right. So what does that rotation really then give you.

E

I think it gives you that um the implicit relocation of keys, so you can have your root key time out eventually and after that timeout you can, you know, create a new key seamlessly to users, because you don't want keys that last forever, because um anything can be broken in forever.

D

Right, and so I think, like the way we've typically seen root rotations handled, is you start using a new root before the current root expires right? And you give enough time uh where the two roots overlap, uh rather than signing the new root with the existing root um authenticating. The new root with the existing root means that you're saying that this root.

D

You should trust this root because it was signed with the original root, but then to know, if there's been any revocation or anything has happened, you actually need to go back and check still go back and validate whether the original route was was valid or not so you're creating a chain there and but deciding to stop partially up the chain in terms of validation which didn't really make. uh I don't think quite addresses the the thread vectors there.

B

Well, the scenarios I'm thinking of are you have a user that went through the process to trust your original root key and then you go through the process internally of saying either. We need to update it because the old one's timing out or we need to sign, because we want a higher key length on our root key. You know they're a long list of reasons you might want to rotate a root key right and so for those clients that have the old root key that they are currently trusting.

B

Do you want to provide an automatic method for them to be updated, and so I'm thinking of all those ephemeral builders that might have a key injected in there? Should that automatically say? Okay, I trusted the overkey. So therefore I should go ahead and trust the new key. As long as I verified that everything hadn't been revoked in the process, there.

E

Yeah- and I think that this doesn't like exclude the possibility of an out-of-bound out-of-band um rotation if and when that's needed, but I think in most cases um this question can be solved with an automatic rotation and then only when you know things go truly really wrong. Do you have to bother with all this out-of-band communication.

D

um But having support for this mechanism allows attackers to take advantage and set a new route information is, is, is the trade-off here right, and so, if you have things like, revocation information or other things built into the whatever the root key is signing off on, um that is no longer verifiable and that no longer can be used in a mechanism to stop uh to as a as a as a stock as a stopping function. Right, I think that's the trade-off here that we need to address.

B

Yeah, but if the clients, if the only reason the client trusts the new root key, is because they're trusting the older key and you revoke the old one I feel like that could potentially propagate through as as long as we design this right, and so the question then becomes you know? What are you solving when you say? Okay, the old root key got compromised and you know that's potentially exposing everything well until you send out that revocation out there and that gets approved, everything's vulnerable at that point.

B

Doesn't matter whether or not you sign a new rookie or not with it you're already vulnerable.

D

Yeah, I know I I agree and I would say like what does issuing the new world achieve there right, because, if you're going to still go back and have to chain back to the original root key and um you have a technique, yeah.

B

Yeah in that scenario, once you're compromised, I see you're going to have to go out of band. I don't think there is an inband way to resolve that situation. You've been compromised at that point, you have to send a new key out out of band process, but I'm looking for all the cases where you haven't been compromised and trying to make scenarios more useful for the users where they don't have to go through all this out-of-band process just do regular maintenance on the stuff.

D

There could also be a question here. I think that we may want to look at in terms of uh who owns root keys and what do root keys signify right, like if you think about the traditional model of like ca's issuing certificates like a ca, essentially ends up holding a root, in which case individual developer search rotations. Those things can happen more frequently right.

D

I think that's, probably a question that we haven't addressed here um and I think there may be more of a threat model that we need to go into with those roles in place to kind of determine. You know what is actually the right mechanism here. Is it's a more secure update if you say, for example, like you know, uh a set of trusted routes within a docker client that you could push out, that has certain uh trusted entities that may be a model that that's more uh easier to update routes with.

D

So I think there is uh uh there is something more to be had here. um Do we do we want to take a a pause on this and come back and have like a more detailed talk on this? I think there are more things to consider here than what we've discussed.

B

Let me throw one quick comment out and then I would say yeah if we want to go more detail. That makes sense, I'm just thinking from the scenario of just updating the debian laptop here I don't have to when debian says their old root key is coming close to expiration time and they send a new one out there. I, as a user, don't have to do anything.

B

I just do my regular package updates and it pulls down the package that has the current root keys and because I trusted the old key that got pulled in and trusted and approved and signed everything, and so it makes a much nicer user experience when I don't have to go through a whole lot of external out-of-band processes to get my clients to be able to work with the new environment when they already worked with the old environment.

A

That's a great example of the key discovery and acquisition workflows like not only we've kind of we haven't really answered it yet, but if, if we say we're not going to worry about it, for now, that's fine. I don't have to worry about how I get the docker or the rabbit network signature for that matter. But what you're talking about there is is that problem as well so to be able to?

A

We don't want to do trust on first use, but I think once you have a key to be able to say I can get updated versions of the key seems pretty important.

D

Yeah is it fair to say we need a mechanism for key distribution right um where we can get these updated keys. That's really the requirement to work backwards from.

A

I think so I think once you have it to be able to maintain, it is important. I don't know if, like how do we, how do we do the update scenario without getting into the tofu scenario? I think that's kind of it.

D

Yeah we can. We can look into that as we can start going to scenarios, but I'll update this to kind of capture uh what the overarching requirement is without making any specific calls here.

A

Sweet.

A

So, just to keep to our time frame, this is great. We've been trying to get to a good key management conversation for a while. So this is really really helpful to make all this great progress um so we'll keep it going.

A

Let's try to get through what we can do to get a merge, so the actual uh document reflects our current state and we have to read through all the notes, so I'll I'll do my part to make sure that my comments are in a place that are obvious to be mergeable, and if we can do that in the others, I'll be great as well.

E

um

A

Just on the point of order to get the status update out was there any other feedback I incorporated as much of the feedback as I could um the on the status report. It's in the hackmdoc.

A

Let me just pull it up real quick.

A

And um so everything from the white backgrounds for the dark background effect to there was some good conversation around balancing. uh Do the example commands provide too much detail that you know? Should I pull that out, but I thought actually, there was a really good conversation that came out of it uh as a result of the ordering of pushing digest before their tags, so that we can get two independent entities pushed to the registry um and then later do the tag update without trying to make some master transactional boundaries.

A

So to me that kind of felt like a good balance, um but if there's some more in that way that we need to do that'd be great, uh I think there's a some of the other there's two other pieces of feedback that was want to look complex and two: are we really making progress? Just putting a status report doesn't really show progress, so um the complexity, one's an interesting one, that's part where I can use more feedback as far as making progress.

A

That is another part that I wanted to talk about some timelines on things, but before I talk about the timelines going forward beyond what I put into the status talk, was there any other feedback we wanted to talk about before we merge and.

A

Publish.

A

Going once.

A

Okay, I got a plus one for uh merge, okay, so on the timelines, let's transition to that, um because that is the piece that I think a lot of us are getting in a difficult spot going. You know for the ones that are working on it. We know we're making progress, we always want it to be faster outside of it. There's a lack of confidence because they're, not really it's not obvious um and people are starting to spin up other efforts.

A

That it'd be great if the other efforts were actually as holistic, but they're much more sandboxed and don't really promise the cross-registry solutions we've been working on so um after this doc. I I have one thing related to teleport that I have to go finish up, but once this is my next thing after I want to be able to outline the three. I think it's three places that we need some investment that could use some help, one of which was the validation with opengatekeeper.

A

We talked about doing that. um The teams in azure that are happen to be part of open gatekeeper they would like to, but they're not going to get to it right away because of other critical work they're on. So, if there's other people that are at least close, if not in the gatekeeper open keeper community we'd love to prototype, that uh the reason I really wanted to be close to the open gatekeeper community is, I want to avoid us. uh This goes for all these things, building something that works around.

A

What exists today, as opposed to this, is what we would like to see changed, whether it be opa, gatekeeper or notary. So we really want people that are close enough to say. Yes, I know enough around open gatekeeper to know that this would really work if we made this one change to oprah gatekeeper, as opposed to. Let me manipulate this thing to make it work only because I don't think I can change like these are all projects that are just code, we'd love to make changes to it.

A

So, oh yeah, I am referring to the open policy agent, gatekeeper implementation. So basically the idea is we want to validate this with something very generic like kubernetes, because it's a very open framework and um that we can actually validate the end end review and if we can validate the end to end with a true policy manager uh like that, then we assume that we can do with other projects, whether it be cloud specific projects or other things. That's the premise that we're doing there. So that's prototype, that's effort!

A

One is to get something going there with the validating. The next end. End scenarios, um the other one was uh the cncf distribution changes uh we'd like to see some changes. You know there related to the artifacts manifest spec that we've been working on and the list api that we can get the link list for the signatures out of the registry. uh I'd been assuming that we were going to do that from our side, because we were kind of already prototyping on that. That would make the next round of iterations.

A

um It doesn't have to be us and that, once we have the artifact spec uh artifact manifest more detailed. That should be easy for others to build in and then, of course, is the updates to the mv2 client. So those are the three things um there's something here for the person who won't identify themselves, so I'm quite challenging to even acknowledge them um anyway. I we already time so we can talk more about it, um but I did get a at least one plus one for the uh just publish it.

A

Let's move on um because I think a lot of people keep on asking. I have not been able to say here's the written status of where we're at so I'm hoping this captures it with that.

A

Sorry, I'm looking at the comments uh anyway uh with that we'll post, the recording, we'll keep going and thanks for everybody's progress next week,.

A

Folks,.

A

You.
youtube image
From YouTube: CNCF Notary Project 2021-02-22

Description

CNCF Notary Project 2021-02-22