On Thu, 4 Dec 2025 17:24:03 GMT, Francisco Ferrari Bihurriet 
<[email protected]> wrote:

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

Yes, it's good to see how this behaves on other programs, especially in 
configuration files. I know `krb5.conf` also supports it but it requires the 
included file having an absolute path.

> Would you think that such a change requires a CSR?

Maybe not. I see nowhere in its description in `java.security` talking about 
relative path resolution, so you have no specification to update.

A release note is enough, IMO.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2589975871

Reply via email to