1663157 - OpenPGP keyserver searching by email address is broken, we search by 0xemail

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, defect, P1)

Description

[anonym]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

While testing the new OpenPGP integration I had an awkward time trying to send encrypted email:

1. On Debian Sid I installed Thunderbird 78.2.1 from Debian experimental
2. I created a brand new Thunderbird profile for an existing email account
3. In the account's End-To-End Encryption section I generated a new key pair (probably not necessary)
4. I composed an email to another email address whose key is available on keys.openpgp.org
5. I tried sending the email with encryption enabled
6. As expected I got the message that there are problems with the recipient's key
7. I followed the dialogs until I found "Discover new or updated key", and clicked it

Actual results:

I get the error "We could not find any key matching the specified search criteria".

Expected results:

The key should have been found.

In fact, if I open the key manager manually and select Keyserver → Discover Keys online and enter the key ID I do find the key. But I have to be very careful and sanitize e.g. the usual "0x" prefix of the key ID. But searching by email address is completely broken. It seems obvious that that is what Thunderbird tries to in step 7 above.

Comment 1

[ysard]

Hi, confirmed here on Debian Jessie, Thunderbird 78.2.1.

One clarification, however:

Once the key is deleted, it is not possible to redownload it from the server by the method described here. So, neither by email nor by id.
There are 2 successive dialog boxes:

"Import {$name} (<my_entered_key_id>)?"
"No keys imported."

Note: "{$name}" is probably a display error.

Comment 2

[Magnus Melin [:mkmelin]]

I just tried for a recipient I know have a (non anonymous) key published. Works for me.

If the published key does not say which email it's associated with, obviously we can't find a key for that email. Then you also get the problem with non-filled $name parameter (along with inability to actually import it). I can reproduce that for such a key.

Comment 3

[anonym]

(In reply to Magnus Melin [:mkmelin] from comment #2)

I just tried for a recipient I know have a (non anonymous) key published. Works for me.

If the published key does not say which email it's associated with, obviously we can't find a key for that email. Then you also get the problem with non-filled $name parameter (along with inability to actually import it). I can reproduce that for such a key.

Sure. However, I did not try with an "anonymous" key, only with keys that have a matching uid to the address I search for, and that are uploaded to keys.openpgp.org, like my own email address (my user name at riseup dot net).

Since ysard also reported this problem on Debian I wondered if the Debian package could be at fault, but I can reproduce it with the official Thunderbird 78.2.1 builds.

Comment 4

[Magnus Melin [:mkmelin]]

Hmm, maybe more complicated yes. It's this case: https://searchfox.org/comm-central/source/mail/extensions/openpgp/content/modules/RNP.jsm#558
So a key can be found, but not used since the email is missing (import will fail).

Comment 5

[Magnus Melin [:mkmelin]]

Attachment: bug1663157_import_name.patch (WIP)

WIP patch not to show the error message with the empty name. But maybe the real solution should be to fill in the name from the email we searched for.

Comment 6

[Magnus Melin [:mkmelin]]

Attachment: bug1663157_sample.eml

Sample message for which discover will fail.

Comment 7

[Kai Engert [:KaiE:]]

Magnus, I don't get this exception from the code you mention in comment 4.

I have the impression that searching on keys.openpgp.org is currently broken in general, for all keys.
Maybe something on the server side changed.

Comment 8

[Kai Engert [:KaiE:]]

The bug is much simpler. During past refactoring of our code that search by email a bug was introduced. We add a 0x prefix to the email address, and cannot find that obviously.

Comment 9

[Kai Engert [:KaiE:]]

Attachment: Bug 1663157 - OpenPGP keyserver searching by email address is broken. r=mkmelin

Comment 10

[Magnus Melin [:mkmelin]]

(In reply to Kai Engert (:KaiE:) from comment #7)

Magnus, I don't get this exception from the code you mention in comment 4.

I tried discover from the message reading window, there it at least shows with the attached sample.

I have the impression that searching on keys.openpgp.org is currently broken in general, for all keys.

Your key is correctly found ;)

Comment 11

[Kai Engert [:KaiE:]]

(In reply to Magnus Melin [:mkmelin] from comment #10)

I have the impression that searching on keys.openpgp.org is currently broken in general, for all keys.

Your key is correctly found ;)

The reason is that we start by searching using WKD, and my is available there, too. So searching on keys.o.o is unnecessary.

I want to add another change. I want to make prefixing with 0x optional, if the user has already included it when entering a key ID.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/08722934183d
OpenPGP keyserver searching by email address is broken. r=mkmelin DONTBUILD

Comment 13

[Kai Engert [:KaiE:]]

Comment on attachment 9174139 [details]
Bug 1663157 - OpenPGP keyserver searching by email address is broken. r=mkmelin

Fix broken OpenPGP feature, only affects searching for keys online.

Comment 14

[Rob Lemley [:rjl]]

Comment on attachment 9174139 [details]
Bug 1663157 - OpenPGP keyserver searching by email address is broken. r=mkmelin

[Triage Comment]
Approved for 81.0b3 by wsmwk via Matrix

Comment 15

[Rob Lemley [:rjl]]

Thunderbird 81.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/482c097718f0

Comment 16

[Wayne Mery (:wsmwk)]

Comment on attachment 9174139 [details]
Bug 1663157 - OpenPGP keyserver searching by email address is broken. r=mkmelin

[Triage Comment]
Approved for esr78.

Comment 17

[Kai Engert [:KaiE:]]

https://hg.mozilla.org/releases/comm-esr78/rev/6d55aa891868680e3c799f9563d51d31ed44c2e7
78.2.2