3 ms·
I completely agree with the primary point of the author, which i summarize as: don't ask me to meet your companies arbitrary requirements for code when we don't
by er4hn 4y ago
I completely agree with the primary point of the author, which i summarize as: don't ask me to meet your companies arbitrary requirements for code when we don't have a business relationship. Completely fair. However I don't think that is what software supply chain security is about.
When you look at something like SLSA (slsa.dev) it's more about internal build systems. You are pulling code and dependencies from somewhere, that is cool. Now that it is in your environment how do you validate it matches what the upstream provider has? How do you secure your build environment? How do you prevent the outputs of builds, stored internally, from being tampered with? The most popular strategy to date has been "hope" as in "hope is not a plan".
Where it sucks for OSS maintainers is you have companies coming in and continuing to try and apply hope internally and send prodding emails upstream to not rely on hope. That's bad and is not something worth OSS maintainers dealing with. Unless, you know, the company is offering money to do so.
- di4na 4y agoSo I went to check SLSA Version Controlled: On the maintainer side Verified History: On the maintainer side Retained Indefinitely: Can be both Two Person Reviewed: On the maintainer side Scripted Build: On the maintainer side, could be both but not the current model Build Service: Both i suppose Build as code: On the maintainer side Ephemeral env: User side Isolated: Both Parameterless: Both Hermetic: Both but mostly maintainer Reproducible: Maintainer side Available: Could be discussed but maintainer Authenticated: Maintainer Service Generated: Both Non-Falsifiable: both Dependencies complete: Both Security: Maintainer side Access: Not applicable Superusers: Both So SLSA mostly demand work from the maintainers, not the users.
- er4hn 4y agoThank you for reading through it and summarizing. I disagree with your conclusion however. It's not possible for someone to completely trace upstream dependencies in a SLSA compliant manner. No company can sanely expect that. What can be done is to say "we have some code from outside. How can we attribute it to upstream and make sure it has not been altered?" You can use signatures from the maintainers, version it, even reference a git commit. I don't think that anything additional from maintainers should be required, it's on the company to figure out how best to do so.
- di4na 4y agoI understand your point. But that is explicitly not the point the SLSA are making, nor any of the thought leadership on this. The reality of opensource are totally absent in these discussions. Noone say the things you just said. I understand why you think it should be obvious and how it is done, but that is simply not the reality out there.