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
