OpenSSF SLSA Biweekly, 7 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SLSA Specifications Meeting (November 7, 2022)

Description

Meeting notes: https://docs.google.com/document/d/1kMP62o3KI0IqjPRSNtUqADodBqpEL_wlL1PEOsl6u20/edit#heading=h.yfiy9b23vayj

A

B

C

Good morning,.

D

D

D

So hi everyone, um as always, if you could sign in to the meeting notes which I just pasted in the chat and also a reminder that, by participating you're agreeing to the Linux.

E

Foundation code.

D

Of conduct, uh we have one agenda item on the list from Mike. um I could also give a brief update on the salsa, the 1.0. If you have any other topics, just please add it to the agenda uh Mike. You want to get started sure.

F

So um uh yeah so I think, um based on a couple of things that I saw both at kubecon as well as just some general confusion Fusion in the slack in some other areas, there seem to be um folks who are a little um confused by the build service requirement um in salsa.

F

uh For, for you know, sorry for level three um specifically saying that the build service should be the thing that's sort of generating and signing the Providence um and so I put in the notes, um my my thoughts uh about it um and to just kind of go through them quickly. So one of the things I started to notice.

F

A lot of folks are confusing the concept between like a workload, identity and the build service, signing a thing so um for folks who are not super familiar with workload, identity, that's stuff, like hey, you're, um assigning an identity to a single, build.

F

Let's say in this context for salsa, where you're, where you're just sort of saying you know um using something like let's say: spiffy Spire or you know in GitHub I believe each individual GitHub run has its own sort of unique identity um uh and so that it kind of helps protect against sorts of attacks. That could be.

F

um You know you don't have long-running credentials for a single build to lots of other services and that it should also include like signing secrets and those sorts of things now. I think where people are getting confused is they're. Thinking that the build service piece just that requirement just means like. Oh, you should be using a short-lived key and I think to be clear.

F

I think like um something like a workload, identity and an ephemeral sort of signing secret is still valuable like whether it's Sig store, keyless or spiffy spy or any of that sort of stuff is still um uh is still really good.

F

However, I I also think that it that doesn't really hit what's being talked about in the salsa free requirement, which is that the build service should be the thing doing the signing, and so the intent of that requirement, for my understanding, has a has always been that the um the build service so something like um GitHub actions itself or through a reusable workflow or through tecton chains um uh or or you or doing something like through checked on chains.

F

You actually have that looking at what's happening in the building uh in the build uh introspecting the build and whatever and then generating the Providence and then signing it with the um the purpose being that we don't want to have the build generate its own Providence and sign its own Providence, because obviously, a build is um potentially where the user-defined options are happening. It's very arbitrary, what's actually happening in there and you kind of want to have that in a separate trust domain.

F

um Of course, a security domain and so I think that's kind of where a lot of that confusion is and I, and the other thing I just want to add on there is. um It does still sound like something like ephemeral, keys or or um workload. Identities is still probably something that either we recommend or we when we look at you know the the the the other requirements for saying a secure build system.

F

We might say: hey look for secure, build systems that use stuff like workload identities, um but I just want to make sure that, like what we could, what could we do to make that much clearer, because I think there's a lot of confusion around it. Foreign.

D

Yeah um yeah I think uh one thing and Sean had also suggested something nice too like if we could somehow introduce into the specification both The Province back and the course I'll suspect the idea of like trust, domains or security boundaries, or something like that. I think. That's like the big thing. It seems to be. That's the big thing. That's missing that like if we can better explain that I think and have a visualization for what that looks. Like I, think that'll help a lot um I think. That's! Maybe one out outcome of this discussion.

D

I know we also had some others. It's also 1.0. uh What's it called the dashboard um I had I raised an issue before of like does? Is that salsa, three or not so like? If, if GitHub has a effectively GitHub and six door in this case combined, you get an x509 certificate that says this artifact really was produced by this workflow and the security boundary is the workflow. Does that meet level? Three.

F

Yeah yeah so I mean I. Think generally, that sort of thing it probably does um I do think that there's still I know one of the big, and this is kind of maybe something also for the tooling team um to to take a look at which is like.

