Announcement about changes to minimal supported JRE for ESAPI 2.x

[Kevin W. Wall]

Background:

Way back on May 3rd of this year, I cross-posted an email to both of the ESAPI mailing lists (i.e., Google groups).

That email was titled

ESAPI support for Java 7 -- how important is it to you?

There was exactly only a single reply and that was from someone who said that their company still needed support for Java 7. Otherwise, the crickets were deafening. On May 12th, I responded to that single reply with this

I can't promise how long we'll keep on supporting it [edited -- i.e., Java 7]. Certainly if a serious vulnerability comes up that has an exploitable path in ESAPI and the only patch is for dependency only supporting Java 8, we could be forced into a predicament where the only choice is to upgrade to Jave 8 and patch or decide to live with it (assuming no reasonable workaround is viable).

I had originally planned on supporting Java 7 up through when standard support for Java 8 ends (which I was thinking was April or May next year), but if this fire drill happens again we are prepared to move that transition date up to Jan 1, 2022. All of you ESAPI users should get off Java 7 ASAP because we are not going to be able to support Java 7 indefinitely.

Continuing to support Java 7 as a target is becoming problematic. We are currently stuck on Apache Commons IO 2.6 because version 2.7 and later requires Java 8. Thus we can't upgrade past 2.6. Unfortunately, that potentially means future exposure to CVE-2021-29425. We don't use FileNameUtils, but we could easily accidentally forget about it and it seems unlikely that this will be the last vulnerability discovered in Apache Commons IO 2.6. (There's a full write up of the analysis in "Security Bulletin #5".) However, doing such analysis and writing up security bulletins every time something like Snyk or Dependabot or OWASP Dependency Check every time some new unpatchable CVE is announced is time-consuming as well as self-defeating as far as developer's confidence in ESAPI goes. In addition, this situation is likely to only get worse as more and more libraries that ESAPI either directly or indirectly depends on abandon Java 7.

I believe even the free support for the Oracle version of OpenJDK 8 has already ended, although there are others such as Amazon, Red Hat, and maybe others organizations whom I still think support OpenJDK 8 for free. But regardless, it is extremely painful for us to have to keep tooling (e.g., an actual Java 7 JDK) on our laptops to continue to support Java 7. Indeed, it is going to start to be difficult to support ESAPI 2 even on Java 8 as the minimal JDK given that Java 8 has reached its EOL (or will, March 31, 2022, as per https://endoflife.date/java). But the next LTS release of Java after Java 8 is Java 11 and that ends in Sept 30, 2023 so it seems pointless to force that big of a jump now. (I know moving to Java 11 requires some pom changes, so even we are not ready to do that yet.)

Announcement:

All which brings me to my announcement. I have made an executive decision that the first ESAPI release that we deploy in 2021 will require Java 8 or later. We will no longer actively support Java 7. (So apologies to the only person who responded. Had there been a groundswell of support for people stating "we absolutely need Java 7 supported", I might have reconsidered, but when only 1 or 2 people speak up, that's not enough.

As a compromise, I will try to do one final patch release this year on Java 7 (tentatively, that will be 2.2.4.0), and then the next release when we update ESAPI 2.x to require Java 8, we will tentatively name 2.3.0.0.

So, that's my big announcement. Please don't blame either Matt or Jeremiah for this though as it is not their doing. If you need to burn effigies or create voodoo dolls because you think I've let you down, you can grab my image from https://avatars.githubusercontent.com/u/1959835?v=4. But for the rest of you, thanks for using ESAPI.

-kevin

--

Blog: https://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall | OWASP ESAPI Project co-lead
NSA: All your crypto bit are belong to us.