On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla <dhana...@openjdk.org> wrote:
>> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code >> across the OpenJDK repository to retrieve the temporary directory path, as >> GetTempPath2 provides enhanced security. While GetTempPath may still >> function without errors, using GetTempPath2 reduces the risk of potential >> exploits for users. >> >> >> The code to dynamically load GetTempPath2 is duplicated due to the following >> reasons. I would appreciate any suggestions to remove the duplication where >> possible: >> >> 1. The changes span across four different folders—java.base, jdk.package, >> jdk.attach, and hotspot—with no shared code between them. >> 2. Some parts of the code use version A, while others use version W (ANSI >> vs. Unicode). >> 3. Some parts of the code are written in C others in C++. > > Dhamoder Nalla has updated the pull request incrementally with one additional > commit since the last revision: > > fix missing code Right, so within a particular environment you can try and have matching JDK versions, but in the world as a whole we do care about different versions being able to attach to each other. (If JVMs have different temp dirs, they won't find each other and attach.) Changing the temp dir for SYSTEM processes on Windows will mean they can't be found by a SYSTEM process from a previous JDK version (assuming that SYSTEM processes already have a different temp dir to regular user processes). That may be a vanishingly small amount of processes out in the world affected, so the incompatibility risk may be small. But also if there are no processes that benefit, is it worth the complexity of the change. Maybe we can think of some examples of processes affected. How would you go about running a Java app in this way, and can we say anything about how common it is? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20600#issuecomment-2376597466