F

Ideally as much of that information, um we need to I think find some consistent patterns for doing it, because the other thing that we don't want to have is we don't want to, let's say encode a ton of information directly. Let's say in uh I know some folks have been talking about this.

F

Is you know you can encode a lot of this information directly in the x509 as opposed to generating provenance and then signing that Providence about that thing and I just think that that also makes it harder to then ingest that information and and make a like make an assertion like that, because if certain information about the I, you know, if there's certain provenance information, that's encoded directly in the signing Secret, um then if I'm, a user of provenance I, don't know like you know, it becomes a little bit more difficult to know like hey.

F

Do I expect all the information directly in the Providence do I expect some of this information to be verified through the actual signing Secrets or what.

D

Yeah I think I mean I I. Think we should split up like recommended. Implementation versus the actual requirements um like I could see why we would recommend having a standard format, Etc I, think from a requirements perspective. If someone implements it using the next five minutes, I could I could see that, um but like I so I liked this issue issue 321 I, put in the meeting notes um that um if.

D

Like does this, the Sig store thing satisfied.

D

It's also three or not like if you call six door in using the GitHub actions oidc token and get a Sig store, x509 certificate that has the identity of the workflow in it.

D

um Is that good enough for salsa 3 um I? Am it's hard because, like you know, we're we're quantizing things that it's kind of a Continuum um I am inclined to say like it seems like it does like it does meet the requirements that you know you. You basically have a guarantee that.

D

The like this workflow definitely generated this artifact, because no other run would have been able to get access to the signing key unless that workflow Were Somehow compromised, which you know like the code itself, that it's running, has some vulnerability, which I think is out of scope for salsa Mike.

F

Yeah so I I think that last thing you said like answers. The question which I think the answer is generally yes, because I think you know if I look at the intent, if I go back to sort of the intent of the requirement, the intent of the requirement is to make sure that an end user build, which is arbitrary actions right.

F

That could be. If that's the thing that's getting compromised, then it could essentially lie about everything else, whereas if you have it separate- and you are controlling that in a different way, then you get the benefit of saying like hey.

F

um I can use whether it's chains or whether it's the GitHub, reusable workflows, um I, can go and say well, yeah I'm, using that that has access and all it's doing is introspecting on the build and then or you know, pulling inputs or whatever and generating the provenance and then signing that and that's all it's doing and the end user has no ability to do that. None of the actual the compilation! No other! You know any of those sorts of steps, actually have the ability to look back. That I think it it meets that requirement.

F

um I. Think, as you sort of mentioned there also earlier is like we might make particular recommendations just from like a hey generally doing it. This way is safer than that way, but I think they're both hitting the requirement and I also think that, like because I also think about it, um if I go back to like chains, definitely hits that requirement.

F

But you also still have the same issue right where if chains gets hacked well, then you know you're still, you know then you're generating bad profitance anyway and I think it's the same thing here with a reusable workflow like if somehow GitHub itself is hacked. Where you know the reusable workflow is not doing what you expect it to then um you still have that same problem and so I think it hits that I I think it does it hit all the requirements there.

D

Maybe one question for the answer like what would be an example of something? That's the level two but not level. Three come.

F

On so I mean I think when I've seen this uh a bunch is I've seen a lot of folks in GitHub actions where they just have a set of GitHub actions that are all controlled by the project itself.

F

um And you know they have step one. You know pull down dependencies step, two um run the build step. Three use cosine to sign that using something like a workload, identity and step. Four push that out and I think that itself is is level two but not level.

F

Three, because the end user can go and modify that the, because a lot of these things are actually happening in the same uh like trust domain and whatever, like there's a lot more there's a lot, there's significantly more areas where it could be attacked and in certain cases, I've actually just seen a build script and part of that build script is cosine. Yeah yeah, in which case you're literally running it as part of the comp like the same step, you're doing the compilation, and so all it takes is let's say, for example, the npm stuff.

F

