Thanks Maarten,
Good catch with the sync between Gitbox and GitHub. It seems, IMHO, we
need a mechanism that ensures that both sides have the same protection
rules. I will put it on my list of open questions.
Thanks,
Sandra
Am 30.07.25 um 21:45 schrieb Maarten Mulders:
Hi Sandra,
Thanks for bringing this up! It sounds very interesting, I haven't heard
much about this before but I could see there are benefits in enabling
some of these protections.
I'm curious, since we have bidirectional sync between GitHub and the
Apache Gitbox. How effective would these measures be? Could one (a
malevolent actor) perform a force-push against a branch on the Gitbox
which would then nevertheless end up on GitHub as well? Or delete a
branch? Or... (you get the idea).
Thanks,
Maarten
On 30/07/2025 13:02, Sandra Parsick 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
