RFR: 8315487: Security Providers Filter [v9]

[Martin Balao]

On Sat, 30 Nov 2024 18:56:31 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi @XueleiFan,
>> 
>> Is not a goal of this proposal to allow different filter implementations, for this reason, there isn't a pluggable filter API design. The only publicly API exposed by the filter is the `jdk.security.providers.filter` security property, overridable through a system property with the same name. Any other APIs are for JCA internal use only. More details can be found in the [proposed JEP draft](https://openjdk.org/jeps/8325511).
>> 
>> We agree that this pull request is too large to review, and for this reason @martinuy has created [JDK-8345139: Fix bugs and inconsistencies in the Provider services map](https://bugs.openjdk.org/browse/JDK-8345139) and [JDK-8345221: Replace legacy with new Provider APIs in SunNativeGSS](https://bugs.openjdk.org/browse/JDK-8345221). We already moved changes from this pull request to [JDK-8345221](https://bugs.openjdk.org/browse/JDK-8345221 "Replace legacy with new Provider APIs in SunNativeGSS") (#22461), and we'll be moving changes to [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map") in the coming days.
>> 
>> Unlike [JDK-8345221](https://bugs.openjdk.org/browse/JDK-8345221 "Replace legacy with new Provider APIs in SunNativeGSS"), [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map") will be a dependency for this pull request. In order to minimize future conflicts, we'll wait for #15539 to be integrated. Then, we'll base [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map") on HEAD code including it.
>
>> ... We agree that this pull request is too large to review ...
> 
> Thank you!
> 
>> ... Is not a goal of this proposal to allow different filter implementations
> 
> Got it.  Thank you for the clarification.  But,  does it sound reasonable to you to support the option to allow different filters implementation?  The built-in filter has many limitations and hard to cover the necessary cases like algorithm parameters filter according to context, avoiding update the existing code and providers, etc.
> 
> A plugin-able API could make it much easier for implementation and backport.  It may not even need a new API, an existing API might be sufficient for the purpose.  Please think about it.

Hi @XueleiFan ,

Looks to me that this is a significant change compared to what we proposed and would require a heavier specification. I am not seeing a compelling argument at the moment.

My first concern is not so much the work that would be required now but the burden of maintaining these APIs in the future if it turns out to be a low demand for them, a marginal benefit or both. While the decision of introducing a built-in filter requires a new system/security property that will need to be maintained, it's not incompatible with a more powerful, extensible and pluggable API in the future. We will not be with our hands tied in that sense. If we introduce a pluggable API, that is a stronger commitment.

The idea of a pluggable core security component looks to me like a door open for different filtering criteria and potential risk of confusion. I see the filter more like a simple firewall with a clear and single specification, that does not leave any room for intepretation or differences in implementation. This core component builds on top of a well defined and unambiguous concept: services are defined as a combination of a provider, service type and algorithm (*).

When we dig into the algorithm level, things start to get less universal. As explained in the JEP proposal, this is an initial iteration of a built-in filter to address the most critical —basic, if you will— use-cases. We reserved characters in the syntax to potentially extend filtering granularity and base decisions on algorithm-specific elements such as parameters, key sizes, etc. We are open to that but would like to see how this settles first, and have more discussion. For example, we can theoretically have the same algorithm X but two providers bringing their own parameters with the key size specified in bytes and bits respectively. Without a common framework, the idea of filtering X key sizes with a single rule is more tricky than what it looks at first glance.

Regards,
Martin.-

--
(*) - We had to address the special case of Cipher transformations, but that was more to address a (less-than-ideal, in my view) design choice made in the past for a critical service type. For design purity, I wish we didn't have it; it was a trade-off.

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

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