Deprecate remoting technologies support

[mbazos]

The original issue here was closed #24434 and I think this needs to be brought back up again.

@bclozel made a few valid points:

Doing this would be a breaking change and we would need to create a new artifact for that. This is typically the type of change we apply for major releases.

These classes have been part of spring-web since Spring Framework 1.1.

I guess it's hard to balance the severity of the issue and the amount of unsafe setup required to trigger it. Tools warning about such vulnerabilities don't usually have that context and they can only convey more information to users about the context of this vulnerability.

In this case, and especially since this new warning seems to be a misunderstanding, I don't think we should move this code now.

The issue was closed but I think this issue should be opened and accounted for at least for the next major release of the spring framework which @bclozel had mentioned as a viable option. Before closing this ticket out it would be nice if there was a set plan on how to handle this in future major releases of spring-framework.

I did fork the spring-framework repo and split the rmi code into a new module `spring-rmi' and this isn't a difficult thing to do and making this part of a major release would be nice as when people upgrade to 6.x they can accommodate for this code no longer being in spring-web.
https://github.com/mbazos/spring-framework/tree/feature/split-remoting-to-new-module

[jhoeller]

@bclozel Instead of splitting those out into yet another artifact, let's rather deprecate the entire RMI and HTTP Invoker support in 5.3 and remove those bits in 6.0 altogether. Such a style of remoting is old school and not recommendable for many reasons these days. Also, the Oracle JDK team intends to deprecate serialization in some form; we can easily anticipate that here.

[jhoeller]

I would even go as far as deprecating the Hessian support as well (a similar style with similar drawbacks even if it is not Java serialization based), leaving spring-web without any remoting contents except for JAX-WS, and allowing us to get rid of the Caucho dependency in 6.0 altogether.

Also, JMS Invoker should be deprecated and removed along with HTTP invoker since it was meant as a direct equivalent, leaving spring-jms without any remoting contents as well.

[bclozel]

Alright let's do that; we'll deprecate everything under:

• org.springframework.remoting.httpinvoker
• org.springframework.remoting.rmi
• org.springframework.remoting.caucho
• org.springframework.jms.remoting

So just leaving org.springframework.remoting.jaxws support in place.

Now depending on how security tools are implemented, they might be relying on artifact names + versions only, not a particular class on classpath. If this is the case, deprecating and removing this support might not solve the problem in the long term, unless vendors update their detection heuristics as a result.

Given how brittle the current systems seems to be (critical warnings to users for a duplicate CVE from a disbanded CNA), I'm not really optimistic right now. Users will have to reach out to their providers to make this right if the warning isn't gone by Spring Framework 6.0.

[mbazos]

@jhoeller Thanks for weighing in on this. I really like the idea of deprecating them now and removing them in 6.0.

[jhoeller]

@bclozel All we'll keep in place for the time being is the remoting infrastructure for the JAX-WS and the EJB access support then. Those might fade away themselves along with some major EE support changes in 6.0 but that's a somewhat different topic.

The remoting.rmi package contains some bits used by the Remote EJB access support but that's not a showstopper. We could still aim to deprecate the entire RMI package and use @SuppressWarnings for the RmiClientInterceptorUtils call in the EJB invoker for the time being.