RFR: 8315487: Security Providers Filter [v13]

Xue-Lei Andrew Fan xuelei at openjdk.org
Sun Dec 15 07:22:44 UTC 2024


On Fri, 13 Dec 2024 05:14:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> It's only the combination of a Provider that overrides getService/getServices + does not call putService/put + overrides newInstance without calling its parent + uses a non-Java SE service type that would be unfiltered.

FYI.  I found [a case](https://www.bouncycastle.org/download/bouncy-castle-java-fips/) that:
1. Override getService/getServices, has its own logic to use put properties.
2. Use extended Provider.Service, but not Provider.Service directly.
3. call put() and get() internally. But because of  `#1` and `#2`, the provider filter theory may not work, please verify.
4. overrides newInstance without calling its parent.
5. uses non-Java SE service types

This is a popular provider (IIRC 17% marketing share per a report).  I think you should have evaluated it and confirmed that the theory works.  Otherwise, please make sure the compatibility issues is limited and the theory works for it.  Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2543514140


More information about the core-libs-dev mailing list