OpenSSF SLSA Biweekly, 17 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SLSA Specifications Meeting (April 17, 2023)

Description

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

A

Good morning,.

A

B

Hey everybody um I'm. Sorry too, man I'm eating my lunch. That's what I'm gonna keep turning up my camera periodically um welcome everyone. As a reminder, please uh register attendance in the meeting notes which you just sent in the chat.

B

um We would welcome newcomers, but there's no newcomers here.

B

um If you have any agenda items, please go ahead and add them. um I put one discussion topic is David here looks like David is not here um a topic that I David wheeler brought up in a pull request. That I think is worth briefly discussing um it's low priorities, if you have anything else, feel free to preempt that um the.

B

First, the only two topics I had were um one I I, think if you could um review The, Proposal 829 832 to Mark V1 as approved and as if you do.

C

B

That and then please mark your approval on GitHub um and then 832 makes V1 the default which we'll submit after the two um I separate them. Just because technically they're too distinct actions um we could have. They prove that.

B

Show up by default um and so sorry, uh yes, it's in the meeting notes, 8, 29 and 8 32.

C

um If you go to.

B

Just the GitHub uh open pool requests, you'll you'll.

C

B

um Mark, if you want to approve approved and make you won the default um and so I think we could use that as the means to register that it has General Community approval.

B

um So far, we haven't heard, to my knowledge, any significant um feedback that would present prevent us from considering it approved um and I think the according to our governance. The process is that the maintainers approve it assuming that, like with the intention that it represents a consensus of the community and so I, think I, don't think we need it like specifically formal approvals or every single.

C

Steering committee member to approve, although.

B

I think that would be helpful. That would be nice to just record um so that and then we'll merge it tomorrow afternoon and then the pr emails go out Wednesday morning, Wednesday I think 9 A.M Eastern um anything.

D

On that topic,.

D

No I think we should have a formal uh you know decision made on this meeting, but this is the plan. So we can, you know document it say: yeah, everybody agreed.

D

In addition to the GitHub process, sure uh what what.

B

D

Particular I think uh so we should acknowledge that there were no major issues raised in the last two weeks right, so we are good to go with the plan to move the specification from basically release candidate towards the candidate approved specification to approve specification under the uh committee license framework.

D

So I've seen several people nodding their head when I said they knew that, but I.

A

I, approve and I agree with what you just said.

D

D

So if anybody has any concerns, this is the time to raise it, it's clean. Otherwise we should you know very current that this was approved on this meeting at least.

B

Sounds good thanks.

C

Sorry does that sound sufficient.

B

Do you all right, thank you.

B

um Okay, so um that's great, thank you very much.

B

Anything more on the 1.0 or last minute topics. Okay, um the only thing I had currently is um that I thought was worth a brief discussion. Is um the terminology um I sent out a pull request to update the diagram? uh Let me present it here.

B

B

Try to zoom in uh sorry the GitHub doesn't make it easy to zoom.

E

B

Hopefully, you can see basically change developer to producer. That's the only change.

B

um We had an earlier pull request that went through and eliminated basically has a single term producer for everything like we have producer and consumer and and um whenever we need a word we default to producer and when we want to be more specific, we kind of spell that out in plain English, like there's cases where we say where we had maintainer, we were placed with Insider threat or individual.

B

If we're trying to emphasize that it's a person instead of an organization um and I, think we didn't really need the word developer or a maintainer, um because we only have the build track and it doesn't really come up um or where it does. We could just easily spell it out, uh but um I think David might he's, unfortunately not here, but he might have some larger concerns, which I asked him in the pull request.

B

um uh So I guess one question is I. Guess just to confirm. Like does that sound good.

A

C

B

Blocker for 1.0, by the way, it's just I, think it's. We could easily Swatch soft terms um uh and then also for this particular diagram.

B

