Is 'branch protection' only applicable for cloud-hosted SCPs?

[TomHennen]

To my knowledge, branch protection is a feature of specific cloud-hosted SCPs, not git/VCS, so I suggest making this requirement for Continuity more generally about the intent/objectives. Then we can maybe just include an example like "This can be achieved using the branch protection features in services like GitHub, for example."

Originally posted by @marcelamelara in #1094 (comment)

[TomHennen]

FWIW I think that GitTuf might make this possible outside of a hosted SCP. @adityasaky would know for sure.

[zachariahcox]

good question!
It's not branded in exactly the same way (because it's way more powerful), but git supports this kind of feature via pre-receive githooks.

The current wording in the pitch is: "On VCS like git, the organization MUST enable branch protections that prohibit updating the branch to point to revisions that are not direct descendants of the current revision."

That does make it sound like there's a button to click somewhere!
We could make it more generic by saying "enforce branch protections."

cc: @marcelamelara

[adityasaky]

I think this may in part be addressed with #1128 and #1142. I think #1142 in particular would allow us to set requirements that may be achieved wildly differently depending on what constitutes the source control system as a whole.

As for the rest of it, I think the requirement could use further clarification. The full set of branch protections (whether via an SCP, pre-receive hooks, etc.) could mean quite a bit further than disallowing force pushes and deletions (which are stated as the baseline in the spec atm), so I think clarification is in order as to what the requirement exactly is. Maybe we could reuse this issue for that? 😄

[zachariahcox]

@adityasaky can you further clarify what you're looking for here?

I like what you're saying, but I feel like this is very clear: https://github.com/slsa-framework/slsa/blob/main/docs/spec/draft/source-requirements.md#level-2-branch-history

The branch protection requirements are there under the "continuity" heading:

Continuity
For all branches intended for consumption, whenever a branch is updated to point to a new revision, that revision MUST document how it related to the previous revision. Exceptions are allowed via the [safe expunging process](https://github.com/slsa-framework/slsa/blob/main/docs/spec/draft/source-requirements.md#safe-expunging-process).

On VCS like git, the organization MUST enable branch protections that prohibit updating the branch to point to revisions that are not direct descendants of the current revision. At a minimum, this typically means preventing "force pushes" and "branch deletion."

It MUST NOT be possible to delete the entire repository (including all branches) and replace it with different source. Exceptions are allowed via the [safe expunging process](https://github.com/slsa-framework/slsa/blob/main/docs/spec/draft/source-requirements.md#safe-expunging-process).

The goal of these minimal branch rules is to produce a reasonable history.
Can you assign this issue to yourself and write up a proposal PR to change it?
Otherwise, I vote to close this one.

[adityasaky]

@zachariahcox I opened #1175, let me know what you think!

[bureado]

The wording in e1ac854 LGTM.

But honest Q: if the subject of the VSA already binds the (immutable) revision to the (mutable) human-friendly references at the time of VSA creation as part of the VSA's subject, what's the benefit of having the predicate trying to say the equivalent of "remote reported they implement a receive hook which enforces rejection of operations modifying linear history of a subset of branches deemed for consumption"? (e.g., I saw a ref_protected value in a JWS claim, or GET /branches/<>/protection at a given timestamp X, etc.)

To be super clear, I think there's good security value in requiring branch protection (in the most generic, non-platform specific way) but it seems to me that is more "scorecardy" and requires continuous inspection, whereas this requirement seems to be defending a user who prefers human-friendly mutable references like branch names being misled into believing that the revision they got is the revision everyone else has always gotten. My point is that determination can really only come from looking at the historical subjects of the VSAs themselves, possibly from transparency logs. 2e-2. (Edit: ...or from an attestation made by the repository owners that they enforce force push prevention and have processes itself that limit the ability to roll it back, etc.)

[david-a-wheeler]

How about, "Prevent unintentional unreviewed changes to a main branch, e.g., by enabling branch protection"? Branch protection can be helpful on GitHub, but I agree, it's better to focus on the overall goal.