geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Swapnil Bawaskar <sbawas...@pivotal.io>
Subject Re: [VOTE] Apache Geode 1.6.0 RC1
Date Tue, 01 May 2018 21:23:42 GMT
+1

On Tue, May 1, 2018 at 2:19 PM Dan Smith <dsmith@pivotal.io> wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message