As per Apache policy the sigs or hashes should NOT be mirrored, see also https://issues.apache.org/jira/browse/INFRA-6848 <https://issues.apache.org/jira/browse/INFRA-6848>
You can trust that it is an Apache committer who signed the artifact by verifying with gpg —verify. If you got the KEYS file from Apache and also double check the PGP key ID, then you are safe. Ideally, all committers should get their code signing key signed by the other committers to build a web of trust, but that is not done enough.. https://www.apache.org/dev/release-signing.html#web-of-trust <https://www.apache.org/dev/release-signing.html#web-of-trust> -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 3. mar. 2017 kl. 14.16 skrev Bram Van Dam <bram.van...@intix.eu>: > >> From what I can see, hashes and signatures are both missing on the >> download mirrors for Lucene and Solr. That's probably prudent for >> hashes, but should signatures be there? > > I vaguely remembering raising this issue before -- though it might have > been regarding a different Apache project. From what I remember, the ASF > signature guidelines don't require software signing keys to be signed by > anyone in particular. So unless the signature file is on the (https) > Apache download site, it's probably effectively useless. > > After all there's nothing stopping me from setting up a rogue mirror, > creating a "Shawn Heisey <apa...@elyograg.org>" GPG key and signing my > fake release with it. > > Including signatures on mirrors would only lead to sloppy verification > by whoever is downloading the software. > > That is, unless there's some kind of web of trust in the release > signature, but that currently doesn't seem to be the case. > > - Bram > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
