OpenSSF SLSA Biweekly, 5 Jun 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SLSA Specifications Meeting (June 5, 2023)

Description

https://docs.google.com/document/d/1JbJZxeZOWE7rxT24iEozX35LIUl_Yoqd-DeSm6309GA/

A

And uh anyone know if Mark is around.

B

He's headed he's added a gentile item, so I would have.

A

Oh okay, there he is.

C

Looks like you just summoned him.

D

D

Hey everyone um welcome uh if you could as a reminder, if you could register attendance in.

E

The meeting notes as usual.

D

Just paste the link in the chat um and if you have any agenda items, uh please just add it to the notes um we just we have a couple right now. What's on the agenda is a couple discussion topics from uh issues that came up this past week or the past two weeks, I guess, since we didn't meet last week um uh first, we could welcome any new members. If there's anyone new here, if you want to say hi.

D

And it doesn't look like it: okay, um uh quick note on scheduling um next week, I'm out, so if someone could run run, the meeting that would be great. uh The following week is a U.S another U.S holiday. It's Juneteenth, um I, don't know if we need to decide now whether to go but like um uh like I I'm off, for example, and a lot of us companies are off um so I guess. You could decide next week uh um whether to cancel the following week or not yeah, it's yeah.

D

We it's a it's a new U.S holiday, but.

E

Last year,.

D

Was that the first year that we had became a public health, U.S holiday, yeah.

A

D

uh So that's always nice getting an extra holiday.

D

um Okay. uh The first topic I wanted to discuss um is the is issue 870.

D

um So it ends up that the spec, the provenance spec is ambiguous.

D

um There's a discrepancy in the type of a field, um the app there's, an annotations field, unlike resolved dependencies. um Briefly. The reason why it came up is that we, um the text, says one thing it links to the in total specification, which defines the type as being a Json object uh in. We have a queue and protophile that also describes it.

D

But that says it could be any Json type, not just object, um and because it's defined effectively defined in two places and we don't say which one has priority: it's ambiguous what's allowed um and so like the technically correct thing to do is to resolve.

F

D

Issue and bump the dependency resolving.

F

D

um I, don't know if we necessarily need to discuss it here like specifically how to resolve it. I think we could just say one any event of a discrepancy. One can have priority um and we can choose whether it's object or any type.

D

um But the thing I wanted to specifically bring up at this meeting is an issue that Arno raised I see what he just joined, welcome Marna, um which is that we had decided and V1 to version the two together. I'm sorry version the spec like the levels and the provenance format together, because most people just call it the same anyway.

D

But already we immediately have the need to do a version bump of the provenance, and it's not super desirable to do a version pump of the spec, because nothing else has changed in the spec. um So I wanted to just bring up that topic to see if people have thoughts, one way or the other.

G

Did we specifically decide against patch versioning major minor patch, no.

E

G

E

G

Was a problem that we're fixing it wasn't an intentional.

F

Yeah, but so we say we state that we use them there and according to Sam there, this is a breaking change, so it requires a major version number bump which, as Mark said I, don't think anybody will say. Okay, here's all set here is salsa to zero and people are going to be like what and we say, oh yeah we're just changing a type of an attribute in the format and everybody's going to be like. What are you kidding me so.

F

It's a very unfortunate situation.

D

Yeah um yeah I agree like I. Think technically the proper thing to do for following strictly is the semantic version bump or is the major version bump? um The question is: will that cause more confused.

F

Because, ultimately, the.

D

Purpose of all of this is to reduce confusion. Right, like the reason of sember is that we have a major minor and Patch to indicate breaking changes and like what people set expectations, but at the same time you know will it cause any confusion by having an immediately new version of salsa, yeah Mike.

A

Yeah um yeah uh I'm not going to talk about Solutions, but but I will want to talk about just uh from practical. You know like one of the things I think from a practicality standpoint, um whether it's here or there is, is as far as I'm aware nobody's actually using salsa people and yet uh the the uh the actual um the I mean they might be implementing it internally, but I have not seen anyone other than um myself actually like develop.

A