You download an npm package that npm package on installation goes and says: I'm going to steal all your secrets. It takes the secrets from um the you know the GitHub action and you know signs whatever it wants.

A

Yeah Aaron in that, if you guys remember, the demo, I did with the git lab piece, so I think that's the example level two versus level three because git lab is, is the build service, it's actually generating the provenance without interaction from the end user. However, it's not signed so I had to create a job right. That's that's from the end user in the CI, that's doing cosine sine on that provenance document.

A

So it's not the best right and that's actually Mark that merge request that I did where I was very specific about level two versus level.

B

A

Right, it's level, two is like hey. We have something, that's like better than nothing, but it's also potentially able to be tampered with because of.

B

A

Or the you know, the end user, the ability to change that signature.

D

Later on, so this is I I forget was this using git lab secrets.

A

uh Yeah, so this would use like the gitlab CI variable, because I wasn't doing keyless either I was just using a private key and the CI variable that was masked, you know, um and to to do the cosine signature.

D

I see so like using like kind of um like secrets that are locked down to only be accessible.

A

It's accessible to like the CI job, but it's also technically, you know the end user could could script any job they want using that secret in a way, unfortunately, um so I'm not a huge fan of the way that it's happening. That's why I'm kind of pushing on gitlab to do the signature in the build Service as well and they're working on that, which is nice.

F

So one thing I also heard from that- is that there's there's two separate pieces right: there is the um having a build surface, generate the provenance and having a build service sign the provenance right, which I think is is really important.

F

To make sure is clear because, like the generation of the Providence means you can't have a malicious developer or a um you know, some part of the build generate fake Providence without at least you having some insight into what happened right, whereas you know the things that when I look at the other way right, you have the build service. Doing this, the build surface is getting a set of inputs, it's it's like all.

F

It's doing is parsing that set of inputs and forwarding it along um uh and uh and so on and and to Josh's point I think like just to be clear. Yeah I I agree with you that like if, if something, if a service generates it, but you don't know if the service doesn't also sign it, then how do you know?

F

um And how do you know it hasn't been tampered with between the time the service had generated and signed it? um So I do think that those things are two are are closely linked.

F

I just think that the they are separate in the sense that um you can generate Providence without signing it, but you still need to sign it, and also that generally you, if you sign it with um like, if, if you need to do both in order to hit it, is what I mean yeah, you can't just do one and have the other sign it or or generate one and then have the service sign it, because you'll still run into that same issue.

F

D

I guess um so, like the workload identity, it's still not clear to me what we, what requirement does it not meet um and if there is no such requirement, but it's desirable that we want to like call that level three, but not level two or if we we say that shouldn't be level three, then what requirement would it be.

F

Oh I mean I think this is so when I think about workload, identities, I think about you are essentially securing that a particular thing is at least spun up doing what it was spun up to do. And, yes, something could have you know, executed into that environment and is tampering with it or something that you don't realize is in that environment could be doing something that that you don't expect.

F

um So, when I think about the workload identity is and I think about the service generation. Piece right that doesn't hit the service generation piece directly or it doesn't, it doesn't hit it because it still doesn't prevent something like somebody executing in to an environment and modifying the um modifying Providence or generate generating bad Providence and then using if it's, if it's signing with its own workload, identity right or something like that like, for example, if you, you know, give a particular GitHub action.

F

Direct access to you know like through something like six store and keyless to sign. Using the oidc token, like you know that only that one build is like you, don't you don't worry it's a separate concern like you're. Not worried that somebody has stolen a credential that they can then use to now sign whatever they want, but they still have signed a bad build.

D

I I think maybe I'm I'm a little bit confused, I! Guess on what specifically your your talking about here. So.

D

The workloaded anniversity build service signing. um If something has client-side tooling, like let's say, there's a workload workflow that does the oidc to six store thing, gets a signing, sir, from Sig store and uses whatever to sign, to generate and sign Providence. All within the workflow, like like a client-side tooling, like, for example, and npm, is talking about baking this into the npm client.

D

um Are you suggesting that would be level two or level three.

F

