On 22/03/2021 13:16, Konstantin Kolinko wrote:
сб, 20 мар. 2021 г. в 18:24, Emmanuel Bourg <ebo...@apache.org>:
2. The current Windows exe signing process isn't repeatable. There are a
few suggestions workarounds at https://reproducible-builds.org/ and I
need to discuss these with the provider of the code signing service the
ASF uses (DigiCert).
The signature is reproducible but not the timestamp. We'd need something
like a detached signature shipped with the source package, and a build
that either append the signature or get a new one from DigiCert.
There are two signed executables: installer and uninstaller,
and uninstaller is packed into the installer executable.
That's why the installer is built twice by build.xml, first to create
an uninstaller so that it could be signed. (IIRC)
A timestamp is an important part of a signature (so that one does not
create a new signature with an expired key).
The suggested workaround would be something like:
- build
- sign the .exe
- extract the signature and save it somewhere
- rebuild
- insert the saved signature
If the build is reproducible, the rebuild will be identical and the
inserted signature will be valid.
I got a quick look, I guess you replaced the <jar> tasks with <zip> to
make the timestamp of the zip entries reproducible? I'm not sure this is
sufficient, there is no guarantee the order of the entries will be the
same (this is usually dependent on the filesystem used, I don't think
Ant sorts the entries).
I have not reviewed the changes, but jar and zip differ in
a) placement of Manifest file (jar spec requires it to be the first
file in the archive IIRC)
b) encoding used for file names (jar uses UTF-8, zip uses platform default)
I couldn't find a reference to a requirement regarding the location of
MANIFEST. Do you have a reference?
File name encoding should be a non issue as all the Tomcat files have
ASCII names.
пн, 22 мар. 2021 г. в 12:44, Mark Thomas <ma...@apache.org>:
No. The Jar entries used the timestamps of the original files. As long
as the Jar task was configured not to add entries for directories (which
used the current time as the last modified date) that part was OK. The
issue was that the manifest was always created with the current time as
the last modified date.
Those entries for directories are required for some tools to operate
correctly. I think that we already turned them off once and turned
them back on.
(I think it was annotation scanning in some old version of Spring
Framework that was broken by missing directories, but I do not have a
link - just from memory.)
A link would be good so we can review exactly what the problem is/was.
I know that Apache Maven is capable of creating reproducible builds
(by setting an explicit timestamp when building). [1]
Looking at "maven-core-3.3.9.jar" as an example, it has entries for directories,
If the jar task does not do what is needed for us, it is better to ask
Apache Ant project for a fix (so that other projects can benefit from
it as well) rather than replace "jar" with "zip".
Big +1. I've already opened an issue with Bnd. I'll add doing the same
with Ant to my TODO list.
I have no problem reverting any of the reproducible build changes if
they cause problems. I too suspect that the jar -> zip change is the
most likely to trigger issues.
Mark
[1] https://maven.apache.org/guides/mini/guide-reproducible-builds.html
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
