Re: Release Process w/ CVE fixes

[Rick Hillegas]

Thanks for that extra context, Frank.

An official Derby release must be built by a Derby committer and vetted 
by the Derby community. You cannot drive this process.


What you can do is build the Derby 10.15 jar files and deploy them on 
Maven Central yourself. For this, you have to PGP-sign the artifacts and 
publish your public key, according to 
https://maven.apache.org/repository/guide-central-repository-upload.html 
I don't know you convince the Black Duck scanner that your artifacts are 
certified CVE-free.


On 12/9/24 12:02 PM, Frank Domina wrote:

Rick,

Thank you for such a prompt and thoughtful reply. It is unfortunate about 
nobody managing those “older” releases, because “older” does not mean unused, 
and I’d bet that there are more Derby deployments on older JREs than on 21. 
Also, my immediate question was about that particular CVE, but was also generic 
in the case of any future security vulnerabilities.

Thankfully, our product doesn’t actually use LDAP authentication, so we are not 
vulnerable to that particular CVE, which is why I waited a year before 
inquiring about the lack of the older branch releases. However, having high- or 
critical-level vulnerabilities in any of the OSS  jars we deploy raises urgent 
red flags to some of our bigger customers who run Black Duck (or other) 
scanners against their servers themselves. Of course for this CVE, we explain 
that we’re not vulnerable, but that message isn’t always easily accepted or is 
forgotten and we get asked again periodically down the road, and therefore our 
preference is to upgrade OSS components with vulnerabilities to fixed versions 
whether or not our product is susceptible.

The problem with us building and deploying the 10.15 (or 10.14) as you 
mentioned is that since it’s not a public release out on Maven Central, 
security scanners won’t find an exact signature match of the jar (would likely 
show the previous release “with modifications”) and historically that has meant 
that the vulnerability is still reported since the scanner doesn’t know that it 
has been resolved.

As far as java 21 goes, that’s not even on our roadmap. Getting to Java 17 is a 
goal, but a difficult / time-consuming goal that has no target date. The problem is 
the major changes and removals between 11 and 17, especially as it relates to 
reflection and having to ditch XStream. Our newer products are on Java 17 (one 
might be on 21), but this particular product is large & complex and has existed 
for well over a decade. Just getting from Java 8 to 11 was a big undertaking, and 
11 to 17 has much bigger obstacles, with bigger destabilization risks.

Is “manage releases on those older code branches” difficult? I’ve not 
personally done any work in the open-source community, but I wouldn’t mind 
getting my feet wet, especially if it’s in an area without time pressure (I do 
have a “day job” after all 😉).

Best regards,
Frank


From: Rick Hillegas 
Sent: Monday, December 9, 2024 1:20 PM
To: derby-dev@db.apache.org; Frank Domina 
Subject: Re: Release Process w/ CVE fixes

No committer has volunteered to manage releases on those older code branches. 
For your Java11-based product, you will need to build jars from the head of the 
10.15 branch.

Instructions for downloading the head of the 10.15 branch can be found here: 
https://cwiki.apache.org/confluence/display/DERBY/ForNewDevelopers#ForNewDevelopers-CheckOut,BuildtheCodeandruntheTests
 The actual subversion command you need is

   svn co 
https://svn.apache.org/repos/asf/db/derby/code/<https://svn.apache.org/repos/asf/db/derby/code/trunk>branches/10.15
 derby

Instructions for building the head of the 10.15 branch can be found here: 
https://svn.apache.org/repos/asf/db/derby/code/branches/10.15/BUILDING.html

The CVE in question affects applications which use Derby's LDAP-based authentication 
mechanism. We don't get a lot of feedback about which authentication mechanisms are used 
in production. Does your application rely on Derby's LDAP-based authentication? If not, 
you could insulate your application from this CVE by placing your application under 
Derby's NATIVE authentication mechanism. See the topic called "Configuring NATIVE 
authentication" in the 10.15 security guide: 
https://db.apache.org/derby/docs/10.15/security/index.html

