[
https://issues.apache.org/jira/browse/CXF-8328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181702#comment-17181702
]
Robert Schaft edited comment on CXF-8328 at 8/21/20, 8:11 AM:
--------------------------------------------------------------
{quote}Why stop at 3.1.x, why not 3.0.x, 2.7.x, etc etc.
{quote}
Because TomEE is one of your major downstream users and it is also an Apache
project.
Was TomEE team aware of the support end for individual branches? Are there long
term supported branches of CXF?
This looks like there is no coordination between the Apache Projects TomEE and
CXF in regards of Long Term Support. The term might not sound relevant for a
mere library. But for TomEE it is.
Of course you could blame them, "Why do you promise a supported version, when
you rely on libraries that are out of support?". But I doubt, that they could
ensure that, when the decision for one or the other library was made. There is
unfortunately no standard for marking end of support for branches.
Regarding your suggestions:
* Upgrade to newer CXF Version doesn't look like an Option for TomEE because
of API changes.
* I don't see how forking could be an Option for TomEE, because other software
using tomEE might rely on tomee shipping CXF, not a CXF-tomee. And the maven
build chain uses the CXF from your project delivered to maven central. But I am
overseeing something.
was (Author: robert.schaft):
{quote}Why stop at 3.1.x, why not 3.0.x, 2.7.x, etc etc.
{quote}
Because TomEE is one of your major downstream users and it is also an Apache
project.
Was TomEE team aware of the support end for individual branches? Are there long
term supported branches of CXF?
This looks like there is no coordination between the Apache Projects TomEE and
CXF in regards of Long Term Support. The term might not sound relevant for a
mere library. But for TomEE it is.
Of course you could blame them, "Why do you promise a supported version, when
you rely on libraries that are out of support?". But I doubt, that they ensured
that, when the decision for one or the other library was made.
Regarding your suggestions:
* Upgrade to newer CXF Version doesn't look like an Option for TomEE because
of API changes.
* I don't see how forking could be an Option for TomEE, because other software
using tomEE might rely on tomee shipping CXF, not a CXF-tomee. And the maven
build chain uses the CXF from your project delivered to maven central. But I am
overseeing something.
> CVE-2019-12406 not fixed in 3.1 branch
> --------------------------------------
>
> Key: CXF-8328
> URL: https://issues.apache.org/jira/browse/CXF-8328
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.1.18
> Reporter: Robert Schaft
> Priority: Major
> Labels: CVE
>
> CVE-2019-12406 is currently the only open relevant Cybersecurity issue in
> TomEE 7.x (see TOMEE-2876) according to known vulnerability database.
> TomEE 7.x is claiming to be a stable supported version. But it depends on CXF
> 3.1, which has at least the vulnerability reported in
> [CVE-2019-12406|http://cxf.apache.org/security-advisories.data/CVE-2019-12406.txt.asc].
> As I understood, it can't be fixed in TomEE without following the API change
> of CXF 3.2, which the TomEE team is reluctant to do.
> From the distant perspective, a backport to CXF 3.1 of the
> attachment-max-count feature doesn't look complicated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