I kind of feel like developer, looks better here because, like the developer is the one who goes into the source versus producers, kind of implies an organization and kind of implies, touching all the different parts, um but my weak feeling I I, like weekly lean toward just having a single consistent term instead of having the word developer only in this diagram, but nowhere else in the site. So.

C

B

Just wanted to open that up um because.

C

I thought David's.

B

Comments were worth.

C

B

Discussing yeah.

F

Yeah at first at first I wasn't crazy about producer. It seems a bit too abstract, but now in the age of llms and everything even depend about producer actually makes sense.

F

Just that's just my two cents here.

D

Yeah so I agree with that and and if you look at the terminology now we have defined different walls and we have producer, and it actually says that you know it can be a maintainer or safe a software vendor. So it's you know it's kind of like an organization possibly and goes you know, you know the same line of you know, maybe developers to reduce it, but.

C

D

So I think it's um you know I'm happy to go with producer. This would have been using in the spec for a while now and uh I think we should keep it that way. So I agree with the updates that are gone.

A

Yeah I also agree. um You.

C

A

If we don't really list a developer anywhere else in our terminology, not really I think it makes sense to kind of align this diagram, especially right because.

C

A

Is where people are looking at um something that makes total sense? The other quick question I didn't look at the other images. Are there other ones because isn't there another image where there's a bunch of listings of vulnerabilities along the supply chain as well or is that a different thing? Okay? Here we go good excellent.

B

Yeah, this updates all of the um an import request. Description, I, didn't update the ones that are only visible in V 0.1 and the release candidate, um and so there's a little bit of an inconsistency there but yeah. um If.

A

You just look at.

C

B

It is consistently now all this, assuming that we approve and merge this board request. I, like it Nicole.

E

I put the note in the PR, but I feel like I prefer the consistency, but it's not like a strong feeling, but I think we should link to the terminology page at the bottom of all the diagrams, where we use terminology, because it includes like examples and definitions, and so that could be helpful to people who are just coming into it and they're like what is this.

D

B

Good idea, um Okay, so um all right so I couldn't quite tell from it sounds like the weak preference is to switch to producer, not that people particularly like producer, but rather it's consistent with what we use elsewhere, and so the consistency is a clear gain um and maybe there's still a question of perhaps there's a better word that we could use other than producer. But that's a larger discussion does that capture.

D

Yeah, except that I, don't think switching to producer is the right. uh You know is the right thing to say here, because the switch has already been laid in the spec right. uh Aligning the diagram to the to the text. Part of the spec to me is not you know, it doesn't constitute switch, but yeah I think we should continue on switching to the producer. You know and alignment diagrams with the spec with the text yeah.

B

Yeah that yeah thanks thanks for saying that yeah, the um I, think David kind of questioned the choice of switching to producer.

D

um But I think his comment was broader than the diagram.

D

B

um I think like looking at like, for example, other um it for the bro okay. So it sounds like this one. Fine. If you have comments on the pull request, please, please do add them save my by end of day, um uh but it sounds um for the broader question of like is producer. The best word for that s-bomb calls it. What do they call it supplier, um which I think maps to what we call producer?

B

Although I don't know, if there's like some sort of subtle difference, um that might be one thing to consider um of like having a consistency across so people don't say you.

C

Know like if we really do mean.

B

The same thing: um yeah I I, don't like the word Supply here either for further for what it's worth, uh but it does kind of call into a question of like well. If salsa says producer and s-bomb says supplier, are they the same? Are they different? If we literally use the same word and say it's the same thing then.

B

C

B

Supplier is a very good name, foreign.

A

People listen to this recording.

B

I think that term is pretty entrenched in s-bomb um I, think it also um kind of comes in like if you think about a manufacturing pipeline.

B

You there's kind of like a supplier and a distributor I, don't think espan talks about distributor but, like um I, think the terms kind of come from the manufacturing world, where you know like there's a actually I'm, not sure someone could correct me if I'm wrong, but I feel like supplier is like the end entity of like who's, saying how to assemble all the things and the individual Parts can come from other suppliers and then there's um some manufacturer that converts all those parts into a a widget or something and then a distributor which I think we would call package ecosystem that, like then, sends it out um but yeah okay.

