Rainer,
On 2/7/25 4:21 PM, Rainer Jung wrote:
Am 07.02.25 um 21:50 schrieb Rainer Jung:
Hi Chris,
Am 07.02.25 um 20:44 schrieb Christopher Schultz:
Rainer,
On 2/7/25 2:38 PM, Rainer Jung wrote:
Am 04.02.25 um 23:10 schrieb Christopher Schultz:
The proposed Apache Tomcat 10.1.35 release is now available for
voting.
All committers and PMC members are kindly requested to provide a
vote if possible. ANY TOMCAT USER MAY VOTE, though only PMC members
votes are binding. We welcome non-committer votes or comments on
release builds.
The notable changes compared to 10.1.34 are:
- Allow readOnly attribute configuration on the Resources element and
allow configuration of the readOnly attribute value of the main
resources. The attribute value will also be used by the default and
WebDAV Servlets.
- Correct a regression in the fix for bug 69382 that broke JSP
include actions if both the page attribute and the body contained
parameters. Pull request #803 provided by Chenjp.
- Expand the options for handling encoded '/' and '\' characters in
URLs both in the Connector and when using a RequestDispatcher.
For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
Applications that run on Tomcat 9 and earlier will not run on
Tomcat 10 without changes. Java EE applications designed for Tomcat
9 and earlier may be placed in the $CATALINA_BASE/webapps-javaee
directory and Tomcat will automatically convert them to Jakarta EE
and copy them to the webapps directory.
It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.35/
The Maven staging repo is:
https://repository.apache.org/content/repositories/
orgapachetomcat-1530
The tag is:
https://github.com/apache/tomcat/tree/10.1.35
https://github.com/apache/tomcat/
commit/9636e5188311f30c1e46c94191d2145998778bf4
Please reply with a +1 for release or +0/-0/-1 with an explanation.
+1
Reproducibility of the build checked (except for Windows installer
and signing) on Linux Mint 22.1. OK after setting LANG.
I'd still like to look-in on this. For the installer, are you willing
to install Wine?
I could but I'm not so eager putting wine on my laptop.
Interestingly I use NSIS to build windows installers completely on
Linux. That is one of the nice features of NSIS. Currently the only
reason I see, why wine is really used, is the tempinstaller.exe which
is created and then executed to create the uninstaller. When I use
NSIS, it can create the uninstaller directly, but I have not yet
investigated why we need this indirection.
It seems it has to do with how we do code signing, but I haven't fully
understood the details. When building an installer myself, I use
!finalize 'mysignscript myinstaller.exe'
!uninstfinalize 'mysignscript myuninstaller.exe'
inside the nsi script file.
I do not know, whether this would be feasible with how we use jsign and
the cloud signing service, but it should be doable. I haven't understood
though, how the detached signatures are used. I don't seem to use
detached signatures when doing my installer.
NSIS isn't responsible for signing the installer and uninstaller. We use
jsign for that, so swapping makensis for nsis.exe should not interfere.
Without code signing (do.codesigning=false), the following changes at
least run on Linux without wine and produce an installer. But I still
have to check, whether the intsaller actually works:
--- build.xml.kpdt_orig 2025-02-04 18:40:20.000000000 +0100
+++ build.xml 2025-02-07 22:12:14.418108524 +0100
@@ -2565,6 +2565,7 @@
<or>
<os family="windows" />
<available file="wine" filepath="${env.PATH}" />
+ <available file="makensis" filepath="${env.PATH}" />
<isset property="skip.installer"/>
</or>
</condition>
@@ -2618,11 +2619,10 @@
<arg value="/V2" />
<arg value="tomcat.nsi" />
</exec>
- <exec dir="${tomcat.dist}" executable="wine" osfamily="unix">
- <arg value="${nsis.exe}" />
- <arg value="/DUNINSTALLONLY" />
- <arg value="/DNSISDIR=${nsis.home}" />
- <arg value="/V2" />
+ <exec dir="${tomcat.dist}" executable="makensis" osfamily="unix">
+ <arg value="-DUNINSTALLONLY" />
+ <arg value="-DNSISDIR=${nsis.home}" />
+ <arg value="-V2" />
<arg value="tomcat.nsi" />
</exec>
</target>
@@ -2632,9 +2632,11 @@
<!-- Execute the temporary installer to create the uninstaller -->
<exec dir="${tomcat.dist}" executable="${tomcat.dist}/
tempinstaller.exe"
osfamily="windows" />
+ <!--
<exec dir="${tomcat.dist}" executable="wine" osfamily="unix">
<arg value="${tomcat.dist}/tempinstaller.exe" />
</exec>
+ -->
<!-- Reproducible builds: consistent timestamps for installer
files -->
<touch datetime="${tstamp.file}" pattern="yyyy-MM-dd HH:mm:ss">
<fileset dir="${tomcat.dist}"/>
@@ -2671,10 +2673,9 @@
<arg value="/V2" />
<arg value="tomcat.nsi" />
</exec>
- <exec dir="${tomcat.dist}" executable="wine" osfamily="unix">
- <arg value="${nsis.exe}" />
- <arg value="/DNSISDIR=${nsis.home}" />
- <arg value="/V2" />
+ <exec dir="${tomcat.dist}" executable="makensis" osfamily="unix">
+ <arg value="-DNSISDIR=${nsis.home}" />
+ <arg value="-V2" />
<arg value="tomcat.nsi" />
</exec>
<move file="${tomcat.dist}/tomcat-installer.exe"
tofile="${tomcat.release}/v${version}/bin/${final.name}.exe" />
BUT: IMHO without using the official signing service, the installer will
never be reproduced by me. So even if I make some sort of code-signing
work, building the installer would just show, that the file is produced.
When the build "does code-signing" there are two paths:
1. No local detached signature file exists. This is what the release
manager encounters. Jsign takes the binary, sends it to the code-signing
service and requests a signature using the user's credentials. Our build
then saves the signature to a separate file (e.g.
res/install-win/tomcat-installer.exe.sig), and also adds the signature
to the .exe file itself.
2. A local detached signature file exists. This is what everybody
receives from the release manager in the source tarball. Jsign takes the
detached signature and attaches it to the installer file you built yourself.
If the source is identical (it ought to be!) and both makensis and
nsis.exe produce byte-for-byte identical outputs given the same input
(not sure about this one), then the resulting .exe file ought to be
verifiable in a number of ways:
a. On Linux and other platforms, use osslsigncode (I use this as part of
my suite of tests on MacOS)
b. On Windows, just right-click on the file and look at the security
properties to verify that it's properly-signed
In order for you to test this, you must set codesigning=true in your
build. Note that given all the various signatures bundled with the
source release artifacts, you won't actually sign anything yourself.
Plus, if I am willing to try it on Windows, whether it looks OK.
The other wine calls used to execure makensis.exe can be replaced by
directly calling makensis on Linux using -X flags instead of /X flags.
> Also, which artifacts are not byte-for-byte identical when >
performing the build verification -- when LANG=de? All of them, or only
some of them?
Just the fulldocs tarball. The HTML pages contains german text instead
of the english one. We tried fixing it using java means (sysprops,
flags) to no avail.
It turns out that the fulldocs tarball appears to be different for
various reasons even for us release managers operating in the "en"
locale. Depending upon the JDK used to build, we have seen issues with
the LICENSE and COPYING and other files due to linked files on Windows.
We've seen issues where the javadoc sometimes points to to the
Jre17Compat class instead of the Jre19Compat class and vice-versa.
My "verify-release" ant target will tell you if the fulldocs package
isn't identical, but will still tell you that the release should be
considered reproducible.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
