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)
Good catch. Yes, I agree that every maintenance branch should be covered
by branch protection rules.
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
Yes, introducing of security precaution in the process is always a
trade-off between usability and the risk reduction. So the following
questions come to my mind:
- How often do we see such kinds of changes?
- Can we have an exception for such kind of changes? (Maybe we feed
another bad habit with that?)
- Not having such a rule, do we promote other bad habits?
- Which bad habit is okay for us?
At the end, IMHO, we should answer the question:
Does an introduction of such a rule help us to reduce risk in the supply
chain and the benefit of it is higher then the effort in the process? If
not, we can skip it.
3. if someone wants to add new features and clarify new steps in the release
process
Yes, when something changes in the process, we have to relearn the step
where the change had effects. Therefore, we have to check if a change
brings a benefit for us. Maybe we do not have a benefit for now, but
maybe in the future.
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
Yes, step 1 will be a good starting point.
Am 30.07.25 um 19:02 schrieb Hervé Boutemy:
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
