tag:gpgtools.tenderapp.com,2011-11-04:/discussions/problems/121371-cannot-upload-existing-public-keys-to-hockeypuck-key-serversGPGTools: Discussion 2023-04-05T19:08:28Ztag:gpgtools.tenderapp.com,2011-11-04:Comment/549320222022-07-14T19:44:35Z2022-07-14T19:44:35Zcannot upload existing public keys to hockeypuck key servers<div><p>This is probably because SKS returns a fingerprint in this field, whereas hockeypuck returns a long-id.</p>
<p>According to the draft HKP spec, it is compliant to return any of the fingerprint, the short-id or the long-id in a machine-readable [v]index query:</p>
<pre>
<code> The key listings themselves are made up of several lines per key.
The first line specifies the primary key:
pub:<keyid>:<algo>:<keylen>:<creationdate>:<expirationdate>:<flags>
<keyid> = this is either the fingerprint or the key ID of the
key. Either the 16-digit or 8-digit key IDs are
acceptable, but obviously the fingerprint is best. A
keyserver should use the most specific of the key IDs
that it has available. Since it is not possible to
calculate the key ID from a V3 key fingerprint, for V3
keys this should be either the 16-digit or 8-digit
key ID only.</code>
</pre>
<p><a href="https://datatracker.ietf.org/doc/html/draft-shaw-openpgp-hkp-00#section-5.2">https://datatracker.ietf.org/doc/html/draft-shaw-openpgp-hkp-00#sec...</a></p>
<p>So GPGTools should accept userIDs as well as fingerprints in this field.</p></div>andrewgtag:gpgtools.tenderapp.com,2011-11-04:Comment/549320222022-07-14T20:36:26Z2022-07-14T20:36:26Zcannot upload existing public keys to hockeypuck key servers<div><p>One possible workaround would be to append <code>&fingerprint=on</code> to the call to <code>/pks/lookup?op=vindex</code></p></div>andrewgtag:gpgtools.tenderapp.com,2011-11-04:Comment/549320222022-07-14T21:34:33Z2022-07-14T21:34:33Zcannot upload existing public keys to hockeypuck key servers<div><p>Thanks for the updates, Andrew. I've edited the original report to more accurately describe the difference being between the 40 character key fingerprint vs. the 16 character key ID. I'll also look at modifying the proxy server to automatically add that argument onto incoming queries as a workaround until hockeypuck and/or GPG Tools behavior changes.</p></div>gpg_dudetag:gpgtools.tenderapp.com,2011-11-04:Comment/549320222022-07-15T00:29:26Z2022-07-15T00:29:26Zcannot upload existing public keys to hockeypuck key servers<div><p>The workaround is successful. Adding this to the proxy server's location /pks block does the trick:</p>
<p>rewrite ^/pks/lookup(.*) $uri?fingerprint=on break;</p>
<p>So while it will still be nice to get this fixed, it's not as urgent. The hkps fallback keyserver would take priority and could really use fixing given how long it's been broken now and how isolated the fix would seem to be.</p></div>gpg_dudetag:gpgtools.tenderapp.com,2011-11-04:Comment/549320222022-10-01T13:35:24Z2022-10-01T13:35:24Zcannot upload existing public keys to hockeypuck key servers<div><p>Hi gpg_dude,</p>
<p>please excuse the long silence and late feedback. I had hoped that by now we would have gotten around to fixing the fallback key server situation.</p>
<p>Sadly that is still not the case. So for now I connected this discussion with the open ticket about that problem.</p>
<p>Sorry we don't have better news.</p>
<p>Best,<br>
Steve</p></div>Stevetag:gpgtools.tenderapp.com,2011-11-04:Comment/549320222022-10-21T19:11:36Z2022-10-21T19:11:36Zcannot upload existing public keys to hockeypuck key servers<div><p>Just making sure that the original problem report here of GPG tools not being able to upload existing keys if the key server does not respond with a full finger print vs long key id is not getting lost in the mention of the fall back key server which is being trakced in another post.</p></div>gpg_dudetag:gpgtools.tenderapp.com,2011-11-04:Comment/549320222022-10-21T20:55:17Z2022-10-21T20:55:17Zcannot upload existing public keys to hockeypuck key servers<div><p>This <em>should</em> be fixed by MacGPG 2.2.40 which changes how key servers respond to requests.</p>
<p>Could you please recheck, once the next release is out.</p></div>Stevetag:gpgtools.tenderapp.com,2011-11-04:Comment/549320222023-04-04T12:37:19Z2023-04-04T12:37:19Zcannot upload existing public keys to hockeypuck key servers<div><p>Were you able to re-test this in GPG Suite 2023.2? Is the issue resolved for you?</p></div>Stevetag:gpgtools.tenderapp.com,2011-11-04:Comment/549320222023-04-04T22:35:49Z2023-04-04T22:35:49Zcannot upload existing public keys to hockeypuck key servers<div><p>Hi Steve,<br>
I'm not sure how/where I could test this since I already modified my Hockeypuck key server to provide the response GPG Keychain was expecting. I also am not being offered 2023.2 as an update - it says 2023.1 is the latest when I use the built-in check for updates function</p></div>gpg_dudetag:gpgtools.tenderapp.com,2011-11-04:Comment/549320222023-04-05T19:08:24Z2023-04-05T19:08:24Zcannot upload existing public keys to hockeypuck key servers<div><p>That is likely because 2023.2 is ever only shown to macOS Ventura users, since the only change was the UUID change for macOS 13.3. Let's assume this fixed with 2.2.40.</p></div>Steve