Mark,
On 3/22/22 13:12, Mark Thomas wrote:
Hi all,
I wanted to provide a status update on this.
The bnd issue [1] has been fixed and will be included in the next
release. We can switch to the latest bnd snapshot to pick up that fix in
the meantime.
I have tested detached signatures with JSign and they do work across
platforms. I was able to build 10.1.0-M13-dev on Linux (generating the
signature) and then repeat the build on Windows this time inserting the
signature and the uninstaller was correctly digitally signed.
There are, however, a couple of issues.
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?
The zips generated by the Javadoc task don't fix the timestamps of the
files within the zips. The breaks repeatability for the full-docs
package and for the Windows installer.
If it were just the full docs package, I don't think I'd worry too much
about the Javadoc issue but the Windows installer is more of a problem.
Therefore, I plan to work on a custom Ant task that will fix these zip
files by setting the timestamps on the compressed files to be the same
as the timestamp used by the rest of the build.
Can <touch> not be used to do this?
Finally, I have some minor modifications to buidl.xml that will enable
repeatable builds. Once everything is in place the build process will
look like:
- prepare for tagging as currently (update version in
build.properties.default and edit changelog)
- run a release build to generate the detached signatures
- tag including:
- modified build.properties.default
- modified chnagelog.xml
- 2x .sig files added to res/install-win
- anyone can build a release from the tag and will get a build that
includes a signed Windows installer
Oh, that last part is clever, which of course is the whole point of the
detached signatures.
I have confirmed the builds are repeatable across Linux and Windows. I
need to work on how much variation is permitted for Ant versions and JRE
versions.
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.
The release-build should probably auto-generate a report of the
build-chain used to build the release.
Other potential improvements to the build process I've been considering
making:
1. $ ant prep-release
Generates a new build.properties file, build-release.properties which
contains a few useful items:
ant.tstamp.now=[timestamp to be used for repeatable build]
version.suffix= (intentionally blank)
release.asfuser=[username of the user rolling the release]
release.jdk=[details of build environment, perhaps additional items]
release.os=[ibid]
Then modify the build script to include build-release.properties before
any others and ignore the file if it's missing.
Also this will generate res/maven/build-release.properties which will
include:
asf.ldap.username
maven.asf.release.deploy.version
gpg.exec
There's no reason these items can't be computed from the outer build
process and used inside there. It eliminates a few steps for the person
doing the release.
2. Re-name res/maven/mvn-pub.xml -> build.xml
This saves unnecessary typing during the release. I'll probably actually
move the file, then create a new one in its place pointing to the new
one, in case some other downstream process needs that file to be in-place.
3. Read build-release.properties in build.xml (nee mvn-pub.xml) as well
as build.properties and build.properties.default. build.properties
should be almost unnecessary at this point.
4. Document the mail build <target>s in build.xml (nee mvn-pub.xml)
I'm sure there are other things I've been thinking of. These are the
ones I have in the front of my mind.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
