+1 Ran geode-release-check, looks good to me.
-Dan On Tue, May 1, 2018 at 11:55 AM, Anthony Baker <aba...@pivotal.io> wrote: > 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 > > > >