I mean I, know that, like there's a couple of libraries that have done it, but most of the tools still haven't used, the new version um everything's using the 0.2 of the Providence. Still um so in the very least, whatever direction we end up going I think it's going to be a relatively minor uh uh hiccup like I, don't think, there's gonna, be anybody who's like! Oh, no, now I, gotta, re-implement everything um but yeah I just want to throw that out. There.

F

So I I, you know I, think you're, probably right there, but uh I mean it's it's worth pointing out that so the spec as it stands is broken. It's not just that. Oh, it's not saying the right thing. It's saying two different things right, because if you follow the link to the definition that you know that points to the Intel to attestations back, then you get a different definition than the one that's embedded in the spec, so in effect or spec embeds two different definitions that are contradictory.

F

The question is, you know: I I, fear that you know the right. One is the linked one and this you know, as some of us have commented, they would have been better if we had stuck to just one and and not try to embed it, because this is why we have a problem. But you know the question is which one do people actually use?

F

You might think. Well, people are just going to go through the in total, attestations back and then Implement that format, and then everything is good and because that's the one we want, but I fear that in reality, people just see the one that's embedded and they use that.

F

But I don't know it would be worth doing a bit of a survey on that to see. If we can, you know.

E

F

People are doing.

G

I mean I've had problems finding anyone using 1.0 yet because we've been trying to implement it and get our customers to switch over from point two to one and everybody's still on point two.

B

Yeah I I think I would agree with well I'm, not saying with the additional uh kind of coloring that I I think people are trying not even to read our spec and really just want to get a library that implements the format and so um the users of V1. That I'm, aware of are all using the same like go, implementation and so uh I think. That's a factor like how. What does that Implement, um but.

E

Yeah, ultimately, I.

B

Think the what I noticed is right. People are going to do the thing which requires least effort and that's either taking a library that claims to implement it and using that or reading exactly what's written on our website, because an extra click is too much effort.

B

I, don't know how this helps decide what the right outcome is, but I think it's just um context on on how we anticipate people are understanding this. The spec right.

A

I also do think, based on um a couple of things.

A

One is um and I don't know if uh for for future sort of reference, I think it might also make sense for us to sort of talk to, because I know we were talking about precedence but like, for example, here I think it is worthwhile to kind of um like if in Toto is the one that defined the original thing, and it was just a typo on our end that we should have never done it in the first place, um like I I, do think that, like we, we should have um some guidance around like something like that in the future.

A

Around you know like I I would prefer something like hey if we Define something in two places: yeah, that's definitely a huge mess up on our standpoint, but if one of our dependencies in this case in Toto has to find it differently than maybe how we stated it, I would say we you know our dependency takes precedence, and then we should also make sure that whatever we link to is a static link, so that we also don't end up inadvertently pulling in like a new version of that thing. If it if it does get updated.

C

Yes, I have a naive question here, which is I'm guessing. It might be possible in one but not the other. But is there a way in protoba, for example, to link to a particular.

C

Protobuf Define elsewhere, specifically at a certain URL I, don't think so, but I'm curious.

D

I mean this isn't really specific. A protobuf thing. I think we happen to be using protobuf as a schema definition language, um but the spec is also written in English and it says type object, so I think they disagree.

D

You know and we're using Json as the format I think it just is kind of an implementation detail. That is that's pronoun. True.

C

That's a good point yeah, even if we had linked it to the other thing, we could have still messed up in the English right good point.

A

C

Same thing goes.

A

With a Json schema or anything else,.

F

Yeah and to follow up on you know what I was saying: it's like when we have multiple definitions, I mean it. We might want to still do that in the future, because it's convenient, but then we have to I think you know I've seen studying links that points to something that's not going to move. Is it wise thing to do, but we also should have some wording about you know if there's a discrepancy.

F

This is the governing version, because this is how you avoid this kind of situations, and you know it's it's just lessons learned that we have to remember moving forward. Unfortunately it doesn't, you know, help addressing this. The issue at hand.

A

Yeah and then to take that I I, don't wanna I, feel I, don't wanna uh beat a dead horse or anything here um and uh because yeah I I definitely agree with with that um I think I know it's one of the things.

