openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject [DISCUSS][VOTE] Release Groovy UNO Extension 0.1.4
Date Tue, 05 Apr 2016 17:36:25 GMT
Side question.

> -----Original Message-----
> From: Carl Marcum []
> Sent: Tuesday, April 5, 2016 04:07
> To:
> Subject: [VOTE] Release Groovy UNO Extension 0.1.4
> This is for a source release of Groovy UNO Extension 0.1.4 from Apache
> OpenOffice
> and binaries made available from Maven via Apache Nexus.
> Source packages for RC1 are available at:
> and the reference revision is r1737622.
> Binary Maven packages are staged here:
> 1019/
> I'm signing with a new 4096 bit key I recently added to KEYS.

I forgot to ask this when you mentioned the new key before.

Carl, is the fingerprint of this new key added to your account information at

I see only one entry for cmarcum at <> and

    ASF ID: cmarcum
    LDAP PGP key: 8204 E089 64AC 9ABA 7472 A123 669C FA03 CED4 6810

    pub  2048R/CED46810 2011-07-04 Carl Marcum <>
          Key fingerprint = 8204 E089 64AC 9ABA 7472  A123 669C FA03 CED4 6810
    uid                            Carl Marcum <>
    sub  2048R/3175CD6A 2011-07-04

is for your older 2048-bit key.  (Note that you can have any number of key signatures in your
account record and you should probably not remove any that have been used in signing releases
or for any other situation where confirmation is needed that the key is one of yous as an
ASF committer.)

The committer keys file is automatically updated from PGP key signatures and will reflect
countersignatures on your key (circle of trust attestations).  If the key is ever revoked
for any reason, that will be discoverable there too unless the fingerprint or apache account
are removed.  (Of course, you must publish your new 4069-bit public key to a PGP key server
for this to work.)

As far as I know, public keys in release-archive KEYS files are not automatically synchronized
in that manner, although the one associated with projects is, such as the one at 
<>.  This should *not* be used as
a release KEYS though.  See <> for details.  

What is needed in KEYS files for authenticating a release and stored in the mirror directories
is always cumulative, so any signature you have used to sign a release (candidate) needs to
be in the release-associated KEYS file.  It is nice to use the 
<>-accessed version of the key in our KEYS
file because that one has the Useful descriptive information as shown for your 2048-bit key,

Note that keys that have not been used in signing release candidates do not need to be in
release-associated KEYS files and it is good practice (and an useful precaution) to keep it
that way.

PS: None of this is a release blocker.  But you can get the dots connected before the [VOTE]
concludes.  I assume there is no further reason to touch the KEYS file that you have already

 - Dennis

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message