B

So it sounds like um there's not any particular Groundswell of support in terms of changing this term. Okay,.

B

All right sounds good.

B

um Uses supplier, but.

D

I feel good because.

G

Most common thing in the days manufacture which to me I mean I I'll, just try and to say that that from A supplier, where you might not be trying to differentiate as much between the different entities involved in the process of building artifacts it might, it might make more sense to use a supplier, but supplier and manufacturer that still seems to roughly correspond to producer and platform.

C

Yeah I was just clearly stating that that's what the s-bomb requires. That's all I wasn't advocating for using that.

B

It might be worth like briefly, especially if we in we have the other open, uh pull requests about the s-bomb frequenced question. We could mention that there of, like in case you're, wondering these two terms or somewhere, but I'm, not sure if any people really have that question I.

D

Guess we could wait.

B

Until someone actually has a question before heading into a frequently Asked question,.

E

D

We would have to be confident that what we say is correct, which I'm not sure we have the expertise to say that right. So.

E

I think that was one thing mentioned in actually a27 is like we don't want to be wrong and s-bomb is actively.

E

You know iterating as much as we are, so it's probably better to link to them than it is to restate or quote anything of theirs.

B

Okay, thanks for thanks for discussing.

D

B

Else on the the topic or any other.

C

B

E

I mean do we want to like briefly go over the s-bomb issue, so people can take a look at it.

B

E

Guess I'll attempt to give a tldr sure so in 827 um there's a proposal for how do we reference that s-bomb and salsa currently are different, even though, like in the future they're kind of potentially going to have a lot of overlap, and so there's a proposal in there for how we reference it. um I, like the revision on it I do think.

E

I might make a couple comments, though, about us not over defining things and kind of just pointing at them, but I guess if anybody else has any thoughts on that, it would probably be good to comment in there once you get to read it.

F

Yeah thanks thanks for raising this issue. um Now now on. The second at first I was I thought. Maybe we could say something slightly more prescriptive, but I think I. Think I like the the way it's worded now, because but part of what I'm worried about is um uh we there might be an accidental biofurrication. Dude do I make sense. Some people might put s-bombs in their salsa at a station.

F

Some people might use s-bombs um instead of salsa attestations, um I'm kind of worried about the Divergence there, but maybe it's too early- and we probably don't want to be prescriptive here either um any any thoughts on this.

D

So, first, a little bit as Nico was saying earlier: I mean I, think, there's a danger in trying to characterize what es bombs are when we are not the esbom, you know experts or owners, so to speak, because I think you know, with our view, is going to be slightly biased in some ways, and you know we have to be very careful.

D

That's why I was you know in one of my first comments was trying to be broad enough that people would not be offended that we seem to you know Corner them in this small Niche that they may not feel like. This is where they honestly, you know they want to be in and and especially given the amount of development there is that we already know about. So that's you know mostly.

D

What I I would like us to keep working on is trying to make sure that the way we frame things is Broad enough that nobody feels offended by the way we portray things and that we also make it. You know open enough in terms of how things can evolve, which I think you know, there's been some effort to try and do that for sure.

B

Yeah I I, don't think I fully captured anything else. um So if anyone could continue typing, that would be um yeah if you, if you know, if you look at the pull request. My comment on from four days ago on the 13th at 5 PM, starting with what do you think about the following um I one approach could be instead of talking about like the difference between.

B

Could be just be talking about like why doesn't salsa say anything about s-bomb, um which is a little bit like we could be more authoritarian, authoritative there, because we're just explaining the reasoning, as opposed to saying something is true um and so I yeah. If you could.

C

Look at that and.

B

See if you want to incorporate any of that Concepts into the pull request, that would be good too. Basically, I broke it down into.

B

