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