OpenSSF SLSA Biweekly, 5 Dec 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SLSA Specifications Meeting (December 5, 2022)

Description

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

A

Hey folks, sorry I'm late.

B

A

um Welcome everyone, uh as always, if you could uh record your attendance in the notes, dock, which I just pasted in the notes meeting uh and a reminder that uh we'll abide by the lynx Foundation code of conduct for this meeting.

A

If you have any agenda items, please please add them. um Nothing was added so far, so it might just be a short meeting.

A

A

A

So I could uh briefly give an update um the for the with the spec 1.0 change to 530 pull request 536, which um split requirements by party uh several of you viewed that so thank you very much and that was submitted, um as we mentioned before it's full of to-do's, but now we have that and we can make kind of like incremental progress on tracking them down um here. I could present just so you see you can see what I'm talking about.

A

um That's this one where it looks like that's where we have this table so that was submitted again, we could um do pull requests to to fix individual things on there.

A

um The Providence 1.0 spec I submitted a small change, because there was a question about exactly how to um this is maybe bike shedding here uh exactly how to format parameters of like? Is it an array of objects or an object of arrays, and we kind of have where's that comment.

C

A

Three different um kind of attributes that we want to slice by or for there's called disposition for lack of a better word of like. Is it coming from outside? Or is it uh something set by the build system internally and the reason why we care about this is because um the external ones we have to in in the salsa um we have to check because they're set by users, and we want to verify that they're safe within the system. We're generally trusting those, and so it's useful, probably to split it at a high level.

A

Because then there's like one thing of things that you have to set at a certain build level, and one thing that you don't um then by type, is it a reference to an artifact or is it just a raw string value uh and then some sort of name just a unique identifier just to differentiate between them and then the actual value?

A

um So I? Don't think it's probably worthwhile to spend the time here, but I just want to mention that this is the only real update since last time. um If you have any thoughts on it, I think opinions would be welcome to try to get past. We have I think there's like three different options that I have different commits um and if it's unclear like where, in the pull request to find the thing, just let me know and I'll do it.

A

But here's here's like the examples that I happened in this last um comment, um otherwise I think other than that. There's most of the comments I think have been mostly resolved or just have like little to Do's um and so I think that the the biggest part is cleaning up. The pull request to like make the documentation more clear, not have documentation, spread across multiple files, but make sure it's like actually uh in markdown. uh Things like that.

A

um So I hope to do that over the next um a couple weeks, but it's been um I've been a little bit busy with uh with other things for my job, so I haven't been able to spend a lot of time on that.

A

um If there's anything, anyone want to discuss now, I'm happy to do it, but I'm not sure. There's.

C

A

Since last time,.

A

um With that I'll hand it off to Chris.

D

uh Yeah so I've been drafting the spec for how to verify uh build level three systems, um it's almost done, I'm putting the final touches on and it's it's in Google DOC format, I'll be posting it to issue 508 this afternoon. So please read give feedback. um This is my first foray into spec. Writing so I I need input.

D

B

If it would be more useful to get feedback on the Google Doc before you do the markdown translation, then that's I think most people will be open to doing that. If you wanted to share a link to your to your doc in the issue, we've done that a few times before with different things.

D

I'll put the doc there with uh comment permissions to the internet, cool.

A

Yeah and as I mentioned to Chris um before in case, anyone else is in the same boat. um There are tools to automatically convert from Google docs to markdown, so like don't do it by hand uh and if you can't find a tool, just contact me and I'm happy to to get give it.

E

A

Know either do it myself or give a link uh we have one within Google, but I think it might just be Google internal I, don't know if it's publicly available but either way it's um it saves all all that pain and and generally receiving comments on Google Docs is way better than receiving comments on markdown on GitHub code reviews way better meaning easier for both the author and the reviewer.

A

Oh I see someone added something for specification changes. Maybe that was R now I.

F

Don't know if you see it's me, I mean if we have time. I wouldn't bother the whole group with this, but I I thought there was an interesting uh question that came up from our interaction, which is what I was trying to link to specifically uh it's there at the bottom. Actually so, for those who haven't seen this I kind of took a step at putting together a page that defines different stages for the development of specification, so that we can communicate clearly um what stage the spec is, whether it's in basically being worked on.

F

It's uh we are asking people to review it or it's stable, that's the main the stages, and then there is the last one is kind of meant to be okay, end of life kind of thing. And what came out of this is you know in my proposal? I had thought we just retired them and there may be different cases uh which lead to retiring aspect and the main two are. We have updated the spec with a new version altogether or we we abandon it.

F

We can imagine at some point we're working on some document and then we say you know what let's forget that one, let's start over or something like this, and so it doesn't have to happen. But and and so what Mark you said is wait. I, don't know that, just because we're releasing a new version, we would want to retire the uh the previous ones and I thought. That was an interesting question. Do we really want to entertain the idea that we are maintaining several versions and then people?

F

You know we are letting people I, don't CBD, but you know we are actually saying it's okay to stick with an older version. That's basically what I'm trying to say and and so just to give you the context- and you know I apologize, but to bring that up. Like you know, my my background is in wtvc mostly and uh where, of course, the specifications are called recommendations.

