You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-issues@apache.org by "Tony Stevenson (JIRA)" <ji...@apache.org> on 2014/07/28 22:21:40 UTC

[jira] [Resolved] (INFRA-7039) keys-fetch.py does not handle V3 key fingerprints

     [ https://issues.apache.org/jira/browse/INFRA-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tony Stevenson resolved INFRA-7039.
-----------------------------------

    Resolution: Won't Fix

We are going to close this as wont fix.  Given the very low percentages in this usecase, we are going to inform people they need to go and bump their fingerprint if they run into an issue. 

> keys-fetch.py does not handle V3 key fingerprints
> -------------------------------------------------
>
>                 Key: INFRA-7039
>                 URL: https://issues.apache.org/jira/browse/INFRA-7039
>             Project: Infrastructure
>          Issue Type: Wish
>          Components: LDAP
>         Environment: https://svn.apache.org/repos/asf/infrastructure/site/trunk/people/keys-fetch.py
>            Reporter: Sebb
>            Priority: Minor
>              Labels: #bugbash
>
> If an LDAP key entry uses V3 fingerprint, the key fetch process does not work.
> This is because the server that is used - keys.gnupg.net - does not support v3 fingerprints.
> As a temporary work-round, I have added a command-line option to load keys by id; this means finding the id which corresponds to the v3 fingerprint.
> It is not possible to derive the id directly from a v3 fingerprint, so this requires a manual search, followed by manually adding the id.
> It would be useful if V3 fingerprints were directly supported.
> For example, maybe there is a GPG server that supports search by V3 fingerprint?
> Alternatively, perhaps the manual search could be automated?



--
This message was sent by Atlassian JIRA
(v6.2#6252)