I would be suggesting largely that sounds like level two to me and the the reason being is, if I have an arbitrary build environment right and like just as an example, the npm thing right, if, if I download one of those npm malicious packages that steals credentials or whatever right like one of those things that you know on installation, time runs a thing. What is to prevent?

F

uh What is the prevent that npm tool, like you know, so what I run npm install what's to prevent that malicious package from generating salsa provenance, signing it with my workload, identity and pushing that out.

D

What so to play Devil's Advocate? What is stopping that at level three so.

F

I think the thing that's stopping that from level three when I look at it from a service thing: the service, if you have secure like if you have secured the service right, which is something that you should just be doing to begin with right and there's an expectation that whatever is orchestrating the builds is like you know, relatively secure and because that build service is not the thing running. The arbitrary actions right you're, not installing you know, uh you're, not running npm, install on the Node. That's running the build service right.

F

The build service is potentially audited and yeah, because you're doing that, then there's less of a worry that you are. You know, there's less of a worry that, for example, if I'm running tecton chains that tecton chains itself gets compromised or if I'm running GitHub, that GitHub actions itself is compromised.

D

Is a concern with like a short-lived signing certificate versus like a signing service like if, instead, you called Sig, store and received a signature like you, give it a hash and you get it back to a Providence versus instead, you, you call it and you get an x509 cert that you then call would that well.

F

So so I'm thinking about it a little bit differently, I'm thinking about it purely from the the perspective of who is allowed to generate the provenance right, like is the build service, essentially introspecting, on what the end user is doing to then say yep. These are the inputs.

F

I got to the build, so this is what I'm signing for the build provenance versus having an end users like, what's under an end, user's, control or or potentially under, like if you download a malicious package that could go in and say, hey I installed these packages that it didn't install. You know what I mean or, or it included materials that are not.

F

um You know that that weren't being uh that it wasn't told to as part of the GitHub action foreign.

D

My inclination would be to call that level three, because it's not clear like what requirement I would point to to say that that why that's not like the distinction seems unclear to me between that and level. Three, because effectively, the bits of the provenance are embedded in the x509 cert. In this particular six-store case, like the the things that are required at level, three are embedded in there. The entry, like the the top level input, slash, I, think in the VO2 it's called.

D

What's it called config source is effectively embedded in x5090 and the list of dependencies and stuff or materials is not a requirement level three anyway, and so that one could be untrustworthy.

F

So I guess uh so: I have a question so um I guess when it comes to and I know that this is out of the scope of the spec itself, but we're from the perspective of like a uh more from the perspective of like a usability piece.

F

So because it's embedded the x509 I agree with you like it. Can't it can't be falsified. However, what happens if you end up with Providence that like like? Is there a concern here? Because we we need to make sure that the end user whoever's consuming the Providence knows that the x509 is the thing to verify it against versus the provenance itself.

F

Right because, because you could end up in a situation right where, if you do have a compromise, build the um the compromise, build might be generating bad Providence or like bad Provident like a bad predicate right, it would be generating a bad predicate, but the x0509 would say well no hold on the x509. Would not map back to the predicate, but the end user would then need to know that it has to check that.

D

Yeah I think that yeah, that's good any sort of Sig store based thing has to do that right because we have this and that's why I feel like it's a little bit weird in our current thing that, like it's basically listed twice, and you have to verify that the thing listed in the x509 cert matches the stuff in the provenance and then it.

B

Says well, why is it even.

D

In the payload, if it's already in the certificate chain, um yeah.

F

Yeah I I, guess that makes sense and I guess my other just open question to anybody else is: is there would there be like?

F

Have we specified enough in like in it to make sure that it's clear you know either you need to have a build service that asserts these things and signs the Providence in this way and doesn't allow the end user build to sign it or you need to have enough information in the workload identity to um uh um or you need to have enough stuff in the workload identity.

F

To sort of essentially say that this thing couldn't have signed something bad like I think we just need to make that clear, because I'm not independent, I'm, not sure if there's enough like, if there's enough stuff, where everything that would be required from level three provenance could be encoded directly in the workload identity, then I think it's fine right. I think that, yes, it absolutely does hit L3, but if there's anything missing, then it doesn't um uh yeah but I'd be curious to you also. If anybody else has any additional uh thoughts there.