A

Also that if you look at how spdx is trying to develop their um version, three they're trying to pick um a format that is completely as unambiguous as possible, so that they can Define it literally in one place they can import definitions from other places, as opposed to ever stated, restating the definition, and the idea would be that that sort of I think they're using rdf or whatever, um but using that is like that is the one 100.

A

uh This is the canonical definition, and you know if it would not in any way uh be different like if it uses a dependency on a particular other object or other type. It would refer to that other type as opposed to re-implementing. It um yeah once again, I'm not saying use rdf I'm, just saying that that that's kind of what they're doing.

D

Yeah I um yeah I'm not again I'm, not too worried about like how we can actually fix the problem. I think we could do one of these things um for to resolve this particular thing. Oh first of all, I guess it's worth spelling out like what is the problem. What is the breaking change? um The.

G

D

Is right now, if you have a parser that accepts that follows the in total spec and only accepts types object and something then generates of a different type like a string or an array, um then it'll choke and it won't accept it like it literally won't won't parse the file.

D

um That's that's! Basically the issue yeah.

F

So you know I like to I like to know the rules, but I always say it's good to know when to break the rules, because that's what make life diviable and so I would I would like to propose that we then break one rule which is same there.

F

I think you know in the grand scheme of things this is probably the success. You know the Lesser offense kind of things we can do given that salsa10 has now been out for very long that we don't know of any kind of major adoption. Yet you know we probably are better off fixing it.

F

Now we go it's salsa one one and call it done and we can put a footnote even if we want to in the changes- and you know saying yeah technically, this should have been a major bomb, but it was really uh just trying to fix a mistake, and so we just called it the minor version, even though it should be more so that people are, you know aware, and that's it.

C

Joshua, the URI okay, anyway, um what do you call um yeah I, agree: I agree. We have to be practical here. We can't go to 2.0 just to just to fix this um I will repeat what I've said in the GitHub issue. We want to be careful about doing this also, because what do we find, hopefully not Dutch wood, but what? If we find yet another, you know backward and compatible fix. We want to be careful not to accidentally um yeah yeah use this escape hatch too often, but I think everyone understands this.

C

The the other one is um I wonder if pointing to a reference implementation of the spec might help. But again we have to be careful a bit of the language there, because it's possible that the spec Stills, the specs is one thing and the implementation does another and you still need to specify which one takes precedence up. Joshua.

B

Oh really didn't have anything else about it. I I think we should just fix this I'll, ultimately like the strict interpretation of what we have declared I think is that.

B

Yeah we I I can't articulate any better than anyone else. That's already done so I'll just say: I agree. It's just to fix this without major patients.

D

um That also sounds good to me uh and I'm. Fine I'm, fine, just one quick question just to play: Devil's Advocate. One thing that Arnold mentioned in the thread is, um you know, saying like about like we're tying the versions of this like this little levels in the Providence together, um just to think about it for one minute before we decide to do the other which again. Finally, um if we.

E

Did this now effectively.

D

Would be ripping the Band-Aid and we'd say you know, the spec has just a different version number than the provenance and we just live with that and there's we and when it comes up in the future. Well.

F

Then it's just clear: we.

D

Just bump the versions and the two are independent and it kind of avoids that issue.

D

um What we found with 0.2 is that I think a lot of people were confused, that the two had different version numbers, um which is again why we tie them together, um but just just to say that this is an option. uh Is anyone yeah? Is anyone in favor of that.

A

Yeah I mean I, think so so I think the problem that you know uh the the the issues that we always want to kind of avoid is like too much of the difference. Differences like I I, you know I, don't want to throw out. You know uh too many solutions, whether or not it should be. Something like minor revisions can be an update to one or the other, without them being necessarily in sync or whatever.

A

um I do think that there's, like you know, gonna, be some confusion either way um because, like also at the same time as we begin to pull in the other build track, you know the other tracks right uh are the other tracks going to also be you know if we have the source track, um is that going to immediately be prepping for salsa V2 like do we automatically just have salsa V2 of the source track, and is somebody going to be confused by there's no salsa V1 source track?

