<div dir="ltr"><div dir="ltr">On Mon, Mar 11, 2024 at 12:27 AM Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is it not better to use a Path instead of a File for the HERMETIC_IMAGE_FILE or maybe the Path "sub-system" is not initialized at that point ?<br></blockquote><div><br></div><div>Using a Path for HERMETIC_IMAGE_FILE probably is ok. The Path to HERMETIC_IMAGE_FILE could be created using the default file system. It's worth experimenting with that. </div><div><br></div><div>On a (indirectly) related note, there are issues with using non-default file systems during early startup, such as a ZipFileSystem. Creating a file system could initialize user supplied providers and could run into various startup sequence issues. I was able to workaround some of those by delaying initializing the ZipFileSystem and loading ZipFileSystemProvider using a ServiceLoader directly. Some of the remaining ones could not be resolved properly. The current effort to move the hermetic JDK resources into jimage helps avoid those remaining issues.</div><div><br></div><div>Best,</div><div>Jiangli</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Rémi<br>
<br>
----- Original Message -----<br>
> From: <<a href="mailto:duke@openjdk.org" target="_blank">duke@openjdk.org</a>><br>
> To: "leyden-dev" <<a href="mailto:leyden-dev@openjdk.org" target="_blank">leyden-dev@openjdk.org</a>><br>
> Sent: Monday, March 11, 2024 5:45:22 AM<br>
> Subject: git: openjdk/leyden: hermetic-java-runtime: Co-locate cacerts with sun.security.util.FilePaths in JDK modules<br>
> image for hermetic support.<br>
<br>
> Changeset: ff1450b7<br>
> Author:    Jiangli Zhou <<a href="mailto:jianglizhou@google.com" target="_blank">jianglizhou@google.com</a>><br>
> Date:      2024-03-10 21:40:15 +0000<br>
> URL:<br>
> <a href="https://git.openjdk.org/leyden/commit/ff1450b7f5e7de523163af023fbbf96c1c5c721d" rel="noreferrer" target="_blank">https://git.openjdk.org/leyden/commit/ff1450b7f5e7de523163af023fbbf96c1c5c721d</a><br>
> <br>
> Co-locate cacerts with sun.security.util.FilePaths in JDK modules image for<br>
> hermetic support.<br>
> <br>
> - Define each hermetic resource in separate variable in Images.gmk. The<br>
> HERMETIC_RESOURCES is growing too long is becoming more difficult to read.<br>
> - Add a static public method, hermeticExecutableFile() in JavaHome. The method<br>
> returns the File object to the hermetic image. I also renamed EXECUTABLE to<br>
> HERMETIC_IMAGE.<br>
> - In TrustStoreManager, changed TrustStoreDescriptor.storeFilePath (Path) back<br>
> to TrustStoreDescriptor.storeFile (File), which is the same as the original<br>
> version before hermetic support. With the hermetic jimage cacerts support, for<br>
> a non-NONE TrustStoreDescriptor instance, storeFile is null if the JDK default<br>
> cacerts or jssecacerts is used when running in hermetic mode. See comments in<br>
> TrustStoreManager for details. FilePaths.defaultStore() is added to help access<br>
> the default jssecacerts.<br>
> - Add FilePaths.cacertsStream(). This method returns a InputStream instance to<br>
> the default cacerts.<br>
> - Change KeyStoreUtil and AnchorCertificates to use FilePaths.cacertsStream() to<br>
> get the InputStream to the default cacerts.<br>
> <br>
> ! make/Images.gmk<br>
> ! src/java.base/share/classes/jdk/internal/misc/JavaHome.java<br>
> ! src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java<br>
> ! src/java.base/share/classes/sun/security/tools/KeyStoreUtil.java<br>
> ! src/java.base/share/classes/sun/security/util/AnchorCertificates.java<br>
> ! src/java.base/share/classes/sun/security/util/FilePaths.java<br>
</blockquote></div></div>