RFR: 8315487: Security Providers Filter [v13]

[Xue-Lei Andrew Fan]

On Mon, 16 Dec 2024 20:41:04 GMT, Anthony Scarpino <ascarpino 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, Java SE service type class is not a final class normally. It means applications can override it, and thus can break the filter boundary. Github search implies a few cases that override Signature, [here is one](https://github.com/cping/RipplePower/blob/4bdfd7ddca69e2cfb2c33852379844880cfe2a2a/eclipse/jcoinlibs/src/net/i2p/crypto/eddsa/EdDSAEngine.java) with public constructor and get used. Developers can make more surprises even Java API specification are strictly followed.
> 
> I think it was discussed early on that the proposal cannot solve all situations. The most obvious case is algorithms that don’t use the Provider API at all. The admin has to be aware of the providers and apps they are using with the JDK. Given that FIPS 140 is a consumer of this feature, additional scrutiny by the admin is anticipated. While I agree having some classes `final` would help, the solution needs to be best effort using the current SPI to support current provider implementations.
> 
> A pluggable API may be the most flexible, but it requires third parties to implement it and their own syntax. Using an older provider makes this feature useless. It would be nice if the JDK did not have this burden, but I don’t think an alternate has proven to be more effective.

We might have different understand of FIPS 140.

My understand is that any FIPS 140 certified providers/application should get certification and cannot be updated any longer until next approval.  No one, including the admin, is expected to update the filter.  Have a editable java security property might be OK, but any update on it will break the FIPS compliant.  Applications may need to find an alternative way to prevent from java security property update to compliant to FIPS requirements.

FIPS approval is examined by official organization before the certificate is given.  If older provider does not support this feature, it may not get FIPS approval or the existing solution get used.  FIPS compliant is not something new, it has been used for many years.  We want a feature that is usable for them.

I agree that this proposal cannot solve all situation.  But can it address the situations that FIPS approval can be granted?  Otherwise, this proposal might just look great but no one can use it.

I think it applies to other crypto restriction similar to FIPS.  If there is nothing to enforce, the default JDK providers are good enough for them.

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

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