F

So you know it quickly became obvious that there were things we didn't want to recommend anymore because they were old things. And so, if there's a HTML5 spec, you don't want to recommend people to do html4 anymore, and so we said, okay, we're going to retire html4 uh once HTML5 is out, and this is what we want people to use. So my expectation was here. We would have something similar.

F

Let's say you had salsa one, you don't want people or, if you say, let's say, there's a salsa too and there was in salsa one before two. We really want people to still use one or do we want to say no one is retired. People should really move. Of course it doesn't mean everybody needs to move over at night and they keep. Maybe people might stick with the old one, but it's a matter of how we want to communicate this. So Mark go ahead.

A

F

You actually Josh, if you.

A

Want to go first.

B

I yeah I was just going to say that I've been uh thinking about this a bit today and I'm kind of torn, like I, can I, don't think we want to recommend people like continue to use older versions of the spec, but neither do we want to make people feel like they have to move quickly, especially thinking about um like a lot of the changes. We're making are more about clarification than about change of uh recommendations and especially for the provenance format. I.

B

Think this, this notion of, um like outdated but still functional, is, is appropriate.

B

um So we've seen a few folks adopt um social provenance and and Implement social requirements and I, don't think there's uh it's strictly necessary that they should update to a newer Providence version. For example, when uh it's also wonder comes out.

F

All right thanks, I I, just I'm, going to object. Mark! Just uh excuse me it's just because I realize one thing just because we only have one stage called retired for both Obsolete and um abundant doesn't actually mean. We cannot have two versions in stable stage right. We could have two different versions that we keep in stable status, which means that you can actually maintain two different versions. At the same time, when we retire, one is completely up to us. We don't have to retire someone.

C

F

We publish salsa too, so in fact, we have more freedom than what I was thinking so go ahead. Black I know. If that changes your mind too, but.

A

Yeah I um I guess my my main comment on this was because it said, like should no longer be used, which I thought was perhaps an overly strong statement.

A

um It's a little bit nuanced, like you said, uh there's also I actually forgot. I was actually thinking that we have two types of specifications. One is like a literal format right uh and then like the provenance format, um and there I think we actually might want to recommend people upgrade I.

C

A

Have Tech saying that of like don't bother upgrading between zero point x versions, but you probably want to upgrade to 1.x 1.0 whenever that is stable, um so there we might want to have some wording of like new implementations shouldn't use that for the other, for the other, spec I, don't know if it's the same or if it should be softer.

A

um Maybe if we have some sort of language I think what we want to get at is that, like it's still a valid specification, but new implementations shouldn't use it and old ones, or people who are using it currently using it, should consider upgrading I, guess right, something like that anyway. I think Sean was next.

E

Yeah was just thinking about that in in terms of what Joshua was saying about. You know, making people who have already implemented the 0 0.2 version of the provenance spec um I think it would be useful to at least call out that this, the provenance spec, is something that we are working on. Rather than have that become a shock win.

E

um 1.0 comes out, so maybe on the existing Pages being able to call out, you know just give people a heads up who aren't kind of part of this group and aren't kind of actively watching um the changes in the repo that it might be worth. You know a heads up.

E

This is going to change and I think there's some significant changes in the provenance format I mean, especially in terms of the layout that we're proposing uh so I think it might be good for people who are kind of watching this more at the surface level, to call out the fact that we are actively working on the provenance format.

E

I know that there's documentation in there that says um stuff about you know you expect things to change, you know and once we commit to 1.0 we will not be making so many Breaking changes, but it's yeah there's a kind of Fairly rapid iteration happening on the on the provenance format. So it might be worth trying to just call that out on the page that we've got.

F

Yeah- and it's like just to add to this uh to respond to this- is the you know the proposal I put together. There's this notion. There are some stages that are well defined, but you know the spec itself. The documents will have a status section at the beginning and the proposal is to actually have it on every page that not only links to the definition, but also that allows us to communicate any additional information we want to.

F

So if, at some point we're working on another spec that we are getting too close to, you know uh being published where we want people to eventually move. We can always update that section and say: hey watch out be aware. There's this in the works, so I don't know who's next Joshua O'brien.

B

I'm going to blow my hand, because I was basically going to make the point that Mark just written about whether it's even because it's old and valid, doesn't mean we maintain it and there being a distinction between those.

F

Yeah, that's a good point.

C

I was just going to comment that perhaps maybe, instead of like version one and version two there's some notion of connecting these version releases with a date I mean compliant with you know, salsa level, three version. One sounds pretty great. Unless you know that version five is out right, um so I don't know, maybe there's a way that we can express that the um at the version that someone is claiming is three years old.

F

Yeah, that's a different uh indeed, that's another question: that's kind of orthogonal to this that is but yeah I'm afraid on that front, you're going to find people with opinions on either side I mean good luck.

A

Yeah on the date, one I have kind of gone back and forth, um especially because, if we're not doing like regular releases of like every year, then it might just be the three years actually is the most recent one uh or it could be three versions back, I, I, I, don't know, I, don't have an opinion on that. um The um one suggestion actually is that right now that the spec, the um the pull request, defines abandoned of like a spec that we started and then dropped I, maybe I'm not.

