Hi, Please note that only those branch protection rules which are enforced by both GitHub and GitBox matter. As long as I can easily bypass the branch protection rules by working with GitBox there is little point in enabling those. AFAIK only the prevent force push is now is now enforced: https://github.com/apache/infrastructure-asfyaml/issues/72
Konrad > On 30. Jul 2025, at 13:02, Sandra Parsick <san...@parsick.dev> wrote: > > Hi, > > I have taken a more in-depth look at the branch protection checks of the > OpenSSF scorecard best-practices, and I'd like to discuss two topics: > 1. Do we want to enable GH rules to pass some of them? > 2. How do we want to enable the GH rules? > > In their documentation [0] , following checks are documented, when the score > card checks are running without admin permissions: > >> This check determines whether a project's default and release branches are >> protected with GitHub's branch protection or repository rules settings. >> [....] Each tier must be fully satisfied to achieve points at the next tier. >> Tier 1 Requirements (3/10 points): >> - Prevent force push >> - Prevent branch deletion >> Tier 2 Requirements (6/10 points): >> - Require at least 1 reviewer for approval before merging >> Tier 3 Requirements (8/10 points): >> - Require branch to pass at least 1 status check before merging >> Tier 4 Requirements (9/10 points): >> - Require at least 2 reviewers for approval before merging >> - Require review from code owners >> Tier 5 Requirements (10/10 points): >> *Only affected when scorecard check runs with admin priviledged* > > > Of course, the main critism can be "why to invest time in implementing branch > protection rules? Only for earning points to get a nice 'trophy'?" > > From the user perspective, having an OpenSSF badge with a good score on the > README can help the user to decide if it is valuable to take a deeper look at > the project. In our case, it would also show that the Maven project cares > about supply chain security. > > From the maintainer perspective, we should look at every check and decide > check by check if they really help us in our daily work and how high the > effort is to implement passing the check. > > Here is a first review of the best practices proposed by OpenSSF Scorecard: > > - Prevent force push > This check can be satisfied with the GH branch rule 'Block force pushes'. > This rule prevents that someone or an automatismn can overwrite the > repository history accidentally (or consciously) > > - Prevent branch deletion > This check can be satisfied with the GH branch rule 'Restrict deletions'. > This rule prevents that someone or an automatismn can delete the master > branch accidentally (or consciously) > > - Require at least 1/2 reviewer for approval before merging. > This check can be satisfied with the GH branch rule 'Require a pull request > before merging' in combination with the setting 'Required approvals = 1/2'. > This rule in combination with that setting enforces that at least one or two > reviewer on every pull request. It can help to reduce human failure like > "This is only a small change, I don't need a code review" > > - Require branch to pass at least 1 status check before merging > This check can be satisfied with the GH branch rule 'Require status checks to > pass'. This rule enforces that merging a pull request is only allowed when at > least one status check is passed. It can help to reduce human failure like > "This is only a small change. It will not break anything. Therefore, I don't > want to wait until the check is done." > > - Require review from code owners > This check can be satisfied with the introduction of a CODEOWNERS file in > every repository. > > According to an initial check [1], currently no branch protection checks are > passed. But we have at least a rule that prevents force push on the master > branch. > > From my perspective, passing the following checks can help us to avoid > typical human failures that are done mostly accidentally: > - Prevent force push > - Prevent branch deletion > - Require at least 1 reviewer for approval before merging. > - Require branch to pass at least 1 status check before merging > > For passing the check 'Prevent force push' and 'Prevent branch deletion', we > need a refactoring of the current implementation using GH repository rules > [2], [3]. This refactoring would help to make it visible from outside. > > Passing the check 'Require review from code owners', a CODEOWNERS file is > needed in every repository. Maintaining such a file in every repository that > related to Maven could be painful. It belongs to Tier 4 and to pass Tier 4 > all previous tiers have to be satisfied. Therefore, IMHO, we should > concentrate on the other ones. > > Passing the check 'Require at least 1 reviewer for approval before merging', > the GH rule 'Require a pull request before merging' is needed and that will > be have an impact on the release process (m-release-plugin is pushing changes > directly to master branch). We can avoid this impact if we maintain a bypass > list so this rule can be worked around in specific cases, or we can use this > situation and rethink the release process. > > IMHO, we can decide rule by rule if one is helpful for us or not. I don't > think we need to decide like 'implement all rules or nothing.' It also helps > only to implement a few of them. > > If we conclude that it is a good idea to implement such kind of rules. The > next question is how to enable the GH rules. > > Thanks to Piotr, who mentions [4] the possibility of GH repository rules [5], > that can be implemented by calling a REST API. He also drew my attention to > the fact that ASF infrastructure already has support for branch protection in > .asf.yaml [6], [7] (but it seems we are not using it in the Maven project). > One idea could be to refactor this script using repository rules (of course, > we should also discuss it with ASF infra). In case of we have reason not > using ASF infra script, we can implement such script by ourselves for the > Maven source repositories (similar to the shared GH action). Or maybe some > one has another idea. > > Best regards, > > Sandra > > > [0] > https://github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection > (opened on 2025-07-29) > [1] > https://scorecard.dev/viewer/?uri=github.com%2Fapache%2Fmaven-dependency-plugin > (OpenSSF score card for m-dependency-plugin) > [2] > https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets > [3] > https://github.blog/news-insights/product-news/github-repository-rules-are-now-generally-available/ > [4] https://github.com/support-and-care/maven-support-and-care/issues/107 > [5] https://docs.github.com/en/rest/repos/rules?apiVersion=2022-11-28 > [6] https://github.com/apache/infrastructure-asfyaml/blob/main/.asf.yaml > [7] > https://github.com/apache/infrastructure-asfyaml/blob/main/asfyaml/feature/github/branch_protection.py > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