D

Yeah and I agree with that, like it I guess, maybe an assumption. I've been assuming workload, identity means effectively everything that is required by level three yeah.

D

Another Pillager most people are just like: okay, that was a long 30 minute conversation, um okay, yeah.

E

I agree with the conclusion: that's all I have tried.

D

Yeah yeah I really want to make this more clear, um because I feel like there's so much of this stuff, where, like people different, have different emotions in their head there's kind of edge cases. If we could at least have like worked examples or something that would be good.

F

Yeah and for folks who are interested I'm, pretty sure this is also going to be a topic on Friday's um pooling meeting. Just because, like this sort of thing right as we're talking about consuming um since we're talking about consuming provenance right, a lot of the provenance tools will have to make that distinction um we'll have to make that distinction about like hey.

F

If I pull down provenance. You should also check to see if those claims are being made in um you know in in the signing search in some way.

D

um Any more thoughts on this.

D

D

Anything more Mike.

F

uh No I, don't think so. Well, the only other thing, which is just something that, in addition, which is just um and it sounds like it might be better suited for the um the the like the generic requirements of like hey this sort of assumes. You have a reasonable build system that is secure, right and and those sorts of things um I think some of that workload.

F

Identity is still things that, like we probably you know, I, don't know if we want to make those direct um suggestions, but but it's something that we want to make sure of is uh um because I think stuff, like ephemeral, um ephemeral, keys or or sorry ephemeral. Finding secrets are still good for other reasons: Beyond just the the the the non-falsifiability piece like some of it's just also the fact that hey, um you know that, let's say your build system was potentially compromised between you know during this week.

F

Then you know that builds that happen during that week were the things that got compromised. You don't need to revoke the root cert. That kind of thing.

B

D

um So so I can give a quick update on some salsa 1.0 work. uh Let me present.

B

D

I wish I could see my preview of what I'm actually presenting uh is this me. Is it meeting notes being presented right now? Yes, yes, okay, um there's, no visual indication that which window I'm presenting um okay I can see my little 10 pixel preview, moving whenever I scroll. So that's good.

D

um So the three main updates that have happened in the last week um there was uh which again I'm, as always I'm just saying I'm submitting them be in order to move things along, but always happy to take comments uh and we'll do a final review. At the end, um one is around framing levels: around tamper protection, um the main gist is. uh Let me open the preview.

D

um The main gist is to say that at level, one um like that level, one is about preventing mistakes, uh but like it's pretty easy to bypass level. Two is about uh requiring some sort of explicit attack, but it's still kind of easy to perform.

D

It's a deterrence either for unsophisticated or like like you, could get fired, for example, from doing something like that like clearly you're trying to evade some sort of control and it does have real security value, um although it's far from Bulletproof and then level three is that forging the Providence or evading the verification requests some difficult attack, that's beyond the capabilities of most adversaries.

D

This is pretty wishy-washy, but I I feel like after lots and lots of discussions, that's kind of what the differentiates the levels and the main purpose and the rest of it. Just kind of follows from that, um and so that is is this particular change.

D

um I'll just go through all these changes happy to hear comments on them or as always, comments. If you want to just comment directly on the pull request, that's fine and I can do follow-up ones or start an issue either way.

D

um The second one was to create this key principles.

D

Doc, which is we need a better intro here, but the main thing of like Trust Systems, verify artifacts to lay down. You know we have no choice but to manually verify a system, but we can automatically verify all the artifacts created by that um that we trust anchor like anchoring code, not individuals, because one of the main kind of push backups also would be like well, I trust. All these people, like they're, doing the right thing, um which is fine if you like, have three.

D

If you know those three people, but when you're talking about large organizations either like third party or I, don't know those individuals or like in a large organization where you have like hundreds or thousands or tens of thousands or a hundred thousand people uh is no longer scalable to like trust individuals um and then prefer attestations over just inferences of like well. The thing was configured this way, so I assume nothing bad could have happened, but instead we want to explicit attestation of like this good thing did happen as opposed to I.

