Special note regarding Spring Boot 3 ... in README

[Jeffrey Walton]

Hi Everyone,

Regarding the README and the "Special note regarding Spring Boot
3...", I think it's about time to shit or get off the pot. The issue
has been discussed enough. You are now into diminishing returns.

Here's how I would handle it. I follow the three C's: Complaint,
Cause, Correction.

* The Complaint is: ESAPI 2.5.x is not compatible with Spring Boot 3,
Spring 6, Tomcat 10, the latest version of Jetty, etc.

* The Cause is: Package namespaces changed, and ESAPI 2.5.x uses the
old namespaces. ESAPI does not want to drop support for existing
installations.

* The Correction is: Run the conversion script to fix the namespace
and class references.

I would then provide a Unix shell script that uses sed and awk to fix
the namespace and class references. Or you could provide a patch as a
diff, but it is less robust since the source code is going to slowly
change over time.

Once you give users a path forward, you won't have to worry about,
"Therefore PLEASE STOP sending us emails and/or creating GitHub issues
regarding this!" Until you give users the Correction, it is going to
fill up your mailing list and bug tracker.

Jeff

[Kevin W. Wall]

Jeff,

On Sun, Jun 18, 2023 at 1:29 PM Jeffrey Walton <nolo...@gmail.com> wrote:

Hi Everyone,

Regarding the README and the "Special note regarding Spring Boot
3...", I think it's about time to shit or get off the pot. The issue
has been discussed enough. You are now into diminishing returns.

Here's how I would handle it. I follow the three C's: Complaint,
Cause, Correction.

* The Complaint is: ESAPI 2.5.x is not compatible with Spring Boot 3,
Spring 6, Tomcat 10, the latest version of Jetty, etc.

Just for the record, I think the complaints would be a LOT LOUDER if we simply stopped supporting a version of ESAP 2.x that just abandons the javax.servlet namespace. You may not think so, but from what I observe at my day job, a large part of the Java community is not even aware that this problem is lurking let alone starting to deal with it. The community still using javax.servlet is still significantly larger than the one using jakarta.servlet.

* The Cause is: Package namespaces changed, and ESAPI 2.5.x uses the
old namespaces. ESAPI does not want to drop support for existing
installations.

