[jira] [Comment Edited] (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

["Uwe Schindler (JIRA)" <ji...@apache.org>]

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

Uwe Schindler edited comment on INFRA-6583 at 7/23/13 4:19 PM:
---------------------------------------------------------------

Sebb, I agree. But I want to reduce the number of keys because it makes handling also hard for myself on my local machine.

In any case the bug here is that id.apache.org does not fetch updates to existing keys using "gpg --refresh-keys" when updating the ASC files on the web site. This also affects https://people.apache.org/keys/ because it still exposes the old ASC file without subkeys. Adding/chaning subkeys is officially supported by the GPG infrastructure (see my howto), so Apache should support it.

In any case, Apache should update the keys in any case, e.g. to detect revoked keys!
                
      was (Author: thetaphi):
    Sebb, I agree. But I want to reduce the number of keys because it makes handling also hard for myself on my local machine.

In any case the bug here is that id.apache.org does not fetch updates to existing keys using "gpg --refresh-keys" when updating the ASC files on the web site. This also affects https://people.apache.org/keys/ because it still exposes the old ASC file without subkeys.
                  
> 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