RFR: 8315487: Security Providers Filter [v17]

Xuelei Fan xuelei.f at gmail.com
Wed Dec 18 04:26:45 UTC 2024


>
>
> 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
> ).
>
>
May I ask, for what?  The section mentioned, "In some cases, the user may
need to enforce that all cryptographic primitives come from a specific
security provider. This could happen, for example, when operating in a
FIPS-compliant environment or under strict security policies."  I think
this is the real requirement.   So again, can you make it?


> > 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.
>

I did not forbid this new property yet.  I could have other related
uneditable/forbidden because Java supports so with public APIs.  I need to
update my application source code to forbid this one once it is released.
I could live, I think.   It is just a little trouble and I have to take
care of the compatibility issues for the release.

Xuelei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241217/dfc959a9/attachment-0001.htm>


More information about the core-libs-dev mailing list