Closed Bug 1637508 Opened 4 months ago Closed 3 months ago

Import a public key block fails, if it contains at least one key that RNP cannot process.

Categories

(MailNews Core :: Security: OpenPGP, defect)

defect

Tracking

(thunderbird78 fixed)

RESOLVED FIXED
Thunderbird 79.0
Tracking Status
thunderbird78 --- fixed

People

(Reporter: eelco, Assigned: KaiE)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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.

Component: Untriaged → Security
Component: Security → Security: OpenPGP
Product: Thunderbird → MailNews Core

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.

Summary: Fails to import public keys, without error message → Failure to import a import a GnuPG keyring 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

Summary: Failure to import a import a GnuPG keyring file → Import a public key block fails, if it contains at least one key that RNP cannot process.
Duplicate of this bug: 1638194
Blocks: 1595231
Status: UNCONFIRMED → NEW
Ever confirmed: true

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.

Assignee: nobody → kaie
Status: NEW → ASSIGNED

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

Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED

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

Needed for OpenPGP

Attachment #9155201 - Flags: approval-comm-beta?
Depends on: 1644705

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

[Triage Comment]

Attachment #9155201 - Flags: approval-comm-beta? → approval-comm-beta+
Target Milestone: --- → Thunderbird 79.0

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.

You need to log in before you can comment on or make changes to this bug.