James, Mark,
On 11/3/23 12:33, Mark Thomas wrote:
On 03/11/2023 15:45, James H. H. Lampert wrote:
Forgive me if this might be a bit off-topic. But I haven't found a lot
of resources on the subject (and that includes a search of List
archives).
For years now, I've been ignoring the note on the Tomcat download
pages to verify the downloads, preferably by their PGP signatures,
before putting them into service.
This time, though, I decided to follow the instructions. I installed
GPG, imported the KEYS file, and checked the signatures.
But everything I've read about GPG, and PGP signature checking, says
it's meaningless unless the keys are verified as genuine.
Is there a procedure for doing this? A few days ago, I privately
emailed a well-known Tomcat developer, one who has helped me with
technical matters in the past, asking for a fingerprint verification.
I've heard nothing back (then again, he hasn't been heard from on-List
in a few days, so he may be away).
(Sorry... Upcoming production release.)
From the ASF perspective, if the signing key is in the KEYS file then
it can be considered valid. The KEYS file is protected to the same
degree that the source code is protected.
+1
The KEYS file in in revision control. If someone can overwrite that,
they can overwrite the release, anyway, so trust kind of begins there.
The ASF release manager keys should be in the web of trust. Those trust
relationships *typically* mean that the person trusting the key has seen
and validated government issued photo ID of the key holder. But there is
zero guarantee of that.
You can see the signatures on my key if you ask your PGP key manager to
download all signatories of my (or any other) key. You can use those to
determine whether or not you trust the whole group of signers, including
the signed key. For example, my key has been signed by a number of
notable members of the ASF. If my key were to have been signed by a
handful of people you had never heard of before, you might want to be
wary. Because it's a "web", you can follow the relationships until you
get to Kevin Bacon at which point I think you *have* to trust it.
A better way to validate the binaries is to reproduce the build. With
recent releases, as long as you build with the same Ant and Java
version/vendor as the release manager (details are in the
build.properties.release file in the root of the source archive), you
should be able to build a bit-for-bit identical binary - i.e. the
SHSA-512s will match. If a few folks do that and post their results -
ideally as part of the release vote - that adds significant weight to
the validity of the released files.
Caveats
- the Javadoc bundle will be reproducible if you use the same OS
- everything else *should* be OS independent
- reproducible builds are hard and easily broken - we might not have got
it right for every file every time
+1 again
The next 11.0 release will include a verify-release ant target which
should automate essentially all of that. It can easily be back-ported to
the other branches as well.
Alternatively, come along to the next Community Over Code conference,
take part in the key signing party and join the web of trust (or just
use this as the excuse to come to the conference).
And as a final option (I've done it once in 20 years) you can always
arrange to meet a release manager face to face to have your own 2-person
key signing party. Offers of $beverages can help facilitate this ;)
I live near Washington, DC if anybody wants to buy me a beer.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
