You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID> on 2023/11/03 15:45:30 UTC
Verifying Tomcat downloads
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).
--
James H. H. Lampert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Verifying Tomcat downloads
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
On 11/3/23 9:33 AM, Mark Thomas wrote:
> 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 ;)
Thanks, Mr. Thomas.
Interesting. But I'm nearly a month late for this year's conference, and
while I enjoyed the few days I spent in Halifax, as part of a pre-COVID
fall vacation in Canada, I haven't left California since the COVID
pandemic began.
If there's anybody in Orange County, California, who can legitimately
get me into the web of trust (I don't have any key of my own to
exchange; I've never needed one), I'll be happy to buy that individual
lunch sometime.
But for now, I'll simply take your word that "the KEYS file is protected
to the same degree that the source code is protected." Which is still an
improvement over not bothering to verify anything.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Verifying Tomcat downloads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Verifying Tomcat downloads
Posted by Mark Thomas <ma...@apache.org>.
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).
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.
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.
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
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 ;)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org