D

Don't think a Bad Thing could happen um so feel free to to read that, as always, feedback is welcome and then um I think we mentioned at a previous meeting, um I put out a draft uh to get feedback on a 1.0 for uh the provenance format.

D

um It's still like, there's a bunch of to-do's in here um and like I, didn't create a markdown I didn't like protobuf um uh and so like it doesn't look pretty, um but I'd be interested in getting uh people's thoughts. Originally I was going to push this off until after the spec 1.0 release, but I've had a bunch of conversations with folks where there's a lot of confusion around like what is a config Source. What is an entry point?

D

um You know what are the security boundaries, uh and hopefully this is maybe getting towards uh an improvement. uh The big thing again brought by Mike and by Sean um that's missing. Right now is like somehow defining like what these trust domains or security boundaries or I. Don't know what to call them. I don't even know how to picture it. Really um if.

B

You could, if you could do some sort of visualization.

D

I think that would that would help a lot, um but the notion is that we have the build, has some sort of top level inputs that are like the independent inputs to the build, and these are the things that the verifier has to like assume match what you expect.

D

uh There's a list of other optional things, I think I assume this would be optional level, three, maybe at level four. We would require this of like resolved dependencies and then some sort of per Run details of like who ran the build. What time stamps Etc um that hopefully have a better separation of concerns around uh everything, so yeah Mike.

F

Yeah, so one thing um after giving it a bunch of thought, I think one of the the key goals of this. That I think just needs to be made. Sure. That's really clear, but I think this this this.

F

This is getting us there is that idea of at uh and I don't know if we want to put it in as a requirement or whatever, but there should be enough information inside of a predicate that somebody could rebuild the thing if they had access to everything there right like the idea here is you should be describing enough information that if you could pull down the config again the code right, because in certain cases it's open source in certain cases it's gonna be closed.

F

Source in certain cases you know you don't have access to whatever they have access to, um but assuming you did, you should be able to rerun this build um I. Think that's kind of the the thing that's.

F

Oh uh Mark you're you're talking underneath there.

D

Yeah uh thanks yeah I think we have this piece here like it, should contain all the information, the sufficient necessary solution to run the build um uh yeah any again. Any feedback on this uh I marked the pull.

E

Request is draft.

D

Because it's not ready to submit um I, but by the way like I want. Ideally, we would have something like defining a schema in markdown sucks, um but I haven't found any good language to do. This Proto seems like a decent compromise, um because, like it's, nice syntax of like I could do message versus like was it called. Json scheme is horrible to write by hand.

B

D

We like about a bunch of markdown and like Json or animal, seems terrible too. So what I'm hoping is that we could just parse this file and generate just turn it into markdown like take all this. You know all this stuff have something like and there's the tools that do. This turn, that into a Json, which we can then render as a template or something like that.

D

um So if anyone's into that that'd be great um to because right now, it's not very readable. Seeing his comments.

D

But yeah to the actual content area, comment, uh yeah I think that's um and we should be clear of like whether that's Ace I guess at level. Is there a difference between the levels and is that necessary? Like does it have to describe all of the inputs, because that that's actually maybe a change from the 0.1 release, um which is that we said at level three? You just have to list the entry points and the the entry point um Without Really, defining exactly what that is and then level four.

D

You have to Define all the input parameters um and there's some comment on the thread of like well: entry, Point's, actually pretty confusing and I'm actually wondering. Should we just require level three? What Mike said? It's all of the inputs.

F

So um yeah I don't exactly know where we should have it, um because I think there's a lot of there's a lot of open questions about also trying to make it as like make that on-ramp onto the higher levels as easy, as is possible like at some point. We do need to absolutely require that um I also do think that like, if we let's say do require it um like there's, there's ways to trivially, implement it and I'm. Also thinking does any of that defeat.

F

The spirit of the requirement like if I just said, hey I, took a snapshot of the container right at the end of this I took a snapshot of the container that contained everything. I needed and I gave you that hash, but there's essentially no way to pull that down that information. You know there's no way for you to get access to that container. That contained those dependencies.

