On 01 Dec 2020, at 14:09, Mark Thomas <ma...@apache.org> wrote: >> I also object to the removal of OpenSSL code, for the same reason. > > It isn't being removed. The APR/Native library will be retained along > with OpenSSL support for the NIO and NIO2. > > I expect the scope of the APR/Native library for Tomcat 10.1.x onwards > will be reduced to just those native methods required to interact with > OpenSSL which may mean removal of the APR dependency. If we can use > OpenSSL without any native code of our own (e.g. via project Panama or > similar) then better still.
I don’t see the logic here. If the use of native code is a risk, then I expect to see use of openssl and any other API brought in by Panama avoided for the same reason? >> We are in the middle of a global pandemic. Our users do not have the >> resources to suddenly divert to reengineering what is to them a perfectly >> working system, to replace what exists with something else that just works >> differently. > > Upgrading to Tomcat 10 already requires significant re-engineering work > due to the java package change for all the specification APIs. > > Switching an HTTP or AJP connector from APR/Native to NIO or NIO2 with > OpenSSL requires a change of three/four characters in one configuration > file. We have deliberately made it very easy to switch between connectors. > > No-one is being forced to upgrade. Atlassian forced me to upgrade. This is the core of the problem - gone are the days when Tomcat was just a simple server that people downloaded and used to make bespoke web services and could write code any way they liked. Now Tomcat is part of other systems, who in turn have other support horizons unrelated to this project. The AJP deprecation is a problem. For those unaware of what AJP did, AJP allowed a proxy server and Tomcat to be “glued” together as it they were one server, and not two discrete entities. The proxy configuration - that’s SSL, authn and authz - was passed transparently across to Tomcat which behaved as if Tomcat itself had performed the SSL, authn and authz. Sure, if you have a bespoke web service and the budget you can make hack changes to compensate. If your Tomcat is being provided by a vendor, or if you’re under financial strain due a pandemic, then no - you have a sudden very unwelcome headache. The closest RFC compliant solution to this problem is JSON Web Tokens (JWT), which allows data to be passed across both securely and in an RFC compliant way over HTTP. Tomcat should have fixed this problem first, and then deprecated AJP with the clear notice “use this alternative in future”. Regards, Graham —
