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 <rick.hille...@gmail.com>
Sent: Monday, December 9, 2024 1:20 PM
To: derby-dev@db.apache.org; Frank Domina <frank.dom...@nice.com>
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 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
