www-infrastructure-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (INFRA-6583) Changes to GPG Keys (like adding new subkeys for encryption) are not reflected on https://people.apache.org/keys/ or used by https://id.apache.org
Date Tue, 23 Jul 2013 16:12:50 GMT

    [ https://issues.apache.org/jira/browse/INFRA-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716532#comment-13716532

Sebb commented on INFRA-6583:

As far as I know, if you add a second public key to LDAP, you can then use either private
key to decrypt the resulting message. 
Dunno whether that helps here - worth a try perhaps.
But it may just be that the app fails to generate an e-mail at all if one of the keys is unsuitable.
> Changes to GPG Keys (like adding new subkeys for encryption) are not reflected on https://people.apache.org/keys/
or used by https://id.apache.org
> --------------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: INFRA-6583
>                 URL: https://issues.apache.org/jira/browse/INFRA-6583
>             Project: Infrastructure
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: LDAP, Other/Misc, Website
>            Reporter: Uwe Schindler
> After the eMail that all have to reset the LDAP password by requesting a new one, I noticed
for the second time, that I cannot use the "send password encrypted GPG mail" feature to get
a new password, because by GPG key was only created for signatures, not for encryption.
> In fact my key was missing the encryption subkey. I discussed with Tony on #asfinfra
and he recommended to create a new key. But as I have already signed many Lucene/Solr artifacts
using my current key, I did not want to replace it with a new one. Indeed, it is possible
to create the subkey for encryption on an already existing GPG key very easy. The Master-Key-ID
and Fingerprint does not change by that, only the "PGP Key Block" armor changes by that.
> The problm is no: After I submitted the changed key to the GPG key servers, the id.apache.org
/ LDAP cronjob creating the keys files for committers/members and groups (like Lucene) does
not take the changed data into account. It still uses the old armor base64 dump as key (see
https://people.apache.org/keys/committer/uschindler.asc). Please note the missing "sub" line.
The updated key should look like this: https://people.apache.org/~uschindler/E1EE085F.asc
(please note the additional line in the header and the different base64.
> It looks like the cronjob does not call "gpg --refresh-keys" to fetch all changed keys
from the key servers. I tried to enforce an update by removing the key fingerprint from id.apache.org,
waiting for the cronjob (the uschindler.asc file was removed sucessfully), but after adding
the same hash again to id.apache.org, the old key was reappearing.
> I think it is important to fix this, because creating a new key for all those committers
without encryption sub key is not a good idea and too much hassle to update everything.
> I told Tony, that i will post here my findings about "how to add the encryption" subkey.
Maybe add this to the GPG website and refer other committers to it as "howto".
> This is how to add a encryption subkey to an existing GPG key:
> - Update your local repository to get all updated keys: gpg --refresh-keys
> - Check, if your key has no encryption sub key: "gpg --fingerprint <ID>" (if there
is no additional "sub" key in the last line, you have to add one, otherwise your key is fine).
If you call "gpg -a --encrypt -r <ID>", a key without signature will print error like
"no valid public key found for encryption".
> - Enter gpg key update mode: "gpg --edit-key <ID>" and enter: "addkey" + confirm
with key password.
> - It then asks for the type of key, choose: "(6) RSA (Encrypt Only)"
> - Enter key size: 4096
> - Enter expiration: 0 (this limits to lifetime of parent key)
> - Wait until the key is created
> - Enter: "save" to save your modified key
> - You should now be able to encryt stuff: "gpg -a --encrypt -r <ID>" should run
without error
> - The fingerprint should be identical: "gpg --fingerprint <ID>", only an additional
line called "sub" added at end
> - finally, upload the key to GPG key servers as usual and create new ASC files to upload
to web server
> From this point on the committer has updated his key to support encryption, and the ASF
infrastructure should reload the public keys from the keyservers, which it does not do! (this
is the current bug).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message