Re: Reproducible JARs

[George Bateman <ge...@gmail.com>]

Hi Gintas and Stefan, and List,

Thanks very much for your emails. Sorry for the slight delay in replying!

On 25 July 2017 at 07:39, Gintautas Grigelionis <g....@gmail.com>
wrote:
> I believe the easier way would be to diff the fileset of classes to be
> packed to the fileset of classes in the jar before creating a new jar.
> There's a tool called zipdiff that could do the trick (it may ignore
> timestamps, etc). That would correspond to a javac deciding on whether to
> recompile the classes (which is based on timestamps, I guess ;-).

That doesn't solve the timestamps problem though; two people building from
scratch with no jar or class files to begin with will still get different
modification times in it.

> It sounds to me like you're looking for an equivalent of ClearCase
> winkin. If that's the case, have you read [1]?

I have now, thank you! I'll be honest, adding that sort of capability to
Ant sounds just a little beyond my capabilities. Also, it doesn't seem to
be necessary; javac seems to be giving the same exact output every time for
a given javac version.

Stefan wrote:
> The manifest may contain the current time stamp, to make things worse
> for you :-)

Fortunately, I don't see anywhere in Jar.java that mentions time or date,
except passing it to Zip#zipFile() as the modification time, and I override
it there anyway.

> I'm not sure what you want can be achieved at all. The best you can get
> is the exact same jar when the build has been run on the same OS with
> the same version of java, javac and zlib (and probably a few other
> things I'm missing right now).
>
> Different javacs will create different class files. ZIP (and thus JAR)
> creation uses zlib under the covers and different versions may result in
> different deflated output.

That's fine. It's sufficient to be able to say that if you set up your
build environment to my exact but reasonable instructions (as you get in a
Debian source package, for example), you will get the same thing I got.
This would prove that I built the binaries from the source I said I did
just by comparing the single eventual output file.

Re: date formatting, I've added a "parseLenientDateTime" method to the end
of DateUtils.java. It's compatible with the date attribute to <touch> but
also accept milliseconds since epoch and a small range of ISO 8601-type
formats, so that dates output by other software can more easily be read by
Ant. Would it be okay if I submitted a patch that got <touch> to use
parseLenientDateTime as well? It's currently a bit awkward to make git, for
example, output a date that can be read by <touch>.

I've attached the output of git diff so you can see it, but what's the
correct way to submit the code to you?

Best wishes,

George.

Re: Reproducible JARs

[Stefan Bodewig <bo...@apache.org>]

On 2017-08-23, George Bateman wrote:

> Stefan wrote:
>> The manifest may contain the current time stamp, to make things worse
>> for you :-)

> Fortunately, I don't see anywhere in Jar.java that mentions time or date,
> except passing it to Zip#zipFile() as the modification time, and I override
> it there anyway.

I thought we might add a build timestamp inside the default manifest. I
just checked and we don't. All is well.

>> I'm not sure what you want can be achieved at all. The best you can get
>> is the exact same jar when the build has been run on the same OS with
>> the same version of java, javac and zlib (and probably a few other
>> things I'm missing right now).

>> Different javacs will create different class files. ZIP (and thus JAR)
>> creation uses zlib under the covers and different versions may result in
>> different deflated output.

> That's fine. It's sufficient to be able to say that if you set up your
> build environment to my exact but reasonable instructions (as you get in a
> Debian source package, for example), you will get the same thing I got.
> This would prove that I built the binaries from the source I said I did
> just by comparing the single eventual output file.

In this case you could <touch> all files that end up inside the archive
to some fixed timestamp and obtain the same jar for all of them.

It may not work for the timestamp of the MANIFEST.MF, come to think of
it. See line 556 in Jar.java (master branch), the manifest will always
use the current timestamp. Same for the META-INF directory.

> I've attached the output of git diff so you can see it, but what's the
> correct way to submit the code to you?

Attachments are stripped, so your gif never made it through.

Please open an enhancement request in bugzilla[1] and attach your patch
or alternatively open a github pull request.

Stefan

[1] https://bz.apache.org/bugzilla/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org