Hope this helps,
-Rick

On 12/9/24 8:06 AM, Frank Domina wrote:

Hello. I'm new to the group, so I hope this is the appropriate place to ask 
this.



Over a year ago, v10.17.1.0 was released, which contained a fix for an LDAP injection 
vulnerability (CVE-2022-46337 / BDSA-2022-4287). The Jira ticket is 
DERBY-7147<https://issues.apache.org/jira/browse/DERBY-7147><https://issues.apache.org/jira/browse/DERBY-7147>,
 which indicates that the fix also went in v10.14.3, v10.15.2.1, and v10.16.1.2. A cursory 
look at the code seems to confirm this. However, it has been well over a year since the 

RE: Release Process w/ CVE fixes

[Frank Domina]

Rick,

Thank you for such a prompt and thoughtful reply. It is unfortunate about 
nobody managing those “older” releases, because “older” does not mean unused, 
and I’d bet that there are more Derby deployments on older JREs than on 21. 
Also, my immediate question was about that particular CVE, but was also generic 
in the case of any future security vulnerabilities.

Thankfully, our product doesn’t actually use LDAP authentication, so we are not 
vulnerable to that particular CVE, which is why I waited a year before 
inquiring about the lack of the older branch releases. However, having high- or 
critical-level vulnerabilities in any of the OSS  jars we deploy raises urgent 
red flags to some of our bigger customers who run Black Duck (or other) 
scanners against their servers themselves. Of course for this CVE, we explain 
that we’re not vulnerable, but that message isn’t always easily accepted or is 
forgotten and we get asked again periodically down the road, and therefore our 
preference is to upgrade OSS components with vulnerabilities to fixed versions 
whether or not our product is susceptible.

The problem with us building and deploying the 10.15 (or 10.14) as you 
mentioned is that since it’s not a public release out on Maven Central, 
security scanners won’t find an exact signature match of the jar (would likely 
show the previous release “with modifications”) and historically that has meant 
that the vulnerability is still reported since the scanner doesn’t know that it 
has been resolved.

As far as java 21 goes, that’s not even on our roadmap. Getting to Java 17 is a 
goal, but a difficult / time-consuming goal that has no target date. The 
problem is the major changes and removals between 11 and 17, especially as it 
relates to reflection and having to ditch XStream. Our newer products are on 
Java 17 (one might be on 21), but this particular product is large & complex 
and has existed for well over a decade. Just getting from Java 8 to 11 was a 
big undertaking, and 11 to 17 has much bigger obstacles, with bigger 
destabilization risks.

Is “manage releases on those older code branches” difficult? I’ve not 
personally done any work in the open-source community, but I wouldn’t mind 
getting my feet wet, especially if it’s in an area without time pressure (I do 
have a “day job” after all 😉).

Best regards,
Frank


From: Rick Hillegas 
Sent: Monday, December 9, 2024 1:20 PM
To: derby-dev@db.apache.org; Frank Domina 
Subject: Re: Release Process w/ CVE fixes

No committer has volunteered to manage releases on those older code branches. 
For your Java11-based product, you will need to build jars from the head of the 
10.15 branch.

Instructions for downloading the head of the 10.15 branch can be found here: 
https://cwiki.apache.org/confluence/display/DERBY/ForNewDevelopers#ForNewDevelopers-CheckOut,BuildtheCodeandruntheTests
 The actual subversion command you need is

  svn co 
https://svn.apache.org/repos/asf/db/derby/code/<https://svn.apache.org/repos/asf/db/derby/code/trunk>branches/10.15
 derby

Instructions for building the head of the 10.15 branch can be found here: 
https://svn.apache.org/repos/asf/db/derby/code/branches/10.15/BUILDING.html

