RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v12]
John Neffenger
jgneff at openjdk.java.net
Wed Dec 1 01:41:32 UTC 2021
On Tue, 30 Nov 2021 21:56:51 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:
>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>
> 8276766: Enable jar and jmod to produce deterministic timestamped content
>
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
I found it helpful to look at what others have done.
The Debian `strip-nondeterminism` tool clamps the low end of the date to `1980-01-01T12:01:00`. All other dates are permitted no matter the consequence. That tool is written in Perl and is able to access all of the timestamp fields individually. See the [`zip.pm` file][1] for details.
Gradle decided that the only permissible date is `1980-02-01T00:00:00` in the default time zone of the JVM. Period. End of story. No customization at all. [They use a trick][2] with the old `GregorianCalendar` class to counteract the effect in `ZipEntry.setTime` of the default time zone. They use the `org.apache.tools.zip.ZipEntry` subclass of `java.util.zip.ZipEntry`, but many methods pass through to the super class. See the [`ZipCopyAction.java` file][3] for details.
The crux of our problem, as Andrew made more clear to me, is that the methods of `ZipEntry` do not allow for independent access to the two fields: the "DOS date/time" field and the "UT extra field modtime". When trying to set either one of them, the `ZipEntry` class can overwrite the other using the default time zone of the JVM.
@andrew-m-leonard So I agree. Either document that the archives are reproducible only within a certain range of dates, or disallow the dates that are out of range. Then we should be good for at least the next 78 years.
[1]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/blob/master/lib/File/StripNondeterminism/handlers/zip.pm#L40
[2]: https://github.com/gradle/gradle/issues/12895#issuecomment-618850095
[3]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56
-------------
PR: https://git.openjdk.java.net/jdk/pull/6481
More information about the compiler-dev
mailing list