Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Simple hashes, such as files with names ending in .sha512 . These are directly reproducible by re-hashing the files once built, and verifiable with diff .
  • GPG signatures, which are not reproducible but still verifiable with gpg --verify .
  • Windows .exe digital signatures, which are the most complicated. The release-manager generates so-called detached signatures (because the file contains the signature only) and bundles these in the release tag in revision-control, as well as in the source release. You got a copy of these files when you expanded the source archive. When you perform a release-build, the release process uses the existing detached signature files to merge with the unsigned .exe files and the result is a byte-for-byte copy of the signed installer and uninstalled binaries. You can verify these with diff or by asking Windows to confirm the digital signature of the files.

Can I do this more easily?

Yes, if you trust that the release itself comes with trustworthy tools.

In Apache Tomcat releases starting (with luck!) with 8.5.98, 9.0.85, 10.1.18, and 11.0.0-M16, you can have an automated release-verification process.

First, download the source distribution of the release, unpack it, ensure you have the required build environment for your release (mostly a proper JDK and Apache ant version), then run:

ant release

ant verify-release

Code Block
languagebash
ant release

ant verify