A

You know, I, think it's gonna, um I, don't have an answer. I just think that it's it's gonna cause some confusion either way. I just think. Whatever is the the solution. That is both is that right balance between allowing us to update without jumping through a million hoops and eliminating the majority of confusion, I think that's kind of the option. I think.

B

I think another option we should consider is just moving the problems at a station or the the two access stations out of the space out of the cell. To repository uh like there's already there's the intercoator stations uh repo, where there's a growing number of um attestations, so it would fit nicely there or it could be its own separate repository to make the separate versioning less confusing.

B

um I I can see pros and cons to each but I think it's worth considering at least.

F

But so let me ask you a clarification, because that seems like an implementation, an implementation detail in a way of like it's still saying, let's re-separate provenance, the format from the spec salsa, spec and.

E

Yeah they can live in.

F

Yeah, indeed, when you do that, you can just even move it to a different repo. If you want.

B

Exactly and I just think it it has the potential to reduce the confusion in like. Why is this version separately, uh but it also um may make things more difficult in the having the two live side by side can make like editing, uh thermostat right. So it's like which do you prioritize, and so far we've argued that it makes more sense to have it live alongside the spec, because then we can edit the two and tandem.

B

uh They are effectively one part of the same project and that's how we think about them and and operate on them, but um yeah I'm not advocating for my other I just wanted to race.

F

So I the reason I raised my hand, was a bit different, but it's somewhat related in a way. It's like you know. If we, if we separate them again, you know.

F

I mean doesn't don't we have to update South the cell suspect anyway to point to the new version. I mean: what's the tie there and- and you know, because in a way, if one zero says well, that's the format we were using you're supposed to use for provenance, and now we publish a different provenance version. The South suspect still says it's the other one. We haven't solved the problem. We still have to modify the cell suspect and that's why I'm hesitant to you know I I kind of like the idea.

F

That's why I brought it up in the in the GitHub thread, but in the end I was like. Well, maybe this isn't really solving the problem. Maybe you could solve it once for ever in separating that, but at least once we still have a problem, I think but Mark. Maybe you have a better sense of what the tie-in is. There.

D

Yeah I, don't think um yeah, that's a good point too I I mean we would need to fix the we need to point, but I, don't think it would require a version bump of the spec to just say, like nothing in the provenance format like semantically is changing and so I don't think the spec relies on on a good difference. It's not like the build model is different or like there's like a different concept of external parameters, Etc so, um but it is a point that, like right now, they're tied together in some.

D

I don't know, maybe Chris is at the top of my list. I, don't know if that's means first or not, but let's go with Chris all.

H

Right, um let's see I've got a few thoughts. The first is that I don't think we need to bump the spec version to change the version number, because the versioning page is not part of the part of the versions uh directory of the site. I I, don't know how, if that's an implementation detail or if it matters I'm, throwing it out there I'm, not a big fan of separating the two versions. Again, though, because we just reunified the versioning, because it was confusing to implementers and I'm worried that we will relitigate this every two months.

H

If we keep going back and forth.

H

um That being said, I think um I think that we could make this correction as V 1.1 uh just take our licks for there being a mistake in the spec and maybe get a little bit less precious about bumping the version number we can adopt patch versions if we're going, because we can expect kind of a lot of changes with the with an attestation format, um but I I. Think. The biggest concern for me is that we not relitigate versioning every couple of months.

D

I

Okay, um so I posted a link, there's a question around who should implement the provenance spec like actually for in go that came up on the internal side um a month or two ago, and there was actually an expectation that in Toto would be the implementer. Even though there is a proto-spec. Also on the salsa side, because we've been moving towards using protobufts to implement the attestation layer and predicates, we ended up with a separate Proto definition that actually already Imports the intoda specified resource descriptor right, which is the problematic uh type.

I

So we have on the internal side, actually um merged a V1 provenance predicate uh again I, don't think it's really being used anywhere. So if we wanted to remove it, I think it would be a pretty easy fix if we wanted to remove it from the in Toto side, but I'm still sensing a little bit of sort of back and forth between who should own the implementation versus who should own the dot.

