Tightening branch and tags security

[Guillaume Smet]

Hi,

As you may have noticed, I have been working on reducing our exposure to supply chain attacks.

In this context, I have been designing some restrictions on branches and tags for the main quarkusio/quarkus repository (some of them were already in place but some are new - and they will use the rulesets features on GitHub).

These restrictions are not in place yet. I wanted to gather feedback before trying them. Unfortunately the rule evaluation feature is only for Enterprise users so we will have to enable them and see what breaks...

An important note: I don't want these to be in the way of the project, so we might try some and discover they are a really bad idea and revert some of them. But I think we should start and see what's in the way and adapt quickly, rather than being permissive.

- Tags (starting with the easy one)

. Only the Quarkus Bot will have the ability to create tags. Tags will be immutable.

- Branches

. No one except a very few selected people (+ Quarkus Bot and Dependabot) will be able to create a branch on the main repo. The only reason we have to create a branch on the main repo is when we are starting very specific projects such as the Jakarta migration or the current Vert.x 5/Quarkus 4 effort and it is coordinated at the project level. This will avoid people pushing their work branches by mistake to the main repo.

. No one except a very few selected people will be able to push directly to main and the release branches. Pushing will require a PR + merge, which is basically what we already do.

. We will require an approval of the latest commit pushed before merging. I know it's a bit annoying but it's not possible to restrict this to only external contributors. And I want to avoid us approving something and then missing that something new containing malware of some sort has been pushed between approval and merge.

Then there are a couple of additional restrictions that we were already applying: no force pushes...

Thoughts?

-- 

Guillaume

[Stephane Epardaud]

This all sounds like a good idea.

On Fri, 3 Apr 2026 at 11:54, Guillaume Smet <guillau...@gmail.com> wrote:

. No one except a very few selected people (+ Quarkus Bot and Dependabot) will be able to create a branch on the main repo. The only reason we have to create a branch on the main repo is when we are starting very specific projects such as the Jakarta migration or the current Vert.x 5/Quarkus 4 effort and it is coordinated at the project level. This will avoid people pushing their work branches by mistake to the main repo.

[…] 

Then there are a couple of additional restrictions that we were already applying: no force pushes...

 No force pushes even on PRs? This will mean that you won't be able to rebase on the few branches (such as those you mentionned), but perhaps it's a good thing because those will be collaborative so perhaps a merge model is better anyway for those?

[Guillaume Smet]

> No force pushes even on PRs? This will mean that you won't be able to rebase on the few branches (such as those you mentionned), but perhaps it's a good thing because those will be collaborative so perhaps a merge model is better anyway for those?

PRs are not branches from the main repo, the branches live in your fork, so you can do whatever your fork allows.

But you raise a good point for Dependabot PRs where we sometimes force push additional stuff, I'll adjust that.

[Stephane Epardaud]

I was specifically talking about the few branches you said we'd allow, such as the Vert.x upgrade ones.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo8--DGaN%2BbPn8Z3bxiBXwi9JdfTisBJAbvnBrz5i804UA%40mail.gmail.com.

--

Stéphane Épardaud

[Guillaume Smet]

> I was specifically talking about the few branches you said we'd allow, such as the Vert.x upgrade ones.

Yeah, so we will have to see about these ones.

Now, I still think the number of people who can force push to these branches should be very limited.

Or depending on the workflow they choose, we could temporarily relax the rules and then enforce them back to avoid mistakes.

I agree we need a bit more flexibility here.

-- 

Guillaume

[George Gastaldi]

You can also push to another fork's branches when a PR is created AND you are a maintainer in the main repo. That could prevent other branches in the main repo.

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo-QA_Duf%2B_BrUt4ssnLfj2azVoxe7PkLbAh68XMMFpz1g%40mail.gmail.com.

[David Lloyd]

On Fri, Apr 3, 2026 at 4:54 AM Guillaume Smet <guillau...@gmail.com> wrote:

- Branches

. No one except a very few selected people (+ Quarkus Bot and Dependabot) will be able to create a branch on the main repo. The only reason we have to create a branch on the main repo is when we are starting very specific projects such as the Jakarta migration or the current Vert.x 5/Quarkus 4 effort and it is coordinated at the project level. This will avoid people pushing their work branches by mistake to the main repo.

Is there a good technical reason why project-level topic branches *have* to live on the project organization (as opposed to living on a fork, preferably one belonging to a responsible person for the work)?  Maybe we could get rid of these as well.

--

- DML • he/him

[Guillaume Smet]

On Fri, Apr 3, 2026 at 5:34 PM 'David Lloyd' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

Is there a good technical reason why project-level topic branches *have* to live on the project organization (as opposed to living on a fork, preferably one belonging to a responsible person for the work)?  Maybe we could get rid of these as well.

We don't do that very often, it's mostly when a very long effort has to be coordinated across several participants and we feel it's safer to host the branch in the main repo.

My recollection is that we did it twice in the life of the project: the first time for the Jakarta 10 effort and now for the Vert.x 5 effort.

-- 

Guillaume 

[Georgios Andrianakis]

+100, we should have done this long ago

Then there are a couple of additional restrictions that we were already applying: no force pushes...

Thoughts?

-- 

Guillaume

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_5wqfEigqxJ3tp69L-GQd91My%3DCV3a1jVP2bHmsG2COA%40mail.gmail.com.

[Guillaume Smet]

I have applied some rule sets to both the org and the main repo.

