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 - 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. 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]
