On 23/03/2022 16:11, Christopher Schultz wrote:
Mark,
On 3/22/22 15:30, Mark Thomas wrote:
On 22/03/2022 19:06, Christopher Schultz wrote:
On 3/22/22 13:12, Mark Thomas wrote:
<snip/>
The JSign Ant task that adds the detached signature doesn't close
the signed file. This causes problems for Ant. I've opened a JSign
issue [2] for this. I have a locally build version with a hack that
fixes the issue so I can continue testing.
Do you mean it doesn't call OutputStream.close()? Shouldn't that be
cleaned up when the process exits?
Effectively, yes. The problem is that the Ant task runs in process so
the file is still open when the next Ant target tries to work with the
file. You won't notice the issue running JSign from the command line.
Can we run the jsign task with fork="true" or is there too much
information in the ant process's memory that would need to be
insecurely-sent to the jsign process to be prudent?
I don't think it supports it. If it did, that would be another workaround.
No. The Javadoc task generates a file then zips it. We need to change
the timestamp of the file(s) inside the created zip.
??
$ ant javadoc
Dumps everything into output/dist/webapps/docs/, no ZIP files. The
"javadoc" target executes <javadoc> tasks and that's it.
What am I missing?
Look in the individual Javadoc directories. Each one has (I think) 3 zip
files that contain various indexes.
Hopefully, anything Java 11 or later with e.g. "-actlike 1.7" will
produce binary-identical artifacts. If not, merely stating that a
particular build was done with some exact JDK version should be enough.
Hopefully we'll be able to find a way to be reasonably flexible on
Java versions but we'll have to see.
As long as some other party who wishes to confirm the release hasn't
been tampered-with will be able to use the same toolchain, assuming it's
documented properly. This is what non-Java projects do for
repeatability. You can't get the same bytes when using gcc versus clang,
for example. Same with various versions of those things.
Same tool-chain should definitely work. But I'd still like to see how
much flexibility - if any - we have in versions of Java and Ant.
Sounds good. Anything that makes the release process easier is a good
thing (although compared to what it used to be like the current
process is a breeze).
:)
Okay, I'll try to do those in advance of the next releases.
Cool.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
