On Wed, 3 Dec 2025 15:41:21 GMT, Weijun Wang <[email protected]> wrote:
>> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> three additional commits since the last revision: >> >> - Convert ConfigFileTestAnonymousPipes to Java >> - Review suggestion: go back tolerating IOException >> >> We agreed an IOException in this case is recoverable, and decided to >> tolerate it, while adding a debug log message with the exception. >> - Review suggestion: improve comment clarity > > src/java.base/share/classes/java/security/Security.java line 260: > >> 258: // under the rationale that the person writing the >> 259: // original properties file is the one who decides >> 260: // where the relative includes should resolve. > > The person writing the original properties file may have expected includes to > resolve relative to its own location, but whoever created the symlink may > have intended a different resolution path. If they wanted the original > location, they could have just used the real file directly instead of > introducing a symlink. > > For a comparison, I write a tiny C program that includes another file, the > included file was resolved based on the base file's named path, not its real > path. > > I know you might have a backward compatibility concern here. Hi @wangweij, indeed is a fair and interesting point of view! I like the idea of not doing any resolution at all to get rid of the possible problems. But let me do a similar test with some other programs supporting include directives in their configuration files (such as [OpenSSL](https://www.openssl.org/docs/man1.1.1/man5/config.html#:~:text=Other%20files%20can,ignore%20the%20include%2e), [OpenSSH](https://man7.org/linux/man-pages/man5/ssh_config.5.html#Include:~:text=it%2e-,Include,inclusion%2e), [Git](https://git-scm.com/docs/git-config#_includes) and [Apache HTTP Server](https://httpd.apache.org/docs/2.4/mod/core.html#include)), to collect more real world examples (beyond C includes which you already tested). Regarding the backward compatibility, this is not the main use case, and if we could back-port that to 25 in the future, we would get the same behavior in all the supported JDKs shipping [JDK-8319332](https://bugs.openjdk.org/browse/JDK-8319332 "Security properties files inclusion") (as 24 reached end of support). Would you think that such a change requires a CSR? If that's the case I would support the change but in a separate enhancement, so we can get this bug fixed in 26. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2589946016
