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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Verifying Tomcat downloads
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Verifying Tomcat downloads
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Verifying Tomcat downloads
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
