On Tue, 2026-09-08 at 11:56 +0100, Billy McCarthy via dev wrote: > Hello all, > > I'm writing to add a downstream consumer's perspective to this > thread, having > been pointed here by Arnout Engelen after I raised the same question > with the > ASF security team - apologies for arriving two months late to the > discussion. > > First, thank you for the clear answers already given here: that the > CVE is > scoped to the 5.x package and Maven coordinates, and that while the > 4.x line > sets no header limits by default, users can configure > MessageConstraints more > conservatively. We will be applying that configuration on our side, > and I > appreciate that guidance being on the public record. > > To explain why 4.x still matters to us specifically: Atlassian's > newer product > versions have already completed the migration to httpcore5, so this > is not a > case of us avoiding that work. However, we have support commitments > on > already-released product versions that run until 2028-02-03, and > those lines > carry binary-compatibility guarantees for a large third-party plugin > ecosystem. > Swapping the HTTP stack from 4.x to 5.x within a maintenance line > would break > those guarantees, so upgrading is not available to us on the branches > in > question - we are obliged to keep shipping httpcore 4.4.x for roughly > the next > 18 months. > > I want to be clear that I'm not filing a new vulnerability report, > and I'm > conscious of the volunteer cost involved in maintaining an EOL line. > With that > in mind, there are only two paths open to us, and I'd be grateful for > your view > on which you'd prefer: > > 1. A public release from the 4.4.x branch containing conservative > default > limits. I note the branch is already at 4.4.17-SNAPSHOT. If the > PMC were > open to this, we would do the legwork - prepare the patch and a > regression > test, and help with any release-candidate testing - so the > remaining cost to > you is review and the release mechanics. We are not asking for an > expedited > or out-of-cycle release; whenever suited the project would be > fine. > > 2. If no release will be made from 4.4.x, then we will need to > maintain our own > fork of httpcore4 for the remainder of our support window. We > would much > rather not - a long-lived security-relevant fork is a significant > ongoing > cost for us and it fragments the ecosystem
Believe it or not, having to maintain a branch that is outdated and effectively dead is also a significant cost for us as a project. And what do we have compared to Atlassian? Presently we have one and a half active developers working on a purely volunteer basis. The problem is not porting the fix or preparing a patch. The problem is the formal ASF release process costs us collectively a great deal of resources that could have been spent otherwise, like working on the current stable branch or new features. I will try to get around to doing a new release off the 4.4.x branch but it may take a certain while. > - but if that's the outcome, we'd > like to do it in a way you're comfortable with. Specifically, we > would > publish under our own Maven coordinates and drop Apache branding > in line with > ASF trademark policy, and we'd welcome any guidance on naming or > anything > else you'd want us to observe so that downstream users aren't > confused about > what is and isn't an Apache artifact. > As far as I know commercial companies routinely publish patched versions of ASF artifacts with the same artifact coordinates but with a custom version qualifier into their private artifact repositories: https://maven.repository.redhat.com/ga/commons-io/commons-io/ I presume this is permissible as long as there is no change of the original license and limited in scope to bug fixes only. Oleg > Either answer is genuinely useful to us - a clear "no release will > happen" lets > us plan the fork with our eyes open, which is much better than > uncertainty. > > Thanks for your time, and for the many years of work on > HttpComponents. > > Billy > DC Platform Team, Atlassian > > --------------------------------------------------------------------- > 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]