Please let me know if you are blocked on something.

-- 

Guillaume

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3DFmP7AgO09nhADtLZhn1dZhJbKWSd7CSTKoJwpN1YWkg%40mail.gmail.com.

[Yoshikazu Nojima (能島 良和、ノウジマ ヨシカズ)]

Hi,

First of all, I understand the intent behind this restriction and agree that it is generally necessary. That said, the newly enforced organization-wide ruleset, in particular `Require a pull request before merging`, is affecting existing automation workflows.

Specifically, `ja.quarkus.io`, the Quarkus localization site, is affected, and the same applies to `pt.quarkus.io`, `es.quarkus.io`, and `cn.quarkus.io`.

In these localization repositories, GitHub Actions periodically pulls translatable texts from the upstream repository (`quarkusio/quarkusio.github.io`), machine-translates them, and automatically commits and pushes the updates to each localization repository, such as `quarkusio/ja.quarkus.io`.

https://github.com/quarkusio/ja.quarkus.io/actions/runs/24127973583/job/70397175731

Also, while I am not very familiar with the details there, it appears that `quarkusio/quarkusio.github.io` is similarly affected, as it has an automated process that copies AsciiDoc content from `quarkusio/quarkus`.

https://github.com/quarkusio/quarkusio.github.io/actions/runs/24134666024/job/70419556201

For recurring synchronization jobs of this kind, we would prefer to avoid moving to a model where pull requests are automatically opened and then automatically merged, since that would result in a large number of unnecessary pull requests and a significant amount of notification noise.

At the moment, the most practical way forward seems to be to either create a new GitHub App or reuse an existing one, add that app to the ruleset bypass list, and perform `git push` using that GitHub App’s credentials.

If there is any policy or recommended approach for handling this kind of existing automation workflow, I would appreciate your guidance.

2026年4月8日水曜日 0:50:20 UTC+9 Guillaume Smet:

[Guillaume Smet]

Hi,

On Wed, Apr 8, 2026 at 3:25 PM 'Yoshikazu Nojima (能島 良和、ノウジマ ヨシカズ)' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

First of all, I understand the intent behind this restriction and agree that it is generally necessary. That said, the newly enforced organization-wide ruleset, in particular `Require a pull request before merging`, is affecting existing automation workflows.

Specifically, `ja.quarkus.io`, the Quarkus localization site, is affected, and the same applies to `pt.quarkus.io`, `es.quarkus.io`, and `cn.quarkus.io`.

In these localization repositories, GitHub Actions periodically pulls translatable texts from the upstream repository (`quarkusio/quarkusio.github.io`), machine-translates them, and automatically commits and pushes the updates to each localization repository, such as `quarkusio/ja.quarkus.io`.

https://github.com/quarkusio/ja.quarkus.io/actions/runs/24127973583/job/70397175731

Also, while I am not very familiar with the details there, it appears that `quarkusio/quarkusio.github.io` is similarly affected, as it has an automated process that copies AsciiDoc content from `quarkusio/quarkus`.

https://github.com/quarkusio/quarkusio.github.io/actions/runs/24134666024/job/70419556201

Thanks a lot for the feedback, that's exactly what we have been looking for.

I pondered starting a month-long project to analyze everything and make sure we don't break anything but things were a bit more urgent than that so I decided to put barriers in place and then adjust.

I already fixed the quarkusio.github.io workflow today. And I think I also relaxed the rules for the translation repositories so my guess is that it's already fixed (but like 30 minutes ago). As long as you don't force push.

Let me know if it's not and I will have a second look.

-- 

Guillaume 

[Eric Deandrea]

Instead of pushing directly, can’t the automation raise a PR and then merge it directly? We do this in lots of automations. See https://github.com/quarkusio/quarkus-super-heroes/blob/ee264f46f4aacc03d7ead7186c5d3ce812524abc/.github/workflows/create-deploy-resources.yml#L60-L107 for example.

Eric Deandrea

Java Champion

Senior Principal Software Engineer

Quarkus | LangChain4j | Docling-Java

Red Hat

edea...@redhat.com    M: 603.453.5840

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo9yUhLp0Deqcmos%3DH5QuvmYAo_9aRKfqFZ2QDC6RnT-JQ%40mail.gmail.com.

[Yoshikazu Nojima (能島 良和、ノウジマ ヨシカズ)]

Thank you for relaxing the ruleset. I have confirmed that the workflow now finishes without errors.

Eric,
While it is definitely possible to automatically create and merge PRs, I am worried that doing so would generate a large number of unnecessary pull requests and a flood of related notifications.

2026年4月8日水曜日 23:41:58 UTC+9 Eric Deandrea:

[Guillaume Smet]

On Wed, Apr 8, 2026 at 5:50 PM 'Yoshikazu Nojima (能島 良和、ノウジマ ヨシカズ)' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

Thank you for relaxing the ruleset. I have confirmed that the workflow now finishes without errors.

Eric,
While it is definitely possible to automatically create and merge PRs, I am worried that doing so would generate a large number of unnecessary pull requests and a flood of related notifications.

Yeah I kinda agree for the time being, in your case, pushing is good enough.

Glad the issue is sorted out for you.

-- 

Guillaume 

[Julien Ponge]

> I was specifically talking about the few branches you said we'd allow, such as the Vert.x upgrade ones

We’re not using force push on this one. We make weekly merges from main or else we’d break our own local branches.