On Wed, 6 Mar 2024 12:19:14 GMT, Francisco Ferrari Bihurriet <fferr...@openjdk.org> wrote:
>> The implementation of this proposal is based on the requirements, >> specification and design choices described in the [JDK-8319332] ticket and >> its respective CSR [JDK-8319333]. What follows are implementation notes >> organized per functional component, with the purpose of assisting to >> navigate the code changes in this pull-request. >> >> ## Security properties loading (overview) >> >> A new static class named `SecPropLoader` (nested within >> `java.security.Security`) is introduced to handle the loading of all >> security properties. Its method `loadAll` is the first one to be called, at >> `java.security.Security` static class initialization. The master security >> properties file is then loaded by `loadMaster`. When additional security >> properties files are allowed (the security property >> `security.overridePropertiesFile` is set to `true`) and the >> `java.security.properties` system property is passed, the method `loadExtra` >> handles the extra load. >> >> The master properties file is loaded in `OVERRIDE` mode, meaning that the >> map of properties is originally empty. Any failure occurred while loading >> these properties is considered fatal. The extra properties file >> (`java.security.properties`) may be loaded in `OVERRIDE` or `APPEND` mode. >> Any failure in this case is ignored. This behavior maintains compatibility >> with the previous implementation. >> >> While the `java.security.properties` system property is documented to accept >> an URL type of value, filesystem path values are supported in the same way >> that they were prior to this enhancement. Values are then interpreted as >> paths and, only if that fails, are considered URLs. In the latter case, >> there is one more attempt after opening the stream to check if there is a >> local file path underneath (e.g. the URL has the form of >> `file:///path/to/a/local/file`). The reason for preferring paths over URLs >> is to support relative path file inclusion in properties files. >> >> ## Loading security properties from paths (`loadFromPath` method) >> >> When loading a properties file from a path, the normalized file location is >> stored in the static field `currentPath`. This value is the current base to >> resolve any relative path encountered while handling an _include_ >> definition. Normalized paths are also saved in the `activePaths` set to >> detect recursive cycles. As we move down or up in the _includes_ stack, >> `currentPath` and `activePaths` values are updated. >> >> ## Loading security properties from URLs (`loadFromUrl` method) >> >> The extra properti... > > Francisco Ferrari Bihurriet has updated the pull request with a new target > base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge 'openjdk/master' into JDK-8319332 > - Merge 'openjdk/master' into JDK-8319332 > > Conflict in ConfigFileTest.java solved by keeping our file, which had > been previously adjusted. > > Commands: > git merge upstream/master > git restore --ours -- test/jdk/java/security/Security/ConfigFileTest.java > git add test/jdk/java/security/Security/ConfigFileTest.java > git merge --continue > - 8319332: Adjust code for JDK-8319673 changes > > JDK-8319673: Few security tests ignore VM flags > > Next, we will merge the openjdk/master branch and ignore the conflict in > this file. > > Co-authored-by: Martin Balao <mba...@redhat.com> > Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com> > - 8319332: Update copyright and ConfigFileTest.java. > > Bump copyright year to 2024 in all the modified files. > > Remove leaked host name from children JVMs debug command. > > Extract Executor::addSystemPropertiesAsJvmArgs from Executor::execute > and rename 'allJvmArgs' to 'command'. Also split class name and > RUNNER_ARG addition to 'command' as two separated command.add() calls. > > Co-authored-by: Martin Balao <mba...@redhat.com> > Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com> > - Merge 'openjdk/master' into JDK-8319332 > - 8319332: Fix corner-case regression with bash pipe > > Extra properties files provided through bash pipes used to work before > this enhancement, restore their behaviour. > > Also take advantage to use Files::isRegularFile, Files::isDirectory and > Files::exists APIs instead of converting from Path to File. > > Linux reproducers (sub-shell, stdin, and combination of both): > > java -XshowSettings:security:properties \ > -Djava.security.properties==<(echo name=value) \ > -Djava.security.debug=properties -version > > echo name=value | java -XshowSettings:security:properties \ > -Djava.security.properties==/dev/stdin \ > -Djava.security.debug=properties -version > > echo name=value | java -XshowSettings:security:properties \ > -Djava.security.properties==<(echo include /dev/stdin) \ > -Djava.security.debug=properties -version > > Co-authored-by: Martin Balao <mba...@redhat.com> > Co-authored-by: Francisco Ferrari Bihurriet... In the compatibility risk description of the CSR: > In line with the efforts to check invalid URLs (see > [JDK-8294241](https://bugs.openjdk.org/browse/JDK-8294241): Deprecate URL > public constructors), "java.security.properties" file-URL values such as > "file:///C:\some\path\extra.properties" or "file:///some/path/extra > .properties" need to be converted into their valid counterparts: > "file:///C:/some/path/extra.properties" and > "file:///some/path/extra%20.properties" respectively. Is it worth breaking such invalid URLs? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-2061457085
