RFR: 8315487: Security Providers Filter [v17]

[Francisco Ferrari Bihurriet]

On Wed, 18 Dec 2024 00:35:38 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
>> 
>>   Add a debug message to inform the Filter property value read.
>>   
>>   See more in https://mail.openjdk.org/pipermail/security-dev/2024-October/041800.html
>>   
>>   Co-authored-by: Martin Balao Alonso <mbalao at redhat.com>
>>   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>
> Please make a clarification in the JEP.  FIPS is just a case we used to
> talk about how the feature could be used in practice.
> 
> 
> I did not see the benefit of the proposal yet, except the troublesome I
> have to handle with in practice.  I have to disable this feature, and don’t
> allow any security property setting, which is not easy to me once an
> editable property is introduced.  Not to mention the performance impact.
> 
> I don’t want to block this proposal.  If there is a wide consensus, please
> move forward.
> 
> Xuelei
> 
> On Tue, Dec 17, 2024 at 2:59 PM Martin Balao Alonso <
> ***@***.***> wrote:
> 
>> Then, please redefine the scope and purpose of this feature. It is just a
>> part of the solution. Xuelei
>>
>> I see it differently. It's a solution for the problem that we think it is
>> worth addressing from the JDK/JCA perspective. It's not a framework to
>> assist security providers with their FIPS configuration and certification
>> process: they will need to implement self-integrity tests, register the
>> algorithms and algorithm parameters they have certified for a specific
>> version, and possibly many other requirements. A security provider that
>> registers non-FIPS approved algorithms will not get a certification
>> anyways. The problem that we have is with non-FIPS providers that make
>> available crypto that shouldn't be used. Perhaps I can add a non-goal to
>> the JEP, if it helps to clarify this confusion.
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <https://github.com/openjdk/jdk/pull/15539#issuecomment-2549828885>, or
>> unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AQSB3EEB6LZ6TNSIEPF3J5L2GCUEDAVCNFSM6AAAAAA4HWWOTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBZHAZDQOBYGU>
>> .
>> You are receiving this because you were mentioned.Message ID:
>> ***@***.***>
>>

Hi @XueleiFan,

> I did not see the benefit of the proposal yet, except the troublesome I have to handle with in practice.

The benefit is the removal of the limitation described in the [section **What is the current limitation?** of the JBS enhancement issue](https://bugs.openjdk.org/browse/JDK-8315487#:~:text=%23%23%20What%20is%20the,on%20this%20goal%2e).

> I have to disable this feature, and don’t allow any security property setting, which is not easy to me once an editable property is introduced.

No need for this, the filter is disabled by default. If you are so concerned that you would like to forbid any security property modification to JDK deployment administrators, perhaps you should have already forbidden it. There are other security properties with a high impact in terms of behavior, for example `security.provider.<N>`, `jdk.[certpath|jar|tls].disabledAlgorithms`, `jdk.serialFilter` and `jdk.security.caDistrustPolicies` to name a few.

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

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