Why don't we require s-bomb, um and the short answer is um like the we kind of say precisely what we tried to spell out the necessary things without using the term respawn, because s-bomb is kind of ambiguous at the moment um and saying s-bomb is not a good match for the things, the specific things that we're trying to do, and then why this also like invent a new formats of using existing s-bomb format, and that has more of a simple answer of like we can't with the formats that are available today.

B

None of them can express salsa prominence, there's ones coming down the road, but they.

C

Don't exist and.

B

So for now um so yeah anyway feedback and say Andrew yeah.

G

I haven't read the the pr, so I can't speak to the pr specifically, but based on the the conversation around it I feel like this actually or in in my head that this relates to the same confusion um around Providence versus attestation. So if you look at the attestation model that that is published, um the Providence in spdx and Etc are just some are different, predicates and and so um like to me, stating that you can have multiple predicates in one envelope.

G

You can have multiple predicates, being attested with a single signature, um and so it might be relevant to have multiple predicates there in in a single envelope. If you are concerned about the specific provenance, maybe what is defined in the the provenance V1 uh specification.

G

If you are concerned about specific um uh bombs, then that could be another predicate um and so I like I, don't know if if it would clarify the the situation at all, if, if we're trying to be more precise about what it means to have, an attestation is an attestation, because I we've kind of loosely said that that Providence is at a station. But it is an attestation, but it's not a sign attestation.

G

According to the attestation model, it is an in total attestation, but not the the entire um attestation envelope, um and so maybe, if we can hook at that a little bit or pull it apart a little bit, it might make more sense.

B

Yeah I um I I mean regarding esbom. It seems like I, don't know, but I get the impression that when people say like there's a lot of stuff that were rolled into s-bomb and it's kind of both is like simultaneously a particular format and people often has a notion of a minimum set of data. That should be in the thing um and also particularly use cases that will be solved by having that data.

B

um And so kind of in.

C

Any more specificity that.

B

We could have is probably helpful.

F

I might be missing something, but is there a way to include um s-bomb metadata right now in um in Providence, attestations.

B

Yes, there is um a you could either click create it as an output file put in the subject um or you could put in the byproducts um there's an open issue to document that it's probably like a the equivalent of like a one-line change um just having gotten around to it.

F

Oh I, like it I like it that I think that would go a long way to its uh clarifying this.

A

D

A

You say just put it as a subject right, so that's just another attestation of a artifact right and it's just the the shot of that or the file itself. That's bomb right.

B

Yeah, so if it's in the subject, it would effectively say well either way, it would effectively say that uh this build process resulted in this.

A

Bomb there's any arbitrary file, essentially.

C

B

um And that that should be I mean that's a pretty easy fix, like it is just putting somewhere in the prominent form and saying you know many users probably want to have this field, something like that.

B

Okay, um so review on those those were comments would be welcome um any more things to discuss, or should we break now.

A

I have a very small one right, so I threw this issue out. 8 21.! Don't intend to have a discussion on it today, but just want to bring awareness um if anyone is interested in Etiquette, uh merge, requests or pull requests uh and helping to document that that would be really nice. I know, Josh and Mark have already um and and uh I don't know. Also, um you guys already contributed to the issue. So thank you.

A

So just like kind of interesting right, because my experience I'm like all right I, got this one approval when do I merge into Maine right, because I could just press the button, but what's the etiquette to that so it'd be nice for us as a community to kind of high level document that in the contributing, probably so you guys already have done a lot of discussion, which is great and Josh talked about conventional commits, which seems kind of interesting I'll have to read up on that, so I'm just bringing awareness.

A

We don't have to talk about it in here, but.

B

Sounds good yeah I already put my comments on there. um I think I think it'd be great to have in document and start making progress towards and.

C

Feel free to also feel free, as always feel.

B

Free to disagree with anything I said: I won't take offense.

B

B

B

All right, uh good, seeing you everyone and um I'll talk to you on through other asynchronous mean bye. Everyone, foreign.