The CVE in question affects applications which use Derby's LDAP-based 
authentication mechanism. We don't get a lot of feedback about which 
authentication mechanisms are used in production. Does your application rely on 
Derby's LDAP-based authentication? If not, you could insulate your application 
from this CVE by placing your application under Derby's NATIVE authentication 
mechanism. See the topic called "Configuring NATIVE authentication" in the 
10.15 security guide: https://db.apache.org/derby/docs/10.15/security/index.html

Hope this helps,
-Rick

On 12/9/24 8:06 AM, Frank Domina wrote:

Hello. I'm new to the group, so I hope this is the appropriate place to ask 
this.



Over a year ago, v10.17.1.0 was released, which contained a fix for an LDAP 
injection vulnerability (CVE-2022-46337 / BDSA-2022-4287). The Jira ticket is 
DERBY-7147<https://issues.apache.org/jira/browse/DERBY-7147><https://issues.apache.org/jira/browse/DERBY-7147>,
 which indicates that the fix also went in v10.14.3, v10.15.2.1, and 
v10.16.1.2. A cursory look at the code seems to confirm this. However, it has 
been well over a year since the fix was made, yet the only version that was 
ever released was v10.17.1.0.



This effectively has stranded anyone not running Java 21 or later, and there is 
a lot of software out there that is still using Java 17, 11 and even 8, with 
those JREs being supported for another 6-8 years. In fact, Java 11's support 
extends a year beyond 21's, per 
https://www.azul.com/products/azul-support-roadmap/. We have a product that, 
for multiple externally-controlled reasons, is stuck at Java 11 for the 
foreseeable future, and an older one that EOL's 12/2025 that is s

Re: Release Process w/ CVE fixes

[Rick Hillegas]

No committer has volunteered to manage releases on those older code 
branches. For your Java11-based product, you will need to build jars 
from the head of the 10.15 branch.


Instructions for downloading the head of the 10.15 branch can be found 
here: 
https://cwiki.apache.org/confluence/display/DERBY/ForNewDevelopers#ForNewDevelopers-CheckOut,BuildtheCodeandruntheTests 
The actual subversion command you need is


  svn co https://svn.apache.org/repos/asf/db/derby/code/ 
branches/10.15 derby


Instructions for building the head of the 10.15 branch can be found 
here: 
https://svn.apache.org/repos/asf/db/derby/code/branches/10.15/BUILDING.html


The CVE in question affects applications which use Derby's LDAP-based 
authentication mechanism. We don't get a lot of feedback about which 
authentication mechanisms are used in production. Does your application 
rely on Derby's LDAP-based authentication? If not, you could insulate 
your application from this CVE by placing your application under Derby's 
NATIVE authentication mechanism. See the topic called "Configuring 
NATIVE authentication" in the 10.15 security guide: 
https://db.apache.org/derby/docs/10.15/security/index.html


Hope this helps,
-Rick

On 12/9/24 8:06 AM, Frank Domina wrote:

Hello. I'm new to the group, so I hope this is the appropriate place to ask 
this.

Over a year ago, v10.17.1.0 was released, which contained a fix for an LDAP injection 
vulnerability (CVE-2022-46337 / BDSA-2022-4287). The Jira ticket is 
DERBY-7147, which indicates 
that the fix also went in v10.14.3, v10.15.2.1, and v10.16.1.2. A cursory look at the 
code seems to confirm this. However, it has been well over a year since the fix was 
made, yet the only version that was ever released was v10.17.1.0.

This effectively has stranded anyone not running Java 21 or later, and there is 
a lot of software out there that is still using Java 17, 11 and even 8, with 
those JREs being supported for another 6-8 years. In fact, Java 11's support 
extends a year beyond 21's, 
perhttps://www.azul.com/products/azul-support-roadmap/. We have a product that, 
for multiple externally-controlled reasons, is stuck at Java 11 for the 
foreseeable future, and an older one that EOL's 12/2025 that is still using 
Java 8. I can't imagine we're alone in either of those boats.

What does it take to get Derby v10.14.3, v10.15.2.1, and v10.16.1.2 (containing 
that CVE fix) publicly released?

Best regards,
Frank Domina