I

Proto um um spec, because I think there's potentially an expectation that those will be the same or will sort of be the the dot. Proto definition will be the source of of Truth, um and so there being at least two around now those yeah also I miss you.

C

Yeah, if I could um I think I think there's a way to fix this, where we don't have to answer this question right now, whether we're moving the um Providence attestation, backup stream so to speak, but I think it's definitely worth resolving one way or another. We should document this officially in the site, so.

D

Okay, so it um if any other thoughts, uh certainly I I, would be great to hear if, uh if you haven't spoken up yet um I think it sounds like the consensus seems to be on doing a minor version bump like not splitting that.

E

D

Technically, it's a breaking change, but we kind of argue it's it's worth it in this one case, um but we do minor version bump to indicate it. It's kind of like a compromise solution, um yeah I'm any!

D

How about this I'll propose that that's the solution, uh any arguments against.

B

I think we should add, as a chaser, that we should um like clarify what the status of the Proto versus the Q File versus the written text versus in total spec is as part of that change.

D

Yeah, that sounds great.

A

I I do think um not for this conversation, maybe for something like next week or in the coming weeks. I I would also be interested in understanding a little bit more. What that canonical representation actually is because I I know that we're using produce, but without sort of um some of the plugins you could use with protos. You lose a lot of the semantic meaning in in their um you know, so it could lead to different implementations, still breaking uh some of that.

A

So just as an example like right, you know the protobuf just sort of says, uh digest our string, um and so uh you know one of the things I've been working on that that open source project Specter does try to do as much as it can to try and actually pull in as much of the semantic meaning as we can and then allows it to then generate photos, and some of the other things from there um I know once again, like the the folks from the spdx side are looking at rdf and some of these other tools.

A

um But I do think that uh uh it's worthwhile at some point to just sort of talk that over just to make sure that you know we're not inadvertently pausing folks who are implementing it like they can serialize it correctly, but they're still missing uh the ability to actually validate it because it turns out they're, they're thinking, they're, generating a shot 256 when they're, not that kind of thing.

B

Yeah I, don't think it was ever uh articulated explicitly. A new web I think it was discussed in a pull request that we didn't want the Proto buff NQ file to be like necessary things that people use for their implementation. We wanted them to be uh like supplementary to the spectex, to help people reason about what the spec is saying. uh That's my recollection at least, and so as a consequence of that we did like avoid complicated protocol features that we didn't think were easy to read uh without being approach. Perfect expert, for example,.

D

Yeah I think, regardless we should have some sort of thing that says in.

F

The event of a discrepancy.

D

X has precedent, precedence, um I'm, less concerned about what, specifically, it is as long as there's a clear thing that which one is canonical that would solve this particular issue.

D

um If there's, if someone wants to work on a way to like you, write it in one format and it gets copied to the other formats like that would be great I looked into that um for a while, like I started, I started, actually writing it in in the Proto descriptor.

D

Like writing all the documentation there as a comment in there and then, like you, write markdown as a comment in a protobuf file, and then you could parse that it's not that hard to parse, but the problem is actually authoring because, like writing, markdown in a comment usually doesn't have syntax highlighting and auto formatting gets messed up, uh so I thought it was kind of a pain um and that's why I end up just going with like handwriting the markdown and keeping the two in sync, because I thought like.

D

Ultimately that was less work and I. Don't think this would have actually fixed this particular issue, um because we are like we effectively that we want to both link to the in total spec, but also inline it so people could read so they don't have to jump between two different things and that's where this particular problem lied. Is that like we both copied it and linked and the two disagreed and we didn't realize that they disagreed um so yeah illiterate Proto definition is exactly what I wanted, uh but I I.

E

Thought well can I make some sort of partis like.

D

You know I'm not doing a whole programming project just for this, um so yeah.

A

