I'm around to help if need be, at the very least I can validate an RC against other FOSS projects.
Gary On Tue, Sep 8, 2026 at 4:10 PM Oleg Kalnichevski <[email protected]> wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
