www-infrastructure-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (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:02:49 GMT

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

Uwe Schindler commented on INFRA-6583:
--------------------------------------

One addition: After updating the key on the key servers, it is also still not possible to
request a new password on https://id.apache.org. The reason is the same, the infrastructure
does not fetch the updated key from keyservers.
                
> 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 <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 <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

Mime
View raw message