Created attachment 825655 [details] Fetching public keys over WKD I am wonder whether WKD should be recommended over the keyserver in all Gentoo documentation. With WKD, GLEP 79 signatures are retained, while 3rd party sigs are "lost" when fetching over keyservers. You could fetch those sigs with "self-sigs-only" and "import-clean" being disabled. But, I don't like this, because it complicates things and there is a reason for both options being applied by default. Furthermore, you get non-gentoo.org UIDs included.
Created attachment 825657 [details] Fetching public keys over hkps://keys.gentoo.org
Created attachment 825659 [details] HKPS fetch with "--keyserver-options no-self-sigs-only,no-import-clean"
Attached examples were executed with app-crypt/gnupg-2.3.8.
s/I am wonder/I wonder/ ;)
(In reply to David Sardari from comment #0) > I am wonder whether WKD should be recommended over the keyserver in all > Gentoo documentation. What specific documents are you referring to? The process to update documentation differs depending on the document.
There are a lots of wiki sites: https://www.google.com/search?q=site%3Awiki.gentoo.org+%22--recv-keys%22 And: https://www.gentoo.org/downloads/signatures/
I'm re-assigning this to the handbook team, since that's probably the most visible place instructions would appear.
When switching to WKD, you can embed the e-mail address in the signature file to be used for the subsequent pubkey fetch over WKD. Currently, "gpg --verify ..." prints out the subkey's fingerprint, but the primary keys' fingerprints are shown at https://www.gentoo.org/downloads/signatures/ ❯ gpg --detach-sign meh.txt Please specify how long the signature should be valid. 0 = signature does not expire <n> = signature expires in n days <n>w = signature expires in n weeks <n>m = signature expires in n months <n>y = signature expires in n years Signature is valid for? (0) Signature does not expire at all Is this correct? (y/N) y gpg: using "0x3AAE5FC903BB199165D4C02711BE5F68440E0758" as default secret key for signing ❯ gpg --verify meh.txt.sig gpg: assuming signed data in 'meh.txt' gpg: Signature made Di 21 Feb 2023 11:52:43 CET gpg: using EDDSA key BA9783BF96DE7F9BFCEA0E369FA90B7D26619239 gpg: issuer "MASKED" gpg: Good signature from "David Sardari <MASKED>" [ultimate] Primary key fingerprint: 3AAE 5FC9 03BB 1991 65D4 C027 11BE 5F68 440E 0758 Subkey fingerprint: BA97 83BF 96DE 7F9B FCEA 0E36 9FA9 0B7D 2661 9239 ❯ export GNUPGHOME="$(mktemp -d)" ❯ gpg --verify meh.txt.sig gpg: assuming signed data in 'meh.txt' gpg: Signature made Di 21 Feb 2023 11:52:43 CET gpg: using EDDSA key BA9783BF96DE7F9BFCEA0E369FA90B7D26619239 gpg: issuer "MASKED" <==================================== HERE gpg: Can't check signature: No public key
Something to consider is the way keys are managed using L1/L2. With Dilfridge's pubkey, I get: ❯ gpg --auto-key-locate clear,wkd --locate-external-keys dilfridge@gentoo.org gpg: error retrieving 'dilfridge@gentoo.org' via WKD: Provided object is too large gpg: error reading key: Provided object is too large My checks show only him having this problem. I already informed him via direct mail.
I forgot to point out that this problem doesn't occur using HKPS: ❯ gpg --keyserver hkps://keys.gentoo.org --recv-keys 0x94BFDF4484AD142F gpg: keybox '/tmp/tmp.xwqskbSvOS/pubring.kbx' created gpg: /tmp/tmp.xwqskbSvOS/trustdb.gpg: trustdb created gpg: key 94BFDF4484AD142F: public key "Andreas K. Huettel (at work) <MASKED>" imported gpg: Total number processed: 1 gpg: imported: 1
