Please review the ASF policy on signing releases [1]. I think these points are pertinent:
- The release manager signs the release. That provides the verification that the release binaries were in fact created by the release manager and have not been modified. Multiple signatures are not required or even possible sometimes. - The KEYS file in git[2] is a convenience for keeping [3] up to date. In fact, the KEYS file is a secondary check for a fingerprint at id.apache.org (see [4] for how ASF checks signatures on releases). To me I don’t see a strict necessity to include the KEYS file commit in the release tag. It’s on the release branch and it will be merged to /develop. $.02, Anthony [1] http://apache.org/dev/release-signing.html [2] https://github.com/apache/geode/blob/develop/KEYS [3] https://dist.apache.org/repos/dist/release/geode/KEYS [4] https://mirror-vm.apache.org/~henkp/checker/faq.html > On Apr 30, 2018, at 10:31 AM, Galen O'Sullivan <gosulli...@pivotal.io> wrote: > > -1 > > I don't see Mike's key in the KEYS file on either rel/v1.6.0.RC1 > (5ce726bd7b4f8d2648fd011a807a1bcc624ddfa5) or on develop. > > It seems odd to me to add a new key and use it to sign the release without > using an already-existing key to sign the release as well. If someone's > trying to verify a source tag, there isn't a chain of signatures with the > last signer of the release signing a commit with the addition of the next new > key. > > Galen