Yeah, if folks are interested I'm working on that sort of project, so, if folks are interested in contributing we could we could discuss. That's one of the things that actually we've been talking about a little bit in the salsa tooling side is um even if it's not the canonical definition um having something that can translate between these things at least reasonably to get somebody let's say, 80 of the way there um is is useful.

D

Okay, so I think we we could. um We have enough now to on the comment. We could recap the meeting and say the discussion centered around this solution and.

E

I suggest that.

D

We just follow up the rest offline on the issue on the details of which should be canonical and how we implement, but I feel like that. The hard decision was kind of made yeah Arno.

F

You know I think that's fine, I I just want to say that if we think the in total attestation definition is, is the primary source it since we can, unless we can link from the other I mean we could. But you know today we don't have a link from the uh the Q version or the port above version, so that means the text would want.

F

You would want the text to be the primary source, and- and so uh that's what you would want to see in, but as I pointed out, I, don't think this is what most software engineer will will take. I mean I, look at the photograph or because I'm like yeah. This is, you know much more concise way. Something I can read very quickly and say: I know what that means and I think that's what most people are going to do.

F

This is why you know I think if anybody has implemented, they will have used this and not click on the link read through the table and all that but uh yeah. So we have to decide, but it's not so easy here.

F

But we can take that offline I agree, I mean at the same time. We should try to not wait too long. The longer we wait, the worse the case becomes right, so we have to think carefully, but at the same time be being pretty, you know.

F

Diligent and getting it done.

D

And this is actually uh good timing, because Tiani was working which we talked about before of the the using the branches to do the versioning. So we don't do like a director.

E

Crop I guess technically it's a.

D

Directory copy, but it does it through like git, so we keep retaining history, so uh um I could work with him and do.

E

That for this version,.

D

um This could be the trial trial run so good timing on that.

D

Okay, uh I suggest we move on to the next issue. Sound good.

F

D

Just for the sake.

F

Of it, I think it's important that we should clearly minute this is the decision. The status quo is we're going, you know the consensus is we are going to just do a minor version bump.

F

E

D

Yeah yeah, sorry I, don't know what you mean I, so I put it in the meeting notes. It says that's what the decision was and I plan to update the issue after the meeting recapping. That does that sound good to you, yeah.

F

Yeah, that's fine I, just I I cannot see the minutes right now, so I just want to make sure it's captured thanks.

D

uh Chris, do you want to take the next one.

H

Yeah so I I, remember someone mentioning a few weeks back the the possibility of doing issue triage in these meetings weekly, so I put together a quick and dirty uh dashboard on on GitHub. Let me see if I can share it.

H

uh I have never screen shared in Zoom.

H

H

All right did that work yeah. So this is the bug standard uh bug. Backlog template in in GitHub uh I do not have permissions to share it with the org, but I I think it'd be great. If we had this uh just living permanently on the projects page.

H

So there are two issues that came in and also two PR's, that I thought could uh so going through them quickly. Now um this one I opened the folks who build the GitHub generators are working on I believe it. This came up specifically for their container build generator. They miss they they're missing the config Source from the provenance format 0.2, and they think that adding an additional fields to the external parameters that that marks out the source code of the build is useful for making builds more reproducible based on their provenance thoughts.

B

I haven't seen like a strong articulation of why this is required, like they've said that they think it's useful, but I haven't seen them describe how or like.

H

D

Yeah I, um actually I spoke with some some of the folks um separately, I I think what's needed as a model right now, we don't have a model for what the word Source means, um and that was like one of the things that we wanted to do with v 0.2 and then went in the other direction. Just say you know we're not even going to Define it because we don't need it.

D

um Yeah I, agree, I feel like we kind of need it I. My gut feeling is that this would be a good thing for a a true V2 um that, like we kind of someone, it's almost like a like a Divergence, then convergence type of thing where, like you start out with one thing, and then you have different use cases, so you kind of diverge based on um different needs, and then you realize where the commonalities are, and then we could converge onto like some common model.

D

That's my sense here is that it that, like we, don't have enough examples of build types to know what like the archetypes, are, and that ultimately will find that, like most build systems fall into this thing, and so we can main standard fields for that. um But I. My.

E

Sense is that we're not there yet.

