You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Piotr P. Karwasz" <pi...@mailing.copernik.eu> on 2025/10/29 10:34:50 UTC
Branch protection rules (CTR-style)
Hi all,
I’d like to propose enabling branch protection rules for the Commons
repositories while still preserving our Commit-Then-Review workflow.
Specifically, we could enable the following GitHub settings:
- Require a pull request before merging
- No required approvals: PR authors can merge their own changes, even
seconds after the creation of the PR
- Require status checks to pass before merging
- Enable auto-merge to queue merges, instead of waiting for the required
status checks to pass
- Use only “Squash merge” to keep history linear and avoid noise like
“fix previous commit” messages
I realize this introduces a small amount of process overhead (Byzantine
bureaucracy), but it would bring a few benefits:
- Creates an audit trail for reviews
Even after merge, comments can be used to record approvals. This also
lets us search for PRs without comments to identify code that still
needs review, so we don't need to review each commit 44 times.
- Prevents accidental breakage
Required checks ensure we don’t merge commits that break the build.
- Improves notifications
GitHub doesn’t support commit notifications, but it does notify on PRs
letting contributors follow only the repositories they care about
instead of filtering `commits@commons`.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by sebb <se...@gmail.com>.
On Wed, 29 Oct 2025 at 11:43, Elliotte Rusty Harold <el...@ibiblio.org> wrote:
>
> +1
>
> I'd still prefer RTC but this seems like a distinct improvement. At
> least there'd be no more hidden commits that aren't shown in the PR
> history.
Surely the commit is still shown in the commit history - why does it
matter if there is no corresponding PR?
> On Wed, Oct 29, 2025 at 10:35 AM Piotr P. Karwasz
> <pi...@mailing.copernik.eu> wrote:
> >
> > Hi all,
> >
> > I’d like to propose enabling branch protection rules for the Commons
> > repositories while still preserving our Commit-Then-Review workflow.
> >
> > Specifically, we could enable the following GitHub settings:
> >
> > - Require a pull request before merging
> > - No required approvals: PR authors can merge their own changes, even
> > seconds after the creation of the PR
> > - Require status checks to pass before merging
> > - Enable auto-merge to queue merges, instead of waiting for the required
> > status checks to pass
> > - Use only “Squash merge” to keep history linear and avoid noise like
> > “fix previous commit” messages
> >
> > I realize this introduces a small amount of process overhead (Byzantine
> > bureaucracy), but it would bring a few benefits:
> >
> > - Creates an audit trail for reviews
> > Even after merge, comments can be used to record approvals. This also
> > lets us search for PRs without comments to identify code that still
> > needs review, so we don't need to review each commit 44 times.
> >
> > - Prevents accidental breakage
> > Required checks ensure we don’t merge commits that break the build.
> >
> > - Improves notifications
> > GitHub doesn’t support commit notifications, but it does notify on PRs
> > letting contributors follow only the repositories they care about
> > instead of filtering `commits@commons`.
> >
> > Piotr
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
+1
I'd still prefer RTC but this seems like a distinct improvement. At
least there'd be no more hidden commits that aren't shown in the PR
history.
On Wed, Oct 29, 2025 at 10:35 AM Piotr P. Karwasz
<pi...@mailing.copernik.eu> wrote:
>
> Hi all,
>
> I’d like to propose enabling branch protection rules for the Commons
> repositories while still preserving our Commit-Then-Review workflow.
>
> Specifically, we could enable the following GitHub settings:
>
> - Require a pull request before merging
> - No required approvals: PR authors can merge their own changes, even
> seconds after the creation of the PR
> - Require status checks to pass before merging
> - Enable auto-merge to queue merges, instead of waiting for the required
> status checks to pass
> - Use only “Squash merge” to keep history linear and avoid noise like
> “fix previous commit” messages
>
> I realize this introduces a small amount of process overhead (Byzantine
> bureaucracy), but it would bring a few benefits:
>
> - Creates an audit trail for reviews
> Even after merge, comments can be used to record approvals. This also
> lets us search for PRs without comments to identify code that still
> needs review, so we don't need to review each commit 44 times.
>
> - Prevents accidental breakage
> Required checks ensure we don’t merge commits that break the build.
>
> - Improves notifications
> GitHub doesn’t support commit notifications, but it does notify on PRs
> letting contributors follow only the repositories they care about
> instead of filtering `commits@commons`.
>
> Piotr
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Mark,
On 29.10.2025 13:18, Mark Thomas wrote:
> This is a major increase in overhead for trivial fixes.
>
> The Jakarta EE spec projects all use this and it increases the time
> taken for trivial fixes by about an order of magnitude.
>
> It certainly isn't going to encourage me to push trivial fixes I make in
> the Tomcat forks upstream.
My concern with so-called “trivial” fixes is this:
- What is trivial for the author may not be trivial for others. For
example, many native English speakers overlook the complexity of case
folding and localization issues, which can introduce subtle bugs.
- “Trivial” changes can unintentionally include non-trivial
modifications.
- Saying a change is trivial often implies “trust me, this is correct”.
But reviews are not about trust, they are about reducing the
probability of human error. That’s why I review trivial changes with
the same attention as any other.
- Trivial fixes are frequently split into multiple small commits, which
can actually increase cognitive load for reviewers and make changes
easier to overlook.
In practice, “trivial” fixes increase the burden on reviewers if we take
review seriously, and they increase the risk that errors slip through
because they are treated casually.
Personally, I prefer to batch documentation or Javadoc fixes into a
feature branch and review them together before release, especially since
tools (e.g. Copilot) can help verify that no unintended code changes are
included.
If a change is truly trivial, either:
1. it has no real impact on behavior, or
2. it can be reproduced automatically using a tool, which the reviewer
can then use to verify it easily.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by Mark Thomas <ma...@apache.org>.
On 29/10/2025 10:34, Piotr P. Karwasz wrote:
> Hi all,
>
> I’d like to propose enabling branch protection rules for the Commons
> repositories while still preserving our Commit-Then-Review workflow.
>
> Specifically, we could enable the following GitHub settings:
>
> - Require a pull request before merging
> - No required approvals: PR authors can merge their own changes,
even> seconds after the creation of the PR
This is a major increase in overhead for trivial fixes.
The Jakarta EE spec projects all use this and it increases the time
taken for trivial fixes by about an order of magnitude.
It certainly isn't going to encourage me to push trivial fixes I make in
the Tomcat forks upstream.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Gary,
On 29.10.2025 12:30, Gary Gregory wrote:
> Logj4 is has lost involvement from key contributors and is slowly dying on
> the vine IMO due to all of of the hoops and requests it makes on
> contributions.
It’s true that Log4j has lost the active involvement of long-time
contributors like Matt, Ralph, Remko, and yourself, and that has
certainly impacted the project. However, looking at the contribution
timeline [1], I’m not convinced that process changes are the main cause.
RTC was only introduced around April–May 2025, whereas, with the
exception of much-appreciated returns during Log4Shell, many of you had
already reduced your activity years earlier.
I agree that additional checks (API compatibility validation, SAST
tooling, required CI passes, review steps, etc.) can raise the barrier
for *occasional* contributors. But honestly, do you feel that removing
RTC would significantly change contributor engagement? Would you
personally find more time for regular Log4j maintenance today if RTC
weren’t in place, on top of everything you’re already doing in Commons?
For context, Volkan and I had already been applying RTC discipline to
our own contributions long before it became a formal requirement in the
project.
I don’t believe the process itself is the main problem, it’s the
*change* and the need to learn a new workflow from scratch. To give a
comparison: I feel a similar kind of frustration when contributing to
Commons, where I’m expected to follow traditional conventions like
formatting rules and method ordering that aren’t enforced by the build
system.
Piotr
[1] https://github.com/apache/logging-log4j2/graphs/contributors
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by Phil Steitz <ph...@gmail.com>.
On Thu, Oct 30, 2025 at 4:23 AM Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> On Thu, Oct 30, 2025 at 8:38 AM Elric V <el...@melnib.one> wrote:
>
> > > Not doing that is profesional misfeasance.
> >
> > You are aware that open source software does not come with a warranty or
> > any sort of promises about being "fit for purpose" or whatever?
> > Volunteer driven development is not a "professional" undertaking.
> > Doesn't mean we shouldn't all try our best to deliver stuff that works
> > and isn't a leaky bucket, but calling it "misfeasance" is many a bridge
> > too far.
>
> I don't believe we are trying to do our best. In 2025 certain
> principles of secure software engineering are well known and well
> understood, but too often open source projects don't follow them.
> Instead they prioritize developer convenience with known bad practices
> like commit and never review.
>
> You can build any random nitro-fueled, Rube Goldberg drag racer you
> like in your own garage, but it isn't allowed on public roadways. I'm
> increasingly convinced we shouldn't be allowing software that doesn't
> meet basic professional standards on the public Internet.
>
> On the plus side, if software that runs the Internet were required to
> meet minimum standards like code review, then mega-corps that depend
> on these rickety foundations would be highly incentivized to fund
> improvements
Not how it works. Corporate uses grab what works for them. Things that
don't work, fail scans or cause problems eventually get replaced either by
other OSS things that do work or by homegrown things that may or may not
work.
The history of the ASF is the history of the kind of "garage work" that you
disdain. With enough eyeballs and core software value, what starts as
"unprofessional" code turns into very high quality software. We have some
of that in our Commons repos. We have some that needs work. Patches
welcome.
Phil
> so the world no longer depends on the thankless work of
> one random person in Nebraska:
>
> https://xkcd.com/2347/
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Branch protection rules (CTR-style)
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Thu, Oct 30, 2025 at 8:38 AM Elric V <el...@melnib.one> wrote:
> > Not doing that is profesional misfeasance.
>
> You are aware that open source software does not come with a warranty or
> any sort of promises about being "fit for purpose" or whatever?
> Volunteer driven development is not a "professional" undertaking.
> Doesn't mean we shouldn't all try our best to deliver stuff that works
> and isn't a leaky bucket, but calling it "misfeasance" is many a bridge
> too far.
I don't believe we are trying to do our best. In 2025 certain
principles of secure software engineering are well known and well
understood, but too often open source projects don't follow them.
Instead they prioritize developer convenience with known bad practices
like commit and never review.
You can build any random nitro-fueled, Rube Goldberg drag racer you
like in your own garage, but it isn't allowed on public roadways. I'm
increasingly convinced we shouldn't be allowing software that doesn't
meet basic professional standards on the public Internet.
On the plus side, if software that runs the Internet were required to
meet minimum standards like code review, then mega-corps that depend
on these rickety foundations would be highly incentivized to fund
improvements so the world no longer depends on the thankless work of
one random person in Nebraska:
https://xkcd.com/2347/
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by Elric V <el...@melnib.one>.
> holes in open source software deep in the stack, I am astonished that
> people still think it's OK to build and build on top of projects where
> all that's needed to compromise the global infrastructure is to buy or
> steal the GitHub account of one unpaid hobbyist.
No one is forcing anyone to use any of this software. Everyone is free
to audit the repositories and policies and draw their own conclusions.
Any kind of volunteer driven effort has to walk a line between keeping
volunteers happy and producing working results. The addage that many
eyeballs make all bugs shallow still mostly holds true.
> Not doing that is profesional misfeasance.
You are aware that open source software does not come with a warranty or
any sort of promises about being "fit for purpose" or whatever?
Volunteer driven development is not a "professional" undertaking.
Doesn't mean we shouldn't all try our best to deliver stuff that works
and isn't a leaky bucket, but calling it "misfeasance" is many a bridge
too far.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Is the idea to release every class which got or can have a CVE in a
independent jar?
Think we should stick to dependency and consistency modularity, now if you
only want a few methods of stringutils you can copy them, it is what people
not willing commons do generally and it is not bad, now if you need more
you do use commons and accept it as a dependency so I wouldnt fight a CVE
driven approach which can just lead to inconsistent jars and dependency
converge headache when using mixed transitive dependencies - and no maven
nor gradle know how to solve it in several cases ;).
Romain Manni-Bucau
@rmannibucau <https://x.com/rmannibucau> | .NET Blog
<https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old
Blog <http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064>
Javaccino founder (Java/.NET service - contact via linkedin)
Le mer. 29 oct. 2025 à 19:34, Vladimir Sitnikov <si...@gmail.com>
a écrit :
> >commit introduced from merging a user-provided patch. It went through the
> entire review process
>
> As far as I understand, log4shell was effectively caused by "all features
> in a single jar" design.
> If log4j had multiple jar files, then the users could depend only on the
> features they
> use, so the impact of the CVE would be much less.
>
> At the same time, the patch of "allow jndi resolution" could land on its
> own jar, so it would impact a subset of the users only.
> Code review could catch the issue of adding too many features to the single
> jar.
>
> ---
>
> Here's the similar case in commons-lang:
> A recent CVE-2025-48924 relates to ClassUtils while commons-lang is
> often used for its StringUtils only.
>
> If commons-lang was modular like commons-stringutils, commons-classutils,
> and so on,
> then it would be much more secure for the end-users.
>
> Here's a question: what do you think of releasing commons-stringutils.jar
> with StringUtils and Strings clases only?
>
> Frankly, many projects use only StringUtils, yet they suffer from
> accidental CVEs in one of the classes they never use.
>
> Vladimir
>
Re: Branch protection rules (CTR-style)
Posted by Rob Tompkins <ch...@gmail.com>.
> On Oct 29, 2025, at 4:33 PM, sebb <se...@gmail.com> wrote:
>
> On Wed, 29 Oct 2025 at 18:34, Vladimir Sitnikov
> <si...@gmail.com> wrote:
>>
>>> commit introduced from merging a user-provided patch. It went through the
>> entire review process
>>
>> As far as I understand, log4shell was effectively caused by "all features
>> in a single jar" design.
>> If log4j had multiple jar files, then the users could depend only on the
>> features they
>> use, so the impact of the CVE would be much less.
>>
>> At the same time, the patch of "allow jndi resolution" could land on its
>> own jar, so it would impact a subset of the users only.
>> Code review could catch the issue of adding too many features to the single
>> jar.
>>
>> ---
>>
>> Here's the similar case in commons-lang:
>> A recent CVE-2025-48924 relates to ClassUtils while commons-lang is
>> often used for its StringUtils only.
>>
>> If commons-lang was modular like commons-stringutils, commons-classutils,
>> and so on,
>> then it would be much more secure for the end-users.
>>
>> Here's a question: what do you think of releasing commons-stringutils.jar
>> with StringUtils and Strings clases only?
>>
>> Frankly, many projects use only StringUtils, yet they suffer from
>> accidental CVEs in one of the classes they never use.
>
> Surely if they don't use the classes, then they cannot be affected by
> a CVE that applies to such a class?
>
+1, peanuts. Will consider LocaleUtils, And maybe AudioUtils, and maybe SystemUtils….direction unclear.
Cheers,
CRTIII
>> Vladimir
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by sebb <se...@gmail.com>.
On Wed, 29 Oct 2025 at 18:34, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> >commit introduced from merging a user-provided patch. It went through the
> entire review process
>
> As far as I understand, log4shell was effectively caused by "all features
> in a single jar" design.
> If log4j had multiple jar files, then the users could depend only on the
> features they
> use, so the impact of the CVE would be much less.
>
> At the same time, the patch of "allow jndi resolution" could land on its
> own jar, so it would impact a subset of the users only.
> Code review could catch the issue of adding too many features to the single
> jar.
>
> ---
>
> Here's the similar case in commons-lang:
> A recent CVE-2025-48924 relates to ClassUtils while commons-lang is
> often used for its StringUtils only.
>
> If commons-lang was modular like commons-stringutils, commons-classutils,
> and so on,
> then it would be much more secure for the end-users.
>
> Here's a question: what do you think of releasing commons-stringutils.jar
> with StringUtils and Strings clases only?
>
> Frankly, many projects use only StringUtils, yet they suffer from
> accidental CVEs in one of the classes they never use.
Surely if they don't use the classes, then they cannot be affected by
a CVE that applies to such a class?
> Vladimir
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by Vladimir Sitnikov <si...@gmail.com>.
>commit introduced from merging a user-provided patch. It went through the
entire review process
As far as I understand, log4shell was effectively caused by "all features
in a single jar" design.
If log4j had multiple jar files, then the users could depend only on the
features they
use, so the impact of the CVE would be much less.
At the same time, the patch of "allow jndi resolution" could land on its
own jar, so it would impact a subset of the users only.
Code review could catch the issue of adding too many features to the single
jar.
---
Here's the similar case in commons-lang:
A recent CVE-2025-48924 relates to ClassUtils while commons-lang is
often used for its StringUtils only.
If commons-lang was modular like commons-stringutils, commons-classutils,
and so on,
then it would be much more secure for the end-users.
Here's a question: what do you think of releasing commons-stringutils.jar
with StringUtils and Strings clases only?
Frankly, many projects use only StringUtils, yet they suffer from
accidental CVEs in one of the classes they never use.
Vladimir
Re: Branch protection rules (CTR-style)
Posted by Phil Steitz <ph...@gmail.com>.
> On Nov 1, 2025, at 5:05 PM, Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote:
>
> Hi Phil,
>
>> On 1.11.2025 22:29, Phil Steitz wrote:
>> As PMC members it is our collective responsibility to review
>> commits. Having them bundled into PRs doesn't make that any easier,
>> IMO. At the end of the day, the commits are the changes. The best
>> thing we can do - not just here, but in every OSS community - is to
>> get more eyeballs on code. That means building communities.
>> Byzantine processes make that harder.
>
> It’s great to have many eyes on the code, but in practice, that doesn’t
> seem to be happening. Either every commit is flawless, or nobody is
> actually reviewing them, since responses on `commits@` are extremely rare.
>
> The main problem with relying solely on `commits@` is that there’s no
> visibility into whether a commit has already been reviewed (and silently
> approved) or if it hasn’t been looked at at all. In reality, it’s very
> likely that many commits go through without any real review.
Agreed that is a big problem. Self-merged PRs won’t help that.
Phil
>
> Piotr
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Phil,
On 1.11.2025 22:29, Phil Steitz wrote:
> As PMC members it is our collective responsibility to review
> commits. Having them bundled into PRs doesn't make that any easier,
> IMO. At the end of the day, the commits are the changes. The best
> thing we can do - not just here, but in every OSS community - is to
> get more eyeballs on code. That means building communities.
> Byzantine processes make that harder.
It’s great to have many eyes on the code, but in practice, that doesn’t
seem to be happening. Either every commit is flawless, or nobody is
actually reviewing them, since responses on `commits@` are extremely rare.
The main problem with relying solely on `commits@` is that there’s no
visibility into whether a commit has already been reviewed (and silently
approved) or if it hasn’t been looked at at all. In reality, it’s very
likely that many commits go through without any real review.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by Phil Steitz <ph...@gmail.com>.
On Thu, Oct 30, 2025 at 4:39 AM Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> On Wed, Oct 29, 2025 at 4:42 PM Matt SIcker <ma...@musigma.org> wrote:
> >
> > Log4Shell was exploitable via a commit introduced from merging a
> user-provided patch. It went through the entire review process.
>
> Let me try to make my point more clearly. Log4Shell is clear evidence
> that open source dependencies can open massive security holes in
> infrastructure. Anything that risky needs every protection we can
> reasonably enable. Defense in depth is required. CTR is a necessary
> though not sufficient protection. There are many other necessary
> protections, but CTR is absolutely one of them.
>
> We cannot depend on the good judgment and good intentions of single
> individuals. Single software engineers can be and are compromised,
> hacked, and/or bought. CTR significantly raises the bar for injecting
> bad code into the product, both intentionally and unintentionally. It
> is a good and useful practice. There are many attacks on the software
> supply chain, and we need to detect and prevent all of them. I do not
> expect that any one defense will prevent every possible attack, but
> that means we need more than one defense, not that we should settle
> for zero. Code review is one of the broadest and most general defenses
> we have since it applies human intelligence to both known and unknown
> threats. It is the only defense I know that has a chance of detecting
> newly invented supply chain attacks before they're deployed.
>
I think you mean "RTC" but that is not the point. Nobody is saying we
should not be reviewing commits. That's why they are all published. As
PMC members it is our collective responsibility to review commits. Having
them bundled into PRs doesn't make that any easier, IMO. At the end of the
day, the commits are the changes. The best thing we can do - not just
here, but in every OSS community - is to get more eyeballs on code. That
means building communities. Byzantine processes make that harder.
Phil
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Branch protection rules (CTR-style)
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Wed, Oct 29, 2025 at 4:42 PM Matt SIcker <ma...@musigma.org> wrote:
>
> Log4Shell was exploitable via a commit introduced from merging a user-provided patch. It went through the entire review process.
Let me try to make my point more clearly. Log4Shell is clear evidence
that open source dependencies can open massive security holes in
infrastructure. Anything that risky needs every protection we can
reasonably enable. Defense in depth is required. CTR is a necessary
though not sufficient protection. There are many other necessary
protections, but CTR is absolutely one of them.
We cannot depend on the good judgment and good intentions of single
individuals. Single software engineers can be and are compromised,
hacked, and/or bought. CTR significantly raises the bar for injecting
bad code into the product, both intentionally and unintentionally. It
is a good and useful practice. There are many attacks on the software
supply chain, and we need to detect and prevent all of them. I do not
expect that any one defense will prevent every possible attack, but
that means we need more than one defense, not that we should settle
for zero. Code review is one of the broadest and most general defenses
we have since it applies human intelligence to both known and unknown
threats. It is the only defense I know that has a chance of detecting
newly invented supply chain attacks before they're deployed.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by Matt SIcker <ma...@musigma.org>.
Log4Shell was exploitable via a commit introduced from merging a user-provided patch. It went through the entire review process. Had something like CodeQL existed back when that was merged, maybe it would have helped detect the issue, but that would have also required it to not put Log4j is an ignore list of code to skip over. Given the lack of public knowledge of the exploitability of JNDI at the time (July 2013), it would have required an oracle to foresee the vulnerability it introduced. In fact, JNDI exploitability wasn’t publicly known until around 2016 when it was presented in a Blackhat talk about a class of vulnerability discovered from Operation Pawn Storm (likely discovered and weaponized by a Russian government organization based on its targets). Interestingly enough, Log4shell was based on an exploit that initially targeted Java itself in a zero-day. The CVEs published for Java that _might_ correspond to that zero-day are frustratingly vague about what was fixed (see for example [1] and [2]).
Suffice to say, Log4shell was the result of systemic problems in software, and use of RTC or any sort of human review of code history had nothing to do with the situation. While I might agree that code review and static analysis tools and such are useful things, I would strongly disagree that they would have helped prevent Log4shell.
If you’re interested, I have a more detailed writeup about the whole incident. [3]
[1]: https://nvd.nist.gov/vuln/detail/cve-2015-2590
[2]: https://nvd.nist.gov/vuln/detail/cve-2015-4732
[3]: https://musigma.blog/2023/11/10/log4shell-history.html
> On Oct 29, 2025, at 10:40 AM, Elliotte Rusty Harold <el...@ibiblio.org> wrote:
>
> On Wed, Oct 29, 2025 at 11:56 AM Gary Gregory <ga...@gmail.com> wrote:
>
>>>> the vine IMO due to all of of the hoops and requests it makes on
>>>> contributions.
>>>
>>> Log4Shell
>
> I have. I was directly involved in the response to that clusterfuck at
> probably the largest Java shop on the planet. And having been through
> that, and multiple other emergency security response efforts caused by
> holes in open source software deep in the stack, I am astonished that
> people still think it's OK to build and build on top of projects where
> all that's needed to compromise the global infrastructure is to buy or
> steal the GitHub account of one unpaid hobbyist.
>
> No, this is not the only way systems are compromised, but it
> absolutely is one way, and one that's easy to protect against. Not
> doing that is profesional misfeasance.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: Branch protection rules (CTR-style)
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Wed, Oct 29, 2025 at 11:56 AM Gary Gregory <ga...@gmail.com> wrote:
> > > the vine IMO due to all of of the hoops and requests it makes on
> > > contributions.
> >
> > Log4Shell
I have. I was directly involved in the response to that clusterfuck at
probably the largest Java shop on the planet. And having been through
that, and multiple other emergency security response efforts caused by
holes in open source software deep in the stack, I am astonished that
people still think it's OK to build and build on top of projects where
all that's needed to compromise the global infrastructure is to buy or
steal the GitHub account of one unpaid hobbyist.
No, this is not the only way systems are compromised, but it
absolutely is one way, and one that's easy to protect against. Not
doing that is profesional misfeasance.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Oct 29, 2025, 07:44 Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> On Wed, Oct 29, 2025 at 11:32 AM Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > -1, I like to keep it simple.
> >
> > Logj4 is has lost involvement from key contributors and is slowly dying
> on
> > the vine IMO due to all of of the hoops and requests it makes on
> > contributions.
>
> Log4Shell
>
Please study Log4Shell, this would not have prevented it.
Gary
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Branch protection rules (CTR-style)
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Wed, Oct 29, 2025 at 11:32 AM Gary Gregory <ga...@gmail.com> wrote:
>
> -1, I like to keep it simple.
>
> Logj4 is has lost involvement from key contributors and is slowly dying on
> the vine IMO due to all of of the hoops and requests it makes on
> contributions.
Log4Shell
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by Emmanuel Bourg <eb...@apache.org>.
On 01/11/2025 22:16, Phil Steitz wrote:
> +1 to Gary's -1.
Same for me, let's keep things simple, Commons has enough processes.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Branch protection rules (CTR-style)
Posted by Phil Steitz <ph...@gmail.com>.
On Wed, Oct 29, 2025 at 4:32 AM Gary Gregory <ga...@gmail.com> wrote:
> -1, I like to keep it simple.
>
+1 to Gary's -1. Here is a thought experiment: Imagine how much "better"
our software would be if we forced ggregory and markt (the ones who have
said -1 to this proposal) to add the proposed steps to their workflows.
>
> Logj4 is has lost involvement from key contributors and is slowly dying on
> the vine IMO due to all of of the hoops and requests it makes on
> contributions.
>
> > Enable auto-merge
> That one takes the cake, nothing should ever be auto-merged.
>
Ridiculous. Please no, especially not the bot slop.
>
> Gary
>
>
> On Wed, Oct 29, 2025, 06:35 Piotr P. Karwasz <pi...@mailing.copernik.eu>
> wrote:
>
> > Hi all,
> >
> > I’d like to propose enabling branch protection rules for the Commons
> > repositories while still preserving our Commit-Then-Review workflow.
> >
> > Specifically, we could enable the following GitHub settings:
> >
> > - Require a pull request before merging
> > - No required approvals: PR authors can merge their own changes, even
> > seconds after the creation of the PR
> > - Require status checks to pass before merging
> > - Enable auto-merge to queue merges, instead of waiting for the required
> > status checks to pass
> > - Use only “Squash merge” to keep history linear and avoid noise like
> > “fix previous commit” messages
> >
> > I realize this introduces a small amount of process overhead (Byzantine
> > bureaucracy), but it would bring a few benefits:
> >
> > - Creates an audit trail for reviews
> > Even after merge, comments can be used to record approvals. This also
> > lets us search for PRs without comments to identify code that still
> > needs review, so we don't need to review each commit 44 times.
> >
> > - Prevents accidental breakage
> > Required checks ensure we don’t merge commits that break the build.
> >
> > - Improves notifications
> > GitHub doesn’t support commit notifications, but it does notify on PRs
> > letting contributors follow only the repositories they care about
> > instead of filtering `commits@commons`.
> >
> > Piotr
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: Branch protection rules (CTR-style)
Posted by Mike Drob <md...@apache.org>.
> That one takes the cake, nothing should ever be auto-merged.
That's not how GitHub auto-merge works. It's "auto-merge **when ready**".
And it has to be opted into for a given PR.
The definition of "when ready" depends on repository rules, typically based
on receiving a sufficient number of reviews from maintainers and passing
whatever CI checks.
Re: Branch protection rules (CTR-style)
Posted by Gary Gregory <ga...@gmail.com>.
-1, I like to keep it simple.
Logj4 is has lost involvement from key contributors and is slowly dying on
the vine IMO due to all of of the hoops and requests it makes on
contributions.
> Enable auto-merge
That one takes the cake, nothing should ever be auto-merged.
Gary
On Wed, Oct 29, 2025, 06:35 Piotr P. Karwasz <pi...@mailing.copernik.eu>
wrote:
> Hi all,
>
> I’d like to propose enabling branch protection rules for the Commons
> repositories while still preserving our Commit-Then-Review workflow.
>
> Specifically, we could enable the following GitHub settings:
>
> - Require a pull request before merging
> - No required approvals: PR authors can merge their own changes, even
> seconds after the creation of the PR
> - Require status checks to pass before merging
> - Enable auto-merge to queue merges, instead of waiting for the required
> status checks to pass
> - Use only “Squash merge” to keep history linear and avoid noise like
> “fix previous commit” messages
>
> I realize this introduces a small amount of process overhead (Byzantine
> bureaucracy), but it would bring a few benefits:
>
> - Creates an audit trail for reviews
> Even after merge, comments can be used to record approvals. This also
> lets us search for PRs without comments to identify code that still
> needs review, so we don't need to review each commit 44 times.
>
> - Prevents accidental breakage
> Required checks ensure we don’t merge commits that break the build.
>
> - Improves notifications
> GitHub doesn’t support commit notifications, but it does notify on PRs
> letting contributors follow only the repositories they care about
> instead of filtering `commits@commons`.
>
> Piotr
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>