8243666: ModuleHashes attribute generated for JMOD and JAR files

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

8243666: ModuleHashes attribute generated for JMOD and JAR files

Alan Bateman

This is build reproducibility issue with the module-info.class files in
the packaged modules (JMOD files in the case of the JDK build).

One part to this is the ModulePackages class file attribute that is
added by the tools, including the jmod tool and the AddPackagesAttribute
tool in the JDK build. The package names are added in iteration order so
can vary from run to run. This is trivially fixed to sort the package
names.!

The other part is the ModuleHashes attribute where a hash is computed
from all contents of a package module. In the case of JMOD files this
means the hash covers the timestamps on the entries in the JMOD so it
varies from build to build too. The proposal is to compute the hash over
the names and content of the entries. The timestamps and other
non-interesting meta data is not included in the hash. Hashes are to
avoid accidental mixing of tightly coupled modules from different builds
so I think this should be strong enough.

The webrev with the proposed changes is here:
    http://cr.openjdk.java.net/~alanb/8243666/webrev/

There are follow-on issues that will need to be fixed in jlink and the
image writer before the modules container is reproducible. That is
something for another set of patches.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: 8243666: ModuleHashes attribute generated for JMOD and JAR files

Mandy Chung
Hi Alan,

On 4/27/20 12:34 PM, Alan Bateman wrote:

>
> This is build reproducibility issue with the module-info.class files
> in the packaged modules (JMOD files in the case of the JDK build).
>
> One part to this is the ModulePackages class file attribute that is
> added by the tools, including the jmod tool and the
> AddPackagesAttribute tool in the JDK build. The package names are
> added in iteration order so can vary from run to run. This is
> trivially fixed to sort the package names.!
>

This looks okay.

> The other part is the ModuleHashes attribute where a hash is computed
> from all contents of a package module. In the case of JMOD files this
> means the hash covers the timestamps on the entries in the JMOD so it
> varies from build to build too. The proposal is to compute the hash
> over the names and content of the entries. The timestamps and other
> non-interesting meta data is not included in the hash. Hashes are to
> avoid accidental mixing of tightly coupled modules from different
> builds so I think this should be strong enough.
>

Computing the hash from the names and contents of all entries sounds a
good solution.

> The webrev with the proposed changes is here:
>    http://cr.openjdk.java.net/~alanb/8243666/webrev/
>
This looks good to me.

Mandy