It's more than that.There are at least 1 direct dependencies (e.g., Apache Commons FileUpload) that still uses javax.servlet. They have a 2.0 release planned that will use jakarta.servlet namespace, but that would also change the FileUpload namespace from org.apache.commons.fileupload to org.apache.commons.fileupload2 which would cause further changes in ESAPI. Last I heard, there was only a 2.0-SNAPSHOT version available for FileUpload and I'm not comfortable with release versions of ESAPI that have SNAPSHOT versions of dependencies. (It's not even an RC version yet.)

That said, there may be others like this, including in transitive dependencies. Hence the reason for the caution.

One alternative is to deliver an uber jar for the Jakarta version of ESAPI, what would include all the direct and transitive dependencies and not just the ESAPI byte code. That's what the Maven 'shade' plugin (org.apache.maven.plugins:maven-shade-plugin) is supposed to do. But it seems to me, if that is the solution every ones, then it's better for the client applications using ESAPI to do that themselves so they can have control over what version dependencies gets backed in (since excluding some dependencies and telling Maven to use different problem really doesn't work with uber jars. That's one of the major problems with them.

* The Correction is: Run the conversion script to fix the namespace
and class references.

Just don't think that it's a simple conversion of s/javax.servlet/jakarta.servlet/ to the ESAPI code. There at least needs to be (or, should be) some POM changes too, to address changes in dependencies, and almost certainly artifactIDd that makes up the GAV for Maven Central needs to change (probably to 'esapi-jakarta', unless we want to change the namespace for ESAPI for Jakarta as well, in which case 'esapi_jakarata' problem makes more sense, since '-' is not legal in package namespaces). I figure there are companies that will need to use both versions at once. If they use something like JFrog's Artifactory, they would need to be able to distinguish the names of the different jars, and by default, artifactId is used as the base name for the jar file. So, for example, we would have something like:

• esapi-2.6.1.0.jar, which would be for the older javax.namespace
• esapi-jakarta-2.6.1.0.jar, which would be the corresponding version for the jakarta.namespace.

Of course, if we change the name in Maven Central to that (because, trust me, folks will not just be content to download if from the 'Releases' link on GitHub), for developer sanity purposes related to consistency and in case your application pulls in a dependency that uses an old version of ESAPI (e.g., OpenSAML or Shibboleth) then you can support that with having to do shading.

In a nutshell, the big picture is more complicated than it first appears.

I would then provide a Unix shell script that uses sed and awk to fix
the namespace and class references. Or you could provide a patch as a
diff, but it is less robust since the source code is going to slowly
change over time.

My thought was to make something like that a part of the build process in Maven and keep them in sync that way. I think there are Maven plugins that support execution of Bash scripting, but I'm just not that good with Maven and with my son recently moving to Australia, I really haven't had a lot of time to deal with it.

Once you give users a path forward, you won't have to worry about,
"Therefore PLEASE STOP sending us emails and/or creating GitHub issues
regarding this!" Until you give users the Correction, it is going to
fill up your mailing list and bug tracker.

Well, it has slowed down the rate a bit. Especially all the individual emails I used to get, so it mostly has had the intended effect. And if we mess this up, there will be much bigger problems.

There has been a person who is rolling out a fork. E.g., see

https://github.com/rjunqueira/esapi-java-legacy

but I haven't kept up with how it's progressing. I am watching that repo for activity though, if only to learn any potential pitfalls.

I will say at this point though--and I've discussed this with both Matt and Jeremiah and we're all in agreement--that when we finally get started on ESAPI 3.x, we only intend to support JakartaEE and not JavaEE. But our namespace will change as well (probably to org.owasp.esapi3) because there will be major interface changes, so in comparison, that is not going to be the major issue.

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

[Olivier Jaquemet]

Hi,

A quick off-topic response to one of Kevin's points.

On Sun, 18 Jun 2023 at 23:50, Kevin W. Wall <kevin....@gmail.com> wrote:

[...]

One alternative is to deliver an uber jar for the Jakarta version of ESAPI, what would include all the direct and transitive dependencies and not just the ESAPI byte code. That's what the Maven 'shade' plugin (org.apache.maven.plugins:maven-shade-plugin) is supposed to do. But it seems to me, if that is the solution every ones, then it's better for the client applications using ESAPI to do that themselves so they can have control over what version dependencies gets backed in (since excluding some dependencies and telling Maven to use different problem really doesn't work with uber jars. That's one of the major problems with them.

Please, if you are a library maintainer, be it for ESAPI, or any other library, do not use solutions like maven-shade-plugin / jarjar. 

As you clearly indicated, Kevin, hiding transitive dependencies with such tools is a major issue for users of a library as it completely prevents proper dependencies' management.

It prevents security check (using tools like snyk/owasp depencency checker, github securit check)

It prevents explicit choice by the user to use one version or another of the transitive libraries.

I recently had to fork a library to work around a similar issue. I would have preferred to staty with the official distribution !

Olivier

[Kevin W. Wall]

Olivier,

I don't really think that is off-topic. And if we did this, it probably would only be a temporary solution that people could at least compile against. And I figured, with a bit of manual work the jarjar could be used to extract ONLY the ESAPI components, that match org/owasp/esapi and repackage that in something like an esapi-jakarta-<version>.jar file. I don't like it at all, but it would provide a manageable solution even though it would be somewhat of a PITA to manage. If I can figure out a way to call an arbitrary Bash script with some Maven plugin in the context of a specific Maven goal, I think I can do better though. I just haven't figured out how to do that yet.

-kevin

[Matt Seil]

It’s worth noting that invoking sed/awk/bash would remove the current ability to perform cross-platform compilation and release. 

Sent from my iPhone

On Jun 19, 2023, at 18:03, Kevin W. Wall <kevin....@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "ESAPI Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to esapi-project-u...@owasp.org.
To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/esapi-project-users/CAOPE6Pg_A3WcBaFr1a8ur74YOFhVOhCRx5yigcooD3H6QaC%2B4g%40mail.gmail.com.