I'm all in for the first level of OpenSSF scorecard = "Prevent force push + Prevent branch deletion" And that should be done not only for default branch, but also every maintenance branch when we maintain mutliple branches in parallel (Maven 4.1 vs 4.0 vs 3.8 vs 3.8, components or plugins 3 vs 4, Doxia 1.x vs 1.20.x vs 2.x)
sadly, I don't know how to implement with .asf.yaml for "Require at least 1 reviewer for approval before merging", IIUC it combines 2 steps: - reject direct commits to maintenance branches: require use of PR + merge - and PR requires more than self review I'm not absolutely against, just dislike: 1. the overhead 2. the bad habits this will promote 3. it will break maven-release-plugin process that commits directly to maintenance branch explanation: 1. overhead of for PR + merge: on simple typos, i'll have in addition to select a PR label to NOT list the PR in the release notes 2. bad habits: requiring review even on simple typos, I will find a buddy to quickly pair review everything small I do (in the same timezone as me, and we'll help each other at reviewing quickly) The bad habit comes here: my buddy will quickly review everything, small or big... 3. if someone wants to add new features and clarify new steps in the release process in summary: yes for step 1, it's a very good step for next steps, please all prepare in depth: maybe I'm just lacking optimism Regards, Hervé Le mercredi 30 juillet 2025, 13:02:01 CEST Sandra Parsick a écrit : > 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-plu > gin (OpenSSF score card for m-dependency-plugin) > [2] > https://docs.github.com/en/repositories/configuring-branches-and-merges-in-y > our-repository/managing-rulesets/about-rulesets [3] > https://github.blog/news-insights/product-news/github-repository-rules-are-n > ow-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/g > ithub/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
