Maturity Level 1 may be hard to attain for ... anyone.

[jordansissel]

• OSPS-BR-01 "MUST NOT execute arbitrary code that is input from outside of the build script."

Depending on interpretation (it's ambiguous), this excludes nearly every software packaging system. RPM and Deb both support arbitrary code execution "outside of the build script" with things like post-install shell scripts, etc. Same for Ruby, Node, etc, which all support having packages execute code at installation time.

I believe I understand the intent of OSPS-BR-01, but the wording really feels like it excludes every 3rd party source of anything that isn't just a tarball or equivalent container asset.

• OSPS-BR-03 MUST be delivered using SSH, HTTPS or other encrypted channels

I do not consider "plain text delivery of cryptographically-signed assets" to be an "encrypted channel", so it might be worth considering the rather large case of Debian and its derivatives. Debian primarily uses HTTP or FTP, unencrypted, to deliver packages through its mirrors. Ubuntu mirrors often behave the same way.

The way I read this, anything using Debian or its variants or derived products, including container images based on Debian and Ubuntu, would be in violation of this.

It's possible these two criteria should be addressed in separate issues, but I felt it more focused on the "maturity level 1 is impossible if you use Debian at all, anywhere"

[funnelfiasco]

My initial thoughts here, and I'm not speaking for the rest of the WG, is that the issue with OSPS-BR-01 is a matter of ambiguity. An RPM, for example can run arbitrary code, but it doesn't run arbitrary code. "Ben," you say, "that makes no sense." Correct. What I'm getting at is that the code executed in rpm scriptlets is well-defined; even though it could be anything, for any given RPM, it is not. Debs are the same way. I'm not familiar with Ruby, Node, etc, but I'd imagine it's similar. So we probably need to be more clear about what we do and do not intend for this to mean.

As for OSPS-BR-03, there's a part of me that thinks that distro mirrors should come into the 2020s. That said, I don't see much risk of "plain text delivery of cryptographically-signed assets", as any supply chain attack there would have to also compromise the signing, in which case, http vs https won't matter anyway. I don't think your read is unreasonable here, so there's probably a discussion to be had on how we draw (and articulate!) the line here, too.

No matter what we ultimately do with this feedback, I'm glad you raised it. If level 1 is impossible to achieve (or is perceived as impossible to achieve by people who are developing open source software), our work here is not going to be very useful.

[david-a-wheeler]

I agree, these are too ambiguous.

Regarding:

• OSPS-BR-01 "MUST NOT execute arbitrary code that is input from outside of the build script."

The "obvious" interpretation of this text would also forbid the use of Rust, which is often installed by downloading a script & then running it.

This needs a rewrite, which is hard. However, let's start with the goal.

My understanding is that the goal was to prevent the following situation: An attacker creates a pull request on GitHub, with a change to the workflow, and the workflow is automatically run while providing the workflow with sensitive data (like secret keys that might be used for an install). The intent, as I understand it, is to only run code once it's been approved.

I'm not sure how to word that, especially since not everyone uses GitHub or GitLab, & this needs to be worded to handle OSS outside those walled gardens.

Possible rewrite:

OSPS-BR-01 "MUST NOT immediately execute arbitrary code provided by an untrusted proposer in its CI/CD pipeline, unless the CI/CD execution provides it no special privileges or such changes are first authorized."

Regarding:

• OSPS-BR-03 MUST be delivered using SSH, HTTPS or other encrypted channels

You could instead borrow the text from the related OpenSSF Best Practices badge criteria, which focuses on countering the threat instead of what mechanism must be used:

• The project MUST use a delivery mechanism that counters MITM attacks. Using https or ssh+scp is acceptable. [delivery_mitm]

[funnelfiasco]

For OSPS-BR-01, this was already open as #63. Conversation is ongoing in that issue.

[eddie-knight]

Hey @jordansissel, we've been applying feedback in preparation for the upcoming release. There are still some changes pending, but we'd love to hear if you have input on the revised criteria.