On 13/01/2022 01:35, Christopher Schultz wrote:
All,
Having just done the release build for Tomcat 8.5, I was checking to
ensure that the various digital signatures were done properly on the
.exe files we produce as a part of that build.
I happened to check tomcat8.exe and it's got a sha1 signature instead of
a sha512 signature like the other .exe files we sign.
Is that intentional?
Sort of.
Up until early 2021 the ASF used a code signing server originally
written by Symantec that was subsequently sold to DigiCert. That service
was limited to using SHA-1 for Windows signing.
In late 2020 the ASF started to migrate to a new code signing service
written by DigiCert. This allowed use of better hashes for Windows
signing. Tomcat was the first project to migrate in January 2021. We
first switched to SHA-256 and moved to SHA-512 a few days later.
The Commons Daemon release happened while Tomcat was migrating and
before Commons was set up in the new tool.
Those files appear to come from the commons-daemon project, and aren't
signed as a part of the release process. The signature on tomcat8.exe
for example (which is really prunsrc.exe) is Monday, January 18,
2021 7:49:06 AM.
Should we ask the commons-daemon project to roll a new release with
modern signatures on their .exe files? Or should we authenticate the
existing signature and replace it with a new sha512 one? Or should we
just ignore the discrepancy?
That would be me that would do that.
There are a few open issues but they are generally of the "it crashes"
nature with little detail on how to reproduce. The change log has a few
minor fixes and improvements. Given it is a year since the last
release I'll look at getting a 1.2.5 release out. We can pick that up
once available.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