D

But I'm I'm happy to be wow. Father folks, disagree.

H

uh Last call for thoughts, and we can move on. It sounds like sorry. It sounds like the the decision here is to um not not take up this issue at the moment. Wait for uh for modeling work or additional examples is that correct.

H

H

All right, the next is eight seven. Three, this was opened by uh I, believe it was David wheeler he is proposing.

H

um This is a big one. He is proposing either incorporating the concept of semantic equivalency into salsa, build level four or perhaps having a separate salsa track for build reproducibility.

H

A

Yeah so I I read through this issue, um yeah I think that the the main thing is is uh one of the key things that that he brings up in there that some folks have talked about is sort of trying to separate out bit for bit binary reproducibility from something from some other definitions that are above and beyond what we currently have so um and I think that's sort of worthwhile um I do also think that we should probably spend a little bit of time figuring out the definitions of those things, whether it's semantic equivalency, whether it's there's, probably some other things in there- that we probably also want to think through, like some some of the stuff that I know we had discussed was um something like you know, like hermetic, builds or I.

A

Think to to what Mark had said. We should just sort of describe that thing, um as opposed to necessarily defining necessarily just using a word or using a phrase and then defining it. Maybe just sort of spelling it out and so um I do think that the the idea there is is is good. Whether or not we should pick those particular um words and phrases is, is I, think Up, For, Debate.

H

uh Andrew I I just saw you put your hand down. Did you have something to say.

J

I did I didn't, come off, mute, um getting used to to zoom again um Mark and I had a little bit of a conversation. Conversation around this in the Hermetic um issue as well a couple weeks ago.

J

um I think that it makes sense to have a reproducible track, and some of the requirements from the former hermetic requirement, like uh dependency pinning to me, makes more sense to be in a reproducible track. um I I know you saw that I just commented on on this issue during during this call.

J

um One challenge that I feel like will have to contend with, as we create additional tracks, is what the common theme is for each of the the tracks so like for the build track, how I've Justified it in my head at least, is that we're working on build platform partnering in order to get complete prominent generation, and so that's where this, the the complete resolved dependencies fits in which arrived in in or which was like the previous hermetic requirement.

J

um If, if there's not something like and so I I, don't know if that, if we need to have like some kind of summary on each of these additional tracks, that says this is the core tenant that we're trying to achieve with this track. I think that we could achieve I think we can figure that out for a reproducible track as well um and and so I I think that it does make sense to me to have a reproducible track.

H

All right, uh Trish, shank I, believe, is next yeah.

C

Thanks I wasn't sure who was next um yeah I agree with keeping reproducible bills semantic equivalency. You know different gradations for that in a different track.

C

um I also agree that it's important to figure out. What's common to it, because at least to me, it's not clear that, while it's not even clear to me that you necessarily need a hermetic build environment for reproducible bills, I mean I could always look outside so long as that third party mirror is reproducible I, don't necessarily care whether I'm using something hermetic anyway just wanted to bring out um yeah. We need to. We need to figure this out. What defines a reproducible bills track.

A

um So, along those lines, yeah I think one of the things that uh I think has proven useful from a communication. Standpoint was if we, if we take, that that main diagram we have on the salsa site.

A

From the salsa site we can um what's been useful, is being able to point to the box and saying this helps there uh I found that to be very useful in in communication and also getting folks to understand so, for example, the build track that build box where we had solar spill dependencies and then publish or whatever package something like that.

A

um It's been very useful to just be able to say Yep. This track works on that box, and so I think um you know uh if we go, let's say make it separate from as opposed to salsa build level four. We we make it a separate track or whatever I think it's worthwhile to just sort of explain exactly where that fits in, and maybe it's something like the box within the box right. You know, with the build Providence helps protect against this. Then the build reproducibility track protects against.

A

You know this right and point to the where that might be in the in the diagram.

H

D

um So I guess I'll disagree with everyone else. um I, don't think it makes sense for reproducibility to be its own track. I view I. Think, there's two things involved in the proposal. One is When, comparing two artifacts, you don't just do a straight hash, but.

