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
