On Wed, 1 May 2024 15:12:10 GMT, Weijun Wang <wei...@openjdk.org> wrote:
> Just one more question on the system property expansion when it's not
> defined. In your example:
>
> > include ${java.home}/conf/security/profile${SecurityProfile}.security
>
> How bad will it be if we require user to set `SecurityProfile` to `default`
> or an empty string if they don't need any specific profile? I'm a little
> concerned that user would mistype the system property name on the command
> line.
Requiring users to set a security property for a default configuration would
turn `include` statements with a user-defined property pretty unusable in my
view, even if the value were an empty string. I'd expect such user-defined
property to be optional and, if not set, fall back to a secure default. With
that said, this strict behavior that you are suggesting can be achieved
already. Going back to the example, if profiles are defined in a way such that
the file `profile_.security` does not exist but there is
`profile_default.security` instead, users would be required to pass
`SecurityProfile` to `default` and any mistype in the property name or value
would be fatal.
With the existing `java.security.properties` property, a mistype on either the
property name or value goes completely quiet. The value mistype is not ideal in
my view but we don't want to introduce compatibility breaking changes there.
With the proposed feature, a mistype in the property value is noticed
immediately and a system administrator can optionally enforce users to always
pass a correct system property name-value pair.
It is also worth noticing that users can pass `-XshowSettings:security` or
`-Djava.security.debug=properties` to understand what security properties are
in effect.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-2088819066
