You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Anthony Baker <ab...@pivotal.io> on 2018/05/01 17:15:23 UTC
Re: [VOTE] Apache Geode 1.6.0 RC1
Galen,
Given the above information what are your thoughts?
Anthony
> On Apr 30, 2018, at 3:01 PM, Anthony Baker <ab...@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 <go...@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
>
Re: [VOTE] Apache Geode 1.6.0 RC1
Posted by Swapnil Bawaskar <sb...@pivotal.io>.
+1
On Tue, May 1, 2018 at 2:19 PM Dan Smith <ds...@pivotal.io> wrote:
> +1
>
> Ran geode-release-check, looks good to me.
>
> -Dan
>
> On Tue, May 1, 2018 at 11:55 AM, Anthony Baker <ab...@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 <go...@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 <ab...@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 <
> gosullivan@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
> > >
> >
> >
>
Re: [VOTE] Apache Geode 1.6.0 RC1
Posted by Dan Smith <ds...@pivotal.io>.
+1
Ran geode-release-check, looks good to me.
-Dan
On Tue, May 1, 2018 at 11:55 AM, Anthony Baker <ab...@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 <go...@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 <ab...@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 <go...@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
> >
>
>
Re: [VOTE] Apache Geode 1.6.0 RC1
Posted by Anthony Baker <ab...@pivotal.io>.
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 <go...@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 <ab...@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 <go...@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
>
Re: [VOTE] Apache Geode 1.6.0 RC1
Posted by Galen O'Sullivan <go...@pivotal.io>.
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 <ab...@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 <go...@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