Just as a side note: what is the name of the default branch in future? The release workflow needs a tough change towards maven-CI-friendly-versions… thus what about tags?
Best Regards Kemal > Am 30.07.2025 um 21:04 schrieb Elliotte Rusty Harold <elh...@ibiblio.org>: > > I'd start with Tier 1 (I've asked for that before in different > language) and also Tier 2 and Tier 3. Tier 4 is overkill. > >> On Wed, Jul 30, 2025 at 11:02 AM 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 >> > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > 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
