User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

Open OpenPGP Key Management window.
Choose File | Import Public Key(s) from File
Select my GPG public key ring
A list of public keys is shown, offering Cancel and OK; choose OK.
No keys are imported.

Importing my secret key ring worked fine. I imported my private keys before importing my collection of public keys.

Actual results:

After choosing OK to import, no keys are shown. Only my private keys are (remain) visible.

Expected results:

All public keys should have been shown.

Additional information: running Thunderbird 77.0b2 on MacOS Catalina 10.15.4.

I'm not sure if we can support importing binary keyring files from other software directly.

The preferred way is to export the desires keys with ASCII ARMOR, so you get a "BEGIN PUBLIC KEY" format file, and then import that file.

I've filed bug 1637508 to track the addition of an error message on failure to import.

77.0b3 (64-bit) on Windows 10
I exported the public keys to a asc file twice (once with GPA and once with Kleopatra), both files start with

"-----BEGIN PGP PUBLIC KEY BLOCK-----"
But the result is the same as when I try to import my GPG public key ring as described by eelco@ztpe.nl above.
Is the import still buggy or do I do a mistake in the process?

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

I've filed bug 1637508 to track the addition of an error message on failure to import.

Correct, feedback was added in bug 1638537.

Importing can fail if there's just one problematic key contained in the list of keys that you're trying to import.

We need an enhancement to the RNP library that allows us to request that problematic keys are skipped.

Some initial work was done, for example in https://github.com/rnpgp/rnp/issues/1154 and https://github.com/rnpgp/rnp/issues/1145

However, there are still scenarios where it's failing, even with local code that already adds the "permissive" flag.

In addition to lenient import, and fixing the scenarios that aren't lenient yet, we need the ability to diagnose which keys are failing an import to fail.
I've suggested the addition of that feature upstream at https://github.com/rnpgp/rnp/issues/1162

It might be reasonable to attempt a two step approach.

Ideally, when importing a key, the user expects that it can be imported completely.
However, that might not be possible (because of current limitations in RNP).

We have been given an optional import flag to attempt a permissive import.
Some users might appreciate that, but maybe others are unwilling to do that (to avoid having problematic incomplete keys, e.g. if certain attributes of an imported key need to be stripped).

I suggest the following approach for the import procedure:

• try to import in strict mode
• if strict import fails, tell the user, and offer the user to import in relaxed mode.
• if user denies the suggestion, don't import
• if user agrees, proceed with related import

Does this make sense?

Makes completely sense!
Thanks for your efforts!

It would probably be helpful to list which keys were problematic, for such cases.

agreed, but RNP doesn't tell us yet

Currently, I don't have any example key that fails to import in strict mode, but works in permissive mode.
Looks like RNP is now accepting all keys in both modes!
I assume that will change.
I've also asked for an example in https://github.com/rnpgp/rnp/issues/1145

I've implemented the import mechanism described in comment 8.

For obtaining the key listing of the data to be imported (which imports into a temporary area), this patch will always use permissive mode.

Then we'll attempt to do the real import in strict mode.
If that fails, we'll prompt the user, and if permission is granted, we'll do the real import in permissive mode.

Patrick, I've renamed some functions to have a API or Impl suffix. I found it confusing that there were functions with the same name, but which were taking a different parameter list.

However, I understand you're probably calling some of these functions already in your migration code. Please let me know if you want some of these function names to remain unchanged - e.g. if you want we can keep the names in RNP or the API layer, and rename the functions in key.jsm instead.

I've got a test case that allowed me to locally test the patch.

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

Patrick, I've renamed some functions to have a API or Impl suffix. I found it confusing that there were functions with the same name, but which were taking a different parameter list.

No worries, I can handle this.

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/82b5fa7bb05f
Allow key import in RNP's permissive mode. r=PatrickBrunschwig

Comment on attachment 9155201 [details]
Bug 1637508 - Allow key import in RNP's permissive mode. r=PatrickBrunschwig

Needed for OpenPGP

Comment on attachment 9155201 [details]
Bug 1637508 - Allow key import in RNP's permissive mode. r=PatrickBrunschwig

[Triage Comment]

I still have a key export file which (in the nightly I downloaded on Jun 15) is not importing (it is at least giving an error message that no keys were imported). What is the expected current functionality here? The current status is that when importing a collection of keys, at least one key seems un-parseable by RNP, and no keys are imported; and a warning is popped up to this effect.

(In reply to Jon from comment #20)

The current status is that when importing a collection of keys, at least one key seems un-parseable by RNP, and no keys are imported; and a warning is popped up to this effect.

Yes, that's still the expected behavior. Thunderbird is unable to split a key block into pieces. And RNP doesn't provide such an API either. Currently, all we can do is to atomically ask RNP to import it. Either it works completely, or it fails completely.

The migration tool will control the export from GnuPG, so it can export and import one by one, and avoid this problem.

https://hg.mozilla.org/releases/comm-beta/rev/0e39b8506d47c922ce6dc9ef7cbfdb7e831d5722