Consider upgrading to WSS4J 3.0.0. about spring-ws HOT 9 OPEN

I should have explained in more depth why I think spring-ws should pick up wss4j 3.0.0, even at the cost of a new minor release.

The main reason I still think this would justify a new minor release line of spring-ws (4.1.x) is to complete the JakartaEE migration. Ideally, wss4j 3.0.0 would have have been part of spring-ws 4.0.x, probably it was a near miss. Now that it is available upgrade spring-ws and take advantage of the upcoming spring-boot minor release in order to pick it up. Many projects have yet to migrate to spring-boot 3 / JakartaEE9+. Possible future issues like #1360 could be avoided in the first place.

Another reason is plain dependency management. Wss4j 2.4.1 has transitive dependencies which have serious security issues (BouncyCastle, for example). In the meantime, wss4j 2.4.2 and 3.0.2 have been released. It would be great value for spring-ws users to get regular dependency updates by simply using a current spring-boot parent or spring-boot-dependencies bom.

from spring-ws.

At the minimum, could you upgrade to wss4j 2.4.3? 2.4.1 brings in org.bouncycastle:bcprov-jdk15on with at least 5 vulnerabilities. 2.4.3 already uses the newer org.bouncycastle:bcprov-jdk18on

from spring-ws.

Hi @gregturn, afaik spring-boot 3.2 release is scheduled for this autumn - imo this issue alone would justify a 4.1.0 release. I would really like to see spring-boot 3.2 dependency management picking this up.

from spring-ws.

For starters, I have tested Spring WS against WSS4j 3.0.0, and it seems to work with no changes. As for creating another Spring WS release version, I'm not yet convinced we need that. A single 3rd party dependency's major feature upgrade isn't quite enough for that.

And to clarify, Spring Boot 3.2 is currently based on Spring WS 4.0.x.

If we include testing against "wss4j-next" in our CI solution, then that may offer enough confidence for you to simply exclude Wss4j from your own build and supplant it with 3.0.0 instead.

from spring-ws.

Hi @gregturn. I'm not sure I understand your position completely.

Are you suggesting that spring-ws will continue using WSS4J 2.4.x for foreseeable future (instead of switching to 3.x) or merely that there will be no dedicated spring-ws release just for the sake of WSS4J upgrade?

If everything works ok with WSS4J 3.x (as your testing results indicate), why not switch to that version as required dependency (whenever it fits the spring-ws release schedule, not necessarily in a dedicated spring-ws release)?
IIUC, WSS4J 3.x uses jakarta namespaces, so it would be in line with #1213 to (eventually) switch to that version.

from spring-ws.

Spring WS has yet to see a reason to launch 4.1.x line at this point in time. We don't have any sweeping changes at this point to make.

If Wss4j 2.4 is using pre-Jakarta EE 9 stuff, we haven' heard (yet) of that. I don't know if that either means its mostly used internally, or if people using Spring WS with Wss4j haven't made the jump. But either way, it passes our testing.

To maintain binary compatibility, we typically don't make a switch to a new major version (2.4 -> 3.0) without a minor version change in Spring WS (4.0 -> 4.1). Part of the reason for coming out with Spring WS 4.0 was to bump other libraries that were vital to pick up Jakarta EE 9.

This would be the first time I've heard of Wss4j having issues with Jakarta EE 9. Perhaps our testing doesn't expose it? If you were to procure a test scenario that exposed such a situation where Spring WS 4.0 combined with Wss4j 3.0 caused a Jakarta EE 9 issue, that would give us grounds to solve such a problem.

But as things currently stand, it looks like simply upgrading a project to use Wss4j 3.0 won't run into any issues with Spring WS 4.0.

from spring-ws.

@gregturn Thanks for the answer.

I mostly agree with what @cachescrubber wrote. I do not have an explicit problem using spring-ws 4.0.x with wss4j 2.4.1, but judging from wss4j jakarta upgrade changes it seems quite possible that there some problematic use cases might exist.

from spring-ws.

@cachescrubber I have discussed this issue with the Spring Boot team. Since there is no autoconfiguration nor version management that involves Wss4j, they are open to the possibility of an upgrade to a major version of Wss4j in a service release of Spring WS.

I think the criteria under which to make such a move in Spring WS would require exposing that Wss4j 2.4 does NOT work properly with Jakarta EE 8 but DOES work with Jakarta EE 9. Right now, it may be that we don't see this due to all method signatures and return types are not based upon Jakarta EE, but instead on interfaces that are still present in the JDK (e.g. javax.security and javax.xml.namespace), hence we can't see the issue.

Spring WS Security has lots of test cases concerning Wss4j. If you were to help us write a test case that exposed this Jakarta EE 9 lack of support, it would help us very much work toward making this transition.

from spring-ws.

Hi @gregturn thanks for coming back to this.

I actually have no spring-ws-security use case which breaks because of not having Jakarta EE 9+ version of wss4j. (We are using securement and validation-actions=Signature).

My main concern are transitive dependencies introduced by Wss4j 2.4.x that are incompatible with spring-boot >= 3.0.0.

#1360 for example - and I just spotted another possible issue. wss4j has a dependency to ehcache 3.10.8 which should be declared using the jakarta qualifier.

[INFO] |  |  \- org.ehcache:ehcache:jar:3.10.8:runtime
[INFO] |  |     \- javax.cache:cache-api:jar:1.1.1:runtime

Using 3.0.1 this would be (note the classifier)

[INFO] |  \- org.ehcache:ehcache:jar:jakarta:3.10.8:runtime
[INFO] |     \- javax.cache:cache-api:jar:1.1.1:runtime

An upgrade to wss4j 3.0.x. would eliminate all those potential issues.

I personally would use the possibility of the upcoming spring-boot minor release to get 4.1 out - so nobody could be surprised by the major update of wss4j. Doing so in a service release would be fine for me (in this special case) but I cannot really produce a test case to ensure this works for everyone.

from spring-ws.