+1 On Tue, May 1, 2018 at 2:19 PM Dan Smith <dsm...@pivotal.io> wrote:
> +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 > > > > > > > >
