git: openjdk/leyden: hermetic-java-runtime: Co-locate cacerts with sun.security.util.FilePaths in JDK modules image for hermetic support.

[Jiangli Zhou]

On Mon, Mar 11, 2024 at 12:27 AM Remi Forax <forax at univ-mlv.fr> wrote:

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

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.

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.

Best,
Jiangli


>
> Rémi
>
> ----- Original Message -----
> > From: <duke at openjdk.org>
> > To: "leyden-dev" <leyden-dev at openjdk.org>
> > Sent: Monday, March 11, 2024 5:45:22 AM
> > Subject: git: openjdk/leyden: hermetic-java-runtime: Co-locate cacerts
> with sun.security.util.FilePaths in JDK modules
> > image for hermetic support.
>
> > Changeset: ff1450b7
> > Author:    Jiangli Zhou <jianglizhou at google.com>
> > Date:      2024-03-10 21:40:15 +0000
> > URL:
> >
> https://git.openjdk.org/leyden/commit/ff1450b7f5e7de523163af023fbbf96c1c5c721d
> >
> > Co-locate cacerts with sun.security.util.FilePaths in JDK modules image
> for
> > hermetic support.
> >
> > - Define each hermetic resource in separate variable in Images.gmk. The
> > HERMETIC_RESOURCES is growing too long is becoming more difficult to
> read.
> > - Add a static public method, hermeticExecutableFile() in JavaHome. The
> method
> > returns the File object to the hermetic image. I also renamed EXECUTABLE
> to
> > HERMETIC_IMAGE.
> > - In TrustStoreManager, changed TrustStoreDescriptor.storeFilePath
> (Path) back
> > to TrustStoreDescriptor.storeFile (File), which is the same as the
> original
> > version before hermetic support. With the hermetic jimage cacerts
> support, for
> > a non-NONE TrustStoreDescriptor instance, storeFile is null if the JDK
> default
> > cacerts or jssecacerts is used when running in hermetic mode. See
> comments in
> > TrustStoreManager for details. FilePaths.defaultStore() is added to help
> access
> > the default jssecacerts.
> > - Add FilePaths.cacertsStream(). This method returns a InputStream
> instance to
> > the default cacerts.
> > - Change KeyStoreUtil and AnchorCertificates to use
> FilePaths.cacertsStream() to
> > get the InputStream to the default cacerts.
> >
> > ! make/Images.gmk
> > ! src/java.base/share/classes/jdk/internal/misc/JavaHome.java
> > ! src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java
> > ! src/java.base/share/classes/sun/security/tools/KeyStoreUtil.java
> > ! src/java.base/share/classes/sun/security/util/AnchorCertificates.java
> > ! src/java.base/share/classes/sun/security/util/FilePaths.java
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240311/d2af960d/attachment.htm>