RFR: 8319332: Security properties files inclusion [v20]

Martin Balao mbalao at openjdk.org
Mon Aug 26 17:42:11 UTC 2024


On Mon, 26 Aug 2024 14:40:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Document list of reserved keys in java.security.Security::getProperty/setProperty APIs.
>>   
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>>   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>
> I think throwing IAE is the cleanest approach and less likely there may be unexpected behavior if we are not worried about backporting. It would break any app previously using this as a property, but at least the behavior would be consistent.
> 
> I think the best alternate approach is to not expose it as a property.
> 
> I think the compatibility risk of an app already using `include` as a property should be extremely low. But one thought is to prepend a special character (say "+") to the property name and add a sentence to the `java.security` file that the `+include` property is not exposed in the `Security` API. It could also be added as an implementation note to the `Security` API. Since this property is JDK specific, I think an implementation note would be acceptable.

Thanks @seanjmullan for sharing your view. Just to clarify, do you mean renaming the `include` directive as `+include`? If so, I'd suggest using `#include` that resemblances macros and pragma directives.

We had an internal discussion at Red Hat and agreed in not pursuing a backport of this enhancement.

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

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-2310728235



More information about the security-dev mailing list