F

Is that like essentially defeating the spirit of of the the thing there, but also I could imagine right like taking a snapshot and let's say in the case of Open Source, taking a snapshot of that image of the build image that includes the dependencies and all you need to do is just run. You know GCC or or run, make or whatever, and it does everything else, and it does again that's kind of your you've enclosed, a hermetic kind of um environment.

F

Then you know that's also awesome right, because then, then folks can look at what's in there and be able to poke around with it as much as they they need to for audit or investigation purposes.

D

Yeah I think that then gets into the transitive thing of like I think that would be a perfectly fine thing to do, but it would kind of beg the question since you'd have to know: well, okay, what's the provenance of that container um and yeah, um it's kind of pushing it down the road.

D

Okay, um oh yeah and I'm working on like the split of like maintainer requirements versus like build requirements for the ecosystem requirements. That's what I'm working on next. uh Okay, we have 15 minutes, left uh I'm, happy here and more things, but I want to make sure it's time for Tracy uh Tracy.

G

Hi folks, yeah I, just just quick group, a cap on the salsa conformance programmer a while back long before kubecon and stuff. We had a call where Jason lives in uh Josh, from Red Hat presented on an overview of the conformance program, and one of the conclusions was that this was the the best meeting to help nurture that and drive that forward and yeah I think, based on the earlier conversation um that that definitely applies so yeah I just wanted to get it on the agenda today, I think today.

G

The main thing is just raising awareness and highlighting this GitHub issue. That's going to track things I think. um The main thing we'll want to work too is a concrete proposal that goes to the openssf governing board, um but I think this there's lots to be ironed out on the way there.

G

So um no no specifics but yeah I would like to make steady progress at this meeting and yeah I'm, helping just to bridge the gap on the documentation, side and um process side, but I'll, say Jason and Josh uh are doing the the heavy lifting and coordinating that so maybe over over to them for any additional comments.

C

Yeah this is Jason uh yeah we'd definitely like to re-engage on this and keep it on the radar. But again you mentioned a lot of the details are being uh hammered out. But, yes, uh the conformance ticket is five one five and it's tied to some of the other issues that are related to this, and so Josh and I probably should kind of probably do a presentation again or depending on how how this group wants to uh adjust that. But we can definitely present uh what we are proposing as a conformance program.

C

G

Joshua Jonah go.

E

Ahead, yeah I um I just wanted to remark on the conformance um proposal document I I read it earlier today: I missed the meeting where it was first presented and I really like the idea, but I'm kind of the third party uh assessment aspect I'm a little a little wary of at this stage. So I'm curious. What what sort of timeline you imagine working towards with with the kind of tier one tier two um establishing processes and things.

G

Yeah I don't think we have a timeline and I think it's safe to say we could also split it up and just do the proposal on a self audit, um so yeah totally open to feedback from folks and yeah I. Think the more we dig into it, the more it does seem to have um yeah. There's lots of specific things we'll need to address so yeah I'm, not sure. If that helps, but that's generally the thinking you can do it as two stages of just So.

G

The plan is we'd like to get to um third party, but I. Don't think we can get there until we're successfully seeing some self-audits and reviewing them in the community coming through.

E

Yeah I think the I think that makes sense, not least of all, because I think, if I, if I look at the few public instances of people claiming like conformance themselves, level, three and four today um I think it's going to be hard to define a good uh assessment um for the third party. Assessors, so I I think the the phased approach and, seeing um you know the shape of salsa one and how people are self-assessing cell for one will really inform how we uh Define the requirements for the third party assessment to.

G

Yeah, no, that sounds good and I'd be happy to. We can modify that now and just mention that the face approach um that makes a lot of sense to me Michael, do you want.

F

To do yeah, um oh yeah, so just a a quick uh comment. Yeah I think it makes sense to have this uh here um and then separately. I do think that maybe once in a while having some representative who's been working on the conformance work to also show up to the tooling meeting, because I know, one of the big things is as we're going through the tooling stuff.

