On Tue, 21 Apr 2026 14:13:43 GMT, Jorn Vernee <[email protected]> wrote:
>> I think this comes down to the question of which option is "risky" in >> security POV. >> >> I understand it is better to control library dependencies, but it could be >> "uncontrollable" eventually if the user tried to use FFM. Thus I think it >> make sence to remove libsyslookup to prevent attacks relates to library like >> DLL hijack. > >> I understand it is better to control library dependencies, but it could be >> "uncontrollable" eventually if the user tried to use FFM. > > Not sure what you mean here. We control libsyslookup. > >> Thus I think it make sence to remove libsyslookup to prevent attacks relates >> to library like DLL hijack. > > Sorry, but I'm not convinced by this argument at all. The JVM uses dozens of > other native libraries. Heck, even the JVM itself is a library. I see no > reason why having another library would be a problem. @JornVernee I found a discussion in #4316. I understood shim library (libsyslookup) was approved to ensure it does not include more symbols than necessary. However I wonder why you said being it was a bug to be able to find any symbols from the JVM. [Javadoc for defaultLookup](https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/lang/foreign/Linker.html#defaultLookup()) recognizes to implementor to choose libraries that are widely recommends as useful on the OS and processor combination. It does not specify precise set of symbols to be exposed. I do not agree with the symbols in JVM is "useful", but I feel there are no significant reason not to prevent to access them. It could be like "Unsafe" API - it might be the reason what you want to prevent to access... ------------- PR Comment: https://git.openjdk.org/jdk/pull/30794#issuecomment-4301880199