E

D

Look at them through some other. uh You know comparison operation that seems lower level.

E

D

The specification it's kind of an implementation, detail um and I think it's completely compatible with whether even if you're not doing reproducible builds like.

E

If you just do a.

D

Regular old build with provenance and something that mutates it, but the mutation's okay, you could do that. That seems okay and then reproducibility I again I.

D

It seems, like reproducibility, solves a bunch of different problems, one of which is trustworthiness of the build and tampering of the build, which is the build track and reproducible builds is one way of Doom a system of multiple verifi. Reproducables is one way of doing that and then, as uh Andrew said like um having like.

E

D

Properties that we care about, such as, like all the dependencies declared.

E

Up front, which is necessary for reproducible.

D

Builds uh could be another thing, but to me it doesn't seem like reproducible itself is the goal, but rather that we're trying to solve some other thing, and that should be the track.

A

Yeah I agree with Mark there, I I think I could be convinced if, if we wanted to uh go into something akin to like.

E

A

If I, if I, think about what we've built so far, you're talking about securing the build infra and making sure that a bad build itself can't um compromise other builds. You know like if I start to think about what the goals of the current track are right um and so far nothing in the existing build track. Actually, talks about the security of the builds you're actually running right, we're sort of saying that's untrusted user code that we don't actually know if it's doing anything suspicious.

A

But what we are doing is we're saying: hey we're protecting against the build infra from being compromised either by a bad, build or from um you know, the the build that you're using essentially like lying about what it did taking keys and signing keys and all that good stuff.

A

J

Yeah and so I think that that um well I'll take what what Mark said and I'll try and claim that we're still that we were still consistent with what I said before that.

J

If we identify what that common theme is, it makes sense to have a reproducible track and I. Think reproducible still like reproducible falls in the same scenario of hermetic. We shouldn't use the word reproducible. We shouldn't use the word hermetic um in in the in the the conversations that we've had around hermetic um I know, uh like I, think uh a dependencies track was tossed out. There I think that still doesn't quite make sense, and so I think that a lot of these Concepts fit well together and have a common goal.

J

But what that core tenant is that we're trying to achieve needs to be assessed out and I think that this is also a good one or a good candidate for trying to figure out what it means to have a closely related but separate track and how how we can identify or how we can maybe isolate what it is that we're care that we care about here as opposed to there, where, in this situation, I think it makes sense that the there is is the build track.

J

So what is the here versus the there of the build track, and how can we clearly differentiate that goal, along with the multiple levels that we have in our mind, to achieve.

H

All right, if that's everyone's thoughts, um I guess we can move to PR triage I, don't know who who added this um but I'm I'm happy to talk about it. um No Michael Wheeler added tacos to the salsa FAQ.

H

um It looks like a few people have already reviewed this and approved it um so yeah, maybe just an FYI, to take a look at it before it merges.

B

I I'll plan to merge that uh tomorrow, if there aren't any objections.

F

Yeah I I think this is a really not very you know it's just the FAQ and we can be uh really relaxed about that. One I'm sorry, but I didn't get. What's the what's the the takeaway from the discussion before, though, on the issue I mean what, in terms of like, we were supposed to do some triage here. What's the outcome of the discussion, what do we do with that issue?.

H

H

We can add it to the backlog, I I think the this issue only becomes actionable if somebody is willing to work on it, because it's quite a lot of work. um So unless we have a volunteer, I propose moving it to the backlog. Category of the dashboard.

B

I mean yeah I think in terms of like issue triage. This issue is too large and needs being if we covered many topics as part of that description. It covers many topics. Ideally it would be broken down into my tractable things, but as Chris Reich said, we need someone to someone who cares about how to own it. I I think there is a certain amount of folding into existing issues that could happen or has probably happened, um but backlog makes sense until there's someone there will excellent.

F

Well, that's fine with me.

D

Okay, I think: that's it! um Okay thanks everyone again! If someone could run a meeting next week, uh I'd appreciate it um and uh I guess: I'll, see everyone soon and talk to you online thanks, Aaron, bye,.

B