F

We want to also make sure that, um especially in the open source, tooling, that, like you know because there's the two pieces, one is like conformance as a project and there's probably also conformance as a build system, um or you know, like different rules, might be conformant to different things. Like you know, hey this. This hits these requirements and I know we wanted to kind of like there's a lot of uncertainty in in the tooling meeting.

F

um A lot of folks are confused as they're like hey um and, if am I or re-certifying, for example like GitHub as a build. You know, GitHub actions is a build system and if that's the case, do you certify like tecton and tecton chains as a build system? And then do you certify or do you certify this installation of tecton and tecton chains, and there was I know, there's been some confusion around that as well? That we want to clear up.

F

G

Good take a note yeah. We should definitely do that. Tour.

D

Yeah I think um we should also figure out like what is a Blocker. We should decide in this group what is a blocker for 1.0 and what it um and what is not I suspect getting the whole thing set up is like going to take too long for a 1.0 like already everything everything is taking too long.

G

Is there a timeline for 1.0 I.

D

Mean we wanted to we wanted to release it months ago. Okay, so I guess.

G

um I know that feeling.

D

um The I would suspect that, like getting defining the idea having some survey in place and saying like what things are certified, what things are not like addressing Michael's question suggestion. We need to do um I.

D

Do wonder if we could continue to iterate on the survey over time that, like we, don't have I'm worried about having to get everything right perfectly the first time right, because it's it's impossible to ever get anything right the first time, um and so if we could have something where we could start with something, that's good enough and then evolve. It uh would be valuable and.

B

D

Don't know if we want to time those to the salsa releases of like we do a 1.1 a 1.2 or we do some sort of rolling thing. I, don't know what the best plan is, but trying to figure out like how we evolve it over time, because we're going to get better at it over time um and trying to figure out that I'm like.

B

G

I think that makes sense, and one of the things to decide in the certification is how we tie it to the releases. So if you certify against 1.0, does that apply? Does that not expire? But if the version changes you need to re-certify and things like that, so just I guess I guess articulating the relationship between them and then I think uh what you say makes a lot of sense. Just we can always fix things in future releases and tighten them up. So, let's yeah, let's not do the Perfection as the enemy of.

D

Yeah, we should also, as part of this, it's not let's say in the checklist in 515, but we need to like I, don't know whether it's here or in the higher level task, um but like we need to figure out like where in the requirements do we stick this right, like that? You have to do this and like how does that like just mechanically fit in um like do? How do you and what format do you publish the survey is, is anything okay?

D

How? How do we verify this exists like? What is the process for uh for verifying this of like it seems like? Probably in practice we have, we will have one certifying body which is the salsa framework, because we have to salsa verifier um tool, and so that comes with a default list of things that they can verify right. You can like verify, GitHub actions and I think people work on Google, Cloud, build and gitlab and Etc, um and so I think just de facto.

D

There is some list where some people have made a decision of like well. This thing, like the conversation we had for the first half hour, this thing is level three or this thing is level two, um and you know if we could work that in of like just explaining that that's the current state um I think that would be good and then also talk about well, you know that's where we are today where we want to be. Is this.

G

Yeah I agree, but nothing specific to it.

G

Okay, um yeah nothing else on that, but yeah thanks for that feedback and I say we'll try to just keep progressing it in this meeting and have some follow-ups next time.

D

Great, do you need anything from anyone.

G

No I think just take a look uh at the docs. If you haven't and ask all the questions, because they're super valuable.

D

um Are folks, starting because, like one of the things listed in 515, was the like create this survey? uh Has anyone started actually putting something like that together.

C

Not that I know of but uh Joshua Mulligan and I can take that as an action item to start uh putting that together- and perhaps we can present that to the group looks like Chris has got a draft.

D

But yeah maybe uh Chris and Jason you could reach out and yeah.

C

Absolutely sounds good questions.

D

D

um Any other topics for today last minute, things with.

D

Okay, um all right: well, it's good good, seeing everyone and uh see you in any other future meetings or uh talk to you uh online bye, everybody.