C

A

It we could leave it off for now of like I, don't anticipate that happening um and then when it does happen we could Define it. Then um that's fine, uh but either I feel like that I would either I would split that out either not Define it or not. Make it part of the outdated.

C

A

A

Yeah also in terms of like saying that there is a new one coming, should we use this the status field for that or just communicate it in some other way. I, don't know.

F

Where we have a website, we can use different ways for sure, but.

F

And maybe not just one wave.

C

F

Important enough, we want people to be aware and not miss it. Yeah.

A

Yeah because I've already had people I think that's a really good point. um I think uh I guess um because yeah I've already had several people like be unaware that that the new ones are coming I.

B

Think I can imagine that being really useful. When we open for comments as well and change it to, then we can actually actively proactively link to the newer version and say like take a look and leave some comments.

A

Yeah for the purpose of resolving this, um does it sound like so far we have just to summarize it because you haven't had this book, I mean I, think working draft, where it's like rough in review, where it's like, basically ready for review stable, where it's like the latest version in stable, and it sounds like we'll want one more. That's like outdated or something like that. That says it is, uh you know, still valid, but no longer maintained and it's recommended to upgrade to the new one. You know something like that.

A

Does that sound like what the consensus is.

F

So I still like the term retired moral because and we can I'd rather you know refine the definition of it, because this is something that's. You know controlled that at some point we make a decision. We retire in this spec. Why outdated this kind of happens? It feels like you, you're, not really, you know making that decision. It just happens over time.

A

Because does something become retired immediately upon the next version existing.

F

Or they're too stable. Well, that's that's exactly what I was trying to say earlier is that we don't have to do that at all. We are in control of that status field on the spec, so we could have two different versions or end versions that are stable and would they stay there and it's entirely up to us to go and say: okay, now we're going to retire that one we really feel like people should no longer use this.

F

A

About it, what about superseded with uh which um do people just suggested yeah.

F

Well, you can do that. I mean I. Yes, that I think that would work too I I, you know again, it depends.

F

The idea of the retired was because it was encompassing different possible scenarios when you see superseded. It means you can't use this for anything else, other than the case where it is superseded by another spec. So especially, if we were to abandon it and I know it's, you know it may never happen, but it happens more often than you know you think so you never know, but you know, because you could you know you have to think this is not like. You know like the whole salsa spec.

F

Maybe we would never abandon it, but you could have you know smaller specification at some point we say: oh, let's have a spec that you start publishing.

F

This people see it, and then you say: oh no, you know what or we should reformat this and merge it with another one or whatever, and then what happens to that spec, it's like well, people may have linked to it and whatnot, and you want to say you know what this is a dead end don't go there anymore, and so that's why the retired, with the you know, this notion that you could abandon the spec was kind of what I was thinking, but we could have different status if you prefer and call them out is explicitly that story reasonable.

F

A

Any opinions, uh I'm I, think that that argument makes sense to me or no I'm, I'm, okay, with retired.

F

Anybody feels strongly about this. That is, we are doing something wrong here.

B

I, don't have very strong opinions. I just have the kind of the Python pep and the kubernetes kept terms more familiar to me. So they used to use superseded in place and peps they've switched to replaced uh to indicate that there's like a more up-to-date thing. You should use instead, um but I'm yeah, I I, don't have a strong, strong feeling.

F

No, but so that's a good point in terms, but you know I mean again, we have this section, you put, you know you can say retired, and then you explain why right- and this is where you can say it has been retired, because there's this newer version, which you should be using it's been superseded. You could use that in the section below or you can say, no, it's been abandoned because being merged with another spec. You know anything like this could be in the section that goes with the status but uh-huh.

F

A

I think the ietf call things historic is that the term.

F

I don't know actually.

F

You will find you know this is the problem. Is everybody reinvents those things so then we're doing the same here.

A

Okay, so in terms of next steps, I suggest that um we add, if anyone has any opinion one way or the other, even if it's mild say so on the dock um and I think uh you know, as one of the improvers I'm fine deferring to Arno to make the decision at all all of them sound okay to me.

A

um So why don't we let you record opinions in the in the pull request.

F

F

Yep and the other opinion is welcome, suggestions. Rest, is you know you see exactly what text you would like.

A

Yeah yeah, my my suggestion just to clean up the paragraph. Instead of should no longer be used, but a little bit more nuanced of like it'll, be it's still valid, but won't be maintained and Etc and recommending using the newer yeah.

F

Yeah that part I can do the change, which is wet bread that was search listing to change no longer be used to no longer maintain that's an easy one.

F

I, don't think anybody is going to get uh upset with that change, and you know like everything else, those things are not cast in stone right. We can always improve on it. So let's not get too worked up about it. It's just didn't get great. It's like Weekend Update sounds.

A

Good any other topics.

F

That's it for me.

A

Hook it up all right, well, uh good, seeing everyone and I'll talk to you online or next week. Bye thanks.