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>, 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
