Ok, thanks Galen. AFAICT, the KEYS file being referred to is this one: https://dist.apache.org/repos/dist/release/geode/KEYS <https://dist.apache.org/repos/dist/release/geode/KEYS>. Other Apache projects like Flink, Beam, Impala, or Kafka don’t version control their KEYS file.
@PMC - we need more reviews and votes to complete this release in a timely manner. Please check it out. Anthony > On May 1, 2018, at 11:42 AM, Galen O'Sullivan <gosulli...@pivotal.io> wrote: > > Thanks for the clarification, Anthony. The release signing page you linked > does say this: > > > Since the KEYS may be needed to check signatures for archived releases, it > > is important that all keys that have ever been used to sign releases are > > retained in the file. Entries should only be added (as described above), > > not removed. > > > Your public key should be exported and the result appended to the > > appropriate KEYS file(s). > > I think we should get Mike's key added to both the develop and release > branches. I would prefer if it was present in the release tag (it could be > confusing for someone checking release history). > > But I guess it shouldn't be too much of a problem if the key isn't in KEYS on > the release. It won't affect the binary. > > I'll change to a +0. > > Galen > > On 5/1/18 10:15 AM, Anthony Baker wrote: >> Galen, >> >> Given the above information what are your thoughts? >> >> Anthony >> >> >>> On Apr 30, 2018, at 3:01 PM, Anthony Baker <aba...@pivotal.io> wrote: >>> >>> 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 >
