-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is 'branch protection' only applicable for cloud-hosted SCPs? #1136
Comments
FWIW I think that GitTuf might make this possible outside of a hosted SCP. @adityasaky would know for sure. |
good question! 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! cc: @marcelamelara |
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? 😄 |
@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:
The goal of these minimal branch rules is to produce a reasonable history. |
@zachariahcox I opened #1175, let me know what you think! |
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 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.) |
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. |
Re: #1136 I'm trying to separate "branch protection" which is typically associated with SCP features from the property we want for the branches intended for consumption. I've also applied the SCS terminology we adopted in another PR. The framing of how this can be accomplished is still a bit TBD, if we decide to adopt something like #1142 suggests, we could move the Git + GitHub/GitLab piece out? That's also where we could discuss server side pre-receive hooks etc.?
Originally posted by @marcelamelara in #1094 (comment)
The text was updated successfully, but these errors were encountered: