The GPG key is used for signing releases and nothing else. It doesn't
tie into source code (git or svn) at all. This is by design.

If I am a release manager, and I sign a release, when you download
that release you can see the signature and know that only I could have
made that signature.

Now, maybe you don't know me, but you know Michael, and you trust him,
and you see that Michael trusts me. Furthermore, Michael knows that
the GPG key belongs to me as a person, because we did a key signing

Therefore  you can trust the release.

Apache rules say that each release manager's should be in the KEYS
file. As a matter of policy we don't store the KEYS file in git,
because we might not notice that someone has changed it.



On Tue, Feb 13, 2018 at 3:27 PM, Michael Mior <> wrote:
> 1. I believe that's it. Note that this is only necessary for release
> managers.
> 2. There's no extra step here as far as I'm aware.
> 3. No one pushes directly to GitHub. GitHub is simply a mirror of the
> official ASF repo. You can see more details here:
> 4. SVN is only used for the website and for publishing release artifacts.
> All development happens via git.
> Let me know if that answers your questions.
> --
> Michael Mior
> 2018-02-13 18:12 GMT-05:00 Edmon Begoli <>:
>> I have a question about the setup for committers:
>> 1. Does this step of sending a key to a default GPG server sets up
>> everything one needs on the Apache ID server, or is there another step that
>> needs to be made:
>> e.g.
>> gpg --send-key B13131DE2
>> Is there something else needed?
>> 2. Once the key is up, how is that propagated to the project? Adding
>> fingerprint to the Apache ID profile?
>> 3. What needs to happen to get committer's github handle added to Apache
>> Calcite github?
>> 4. How does all this get tied up with the Apache SVN for the project?

Reply via email to