Mailing List Archive

Hi!

On Sat, 31 Jul 2021 23:05, Jonas Tobias Hopusch said:

> Does anyone know what may have gone wrong? Is there any additional information I
> can provide to help with tracking down what I presume to be a bug?

It took me a while to track this down. If you look closely at the
listing:

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@jotoho.de>"
^
Although that is somewhat peculiar it does not harm. But,
gpg-wks-client does some processing of the key:

1. It list all mail addresses from the key and matches them to the
requested mail address. (in your example hostmaster@...)

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.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

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@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@...)
>
> 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@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

On Thu, 19 Aug 2021 17:14, Jonas Tobias Hopusch said:

> 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

Sorry, for taking long to reply.

> 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.)

I general we strip all leading and trailing spaces. But there are of
course ways to generate such a user-id, it is covered by the specs.

> 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@gitea.jotoho.de UID)

Well, this

/* Fixme: Unescape fields[9] */
if (!append_to_uidinfo_list (&mboxes, fields[9],

explains it. gpg --with-colons returns the user-id with C-style
escapes. The "https://" has a colon and thus needs escaping.

I have pushed fixes for both bugs to 2.3 and 2.2


Shalom-Salam,

Werner