gpg-wks-client generates empty files

[Jonas Tobias Hopusch]

Hello Werner.

> It took me a while to track this down.

It's good to see one of you respond to my mail. I was worried that maybe the
mailinglist broke both the SPF and DKIM checks and prevented it from being
delivered to the subscriber's mailboxes. To avoid that this time, I'm sending
this mail from another domain with less strict settings.

> pub   rsa4096/612F3350DB59D359 2021-01-27 [C] [verfällt: 2024-01-27]
>   Schl.-Fingerabdruck = 1F42 EF02 BE3E 6FE8 F624  C8BC 612F 3350 DB59 D359
> uid              [vollständig]  (Domain owner of jotoho.de) <hostm[...]
>                                ^- Here is leading blank.
> 
> gpg --list-packets makes it easier to see:
> 
> :user ID packet: " (Domain owner of jotoho.de) <hostmaster at jotoho.de>"
>                   ^
> Although that is somewhat peculiar it does not harm.  But,
> gpg-wks-client does some processing of the key:

It's been a few months since I generated the key with GnuPG so I don't know if I
put the extra spaces there. Maybe it's a consequence of leaving out my name
during UID creation? (Back then I was hesitant to put my name on that key though
my view on that is more relaxed by now.)

> 1. It list all mail addresses from the key and matches them to the
>    requested mail address.  (in your example hostmaster at ...)
> 
> 2. Now it may happen tha there are several user-ids all with the same
>    mail address.  gpg-wks-tools picks one of them and then extracts
>    exactly that user id - however in this case it does not match by the
>    mail address but by the full user-id so that there will be only one
>    user-id in the final key.
> 
> 3. The filter built expression unfortunately strips leading blanks but
>    requires a verbatim match.  Thus it won't find the user id again and
>    errors out.
> 
> Right there is a second error that the empty file should not have been
> written.  But after all that error should never happen.
> 
> I need to see how I can avoid to trim the leading space from the filter
> expression.

This question I'm asking myself at this explanation for the issue is why my
Gitea instance's signing key was also affected by the bug. (The one with the
autosign at gitea.jotoho.de UID)

When looking at that key with the terminal command 

> gpg --export 56105D315120E79B34C4D39516128FBFDB6214C9 | gpg --list-packets

there does not appear to be any whitespace in the UserID that shouldn't be there.

Do you mean by "Thus it won't find the user id again and errors out." that the
error when working with my domain management key also stops the software from
processing other keys, that come after it, properly?

I get the impression that maybe the code dealing with the different keys/uids
should be better isolated amongst each other so any error pertaining to key Y
doesn't also impact processing of key Z. I don't know the big picture or the code
in question though, so feel free to ignore my rambling.

In the meantime, I was able to generate a working Web Key Directory using Sequoia
and installed that on my domain so the issue has no urgency or immediate impact
for me. (Though it would be good to be able to get rid of those extra packages
again once gpg-wks-client works properly for me)

-- 
Jonas Tobias Hopusch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210819/ac5c661e/attachment.sig>