Bugzilla

I understand what's happening.

The Enigmail migration version 2.2 performs an incomplete migration, as reported in bug 1656401.
The "automatic passphrase for protecting secret keys" isn't created. File encrypted-openpgp-passphrase.txt is missing.
Secret keys are imported.
Because of the missing automatic passphrase, the keys are stored without protection on disk.
Because of the incomplete init, the imported secret key cannot be marked as a personal key (based on gpg ownertrust ultimate).

The next time Thunderbird is started, we run into an automatic check, that detects an inconsistency.
We should never have secret keys stored, without having a file encrypted-openpgp-passphrase.txt
The code runs into an exception, and subsequent actions are aborted.

When importing a key, rnp_key_protect fails, because the automatic passphrase cannot be read from encrypted-openpgp-passphrase.txt and again we run into an exception, which causes the import procedure to get stuck as reported.

I suggest the following remedy:

On start, we check if we have secret keys, but no passphrase file. If not (either no keys and no passphrase, or both), then everything is fine.

If we see the error condition, we do the following:

We check, if all secret keys are unprotected (not protected by a passphrase). This is the scenario that the failed migration produced. If all keys are unprotected, we can suggest an automatic repair. We can show an error message explaining. We should offer the user a chance to make a backup. After all, we're going to change their secret key file, and we should be on the safe side. We show the file that should be backed up. We offer the user the choice to repair now, or cancel. If the user cancels, we will start up with OpenPGP degraded/disabled. If the user confirms to repair, then we will create the automatic passphrase file, and then change all unprotected keys to be protected by it. This creates the intended configuration and the required consistency.

However, our check might discover that there are some protected key, that is, secret keys that are protected by a passphrase. This situation isn't produced by the Enigmail import. I suggest to handle this scenario nevertheless, to cover future possible failures that some users might experience (for example file corruption, or manually deleted files, or other future bugs). I'd like to inform the user if this scenario is detected. We cannot automatically repair it. If keys are passphrase protected, and we don't have the file with the passphrase, there's nothing we can do. (We don't protected keys, we always attempt to unprotect them, before considering to import them.)

I suggest additional changes to make our code more robust.

The bug was made possible, by importing secret keys into temp storage, unprotecting them, then copying them to the permanent storage, then protecting them (which failed).

I'd like to change the logic in the following way, so that we won't import unprotected keys.
New logic: Import secret keys into temp storage, unprotecting them, protect them with the automatic passphrase, then copying them to the permanent storage.
This way, if protecting fails, our import will fail, and we avoid having unprotected keys.

In addition, I want to change the init code related to preference mail.openpgp.enable
Currently, changing the pref from false to true doesn't dynamically trigger required initialization to use the OpenPGP feature. Currently a restart is required.

We should add code that discovers the pref change from false to true, and perform all init automatically.
(But I don't want to dynamically disable if the pref is set to false at runtime, the feature will remain enabled until the end of the process lifetime.)

I understand what's happening.

The Enigmail migration version 2.2 performs an incomplete migration, as reported in bug 1656401.
The "automatic passphrase for protecting secret keys" isn't created. File encrypted-openpgp-passphrase.txt is missing.
Secret keys are imported.
Because of the missing automatic passphrase, the keys are stored without protection on disk.
Because of the incomplete init, the imported secret key cannot be marked as a personal key (based on gpg ownertrust ultimate).

The next time Thunderbird is started, we run into an automatic check, that detects an inconsistency.
We should never have secret keys stored, without having a file encrypted-openpgp-passphrase.txt
The code runs into an exception, and subsequent actions are aborted.

When importing a key, rnp_key_protect fails, because the automatic passphrase cannot be read from encrypted-openpgp-passphrase.txt and again we run into an exception, which causes the import procedure to get stuck as reported.

I suggest the following remedy:

On start, we check if we have secret keys, but no passphrase file. If not (either no keys and no passphrase, or both), then everything is fine.

If we see the error condition, we do the following:

We check, if all secret keys are unprotected (not protected by a passphrase). This is the scenario that the failed migration produced. If all keys are unprotected, we can suggest an automatic repair. We can show an error message explaining. We should offer the user a chance to make a backup. After all, we're going to change their secret key file, and we should be on the safe side. We show the file that should be backed up. We offer the user the choice to repair now, or cancel. If the user cancels, we will start up with OpenPGP degraded/disabled. If the user confirms to repair, then we will create the automatic passphrase file, and then change all unprotected keys to be protected by it. This creates the intended configuration and the required consistency.

However, our check might discover that there are some protected key, that is, secret keys that are protected by a passphrase. This situation isn't produced by the Enigmail import. I suggest to handle this scenario nevertheless, to cover future possible failures that some users might experience (for example file corruption, or manually deleted files, or other future bugs). I'd like to inform the user if this scenario is detected. We cannot automatically repair it. If keys are passphrase protected, and we don't have the file with the passphrase, there's nothing we can do. (We don't import protected keys as they are, we always attempt to unprotect them, before considering to import them.)

I suggest additional changes to make our code more robust.

The bug was made possible, by importing secret keys into temp storage, unprotecting them, then copying them to the permanent storage, then protecting them (which failed).

I'd like to change the logic in the following way, so that we won't import unprotected keys.
New logic: Import secret keys into temp storage, unprotecting them, protect them with the automatic passphrase, then copying them to the permanent storage.
This way, if protecting fails, our import will fail, and we avoid having unprotected keys.

In addition, I want to change the init code related to preference mail.openpgp.enable
Currently, changing the pref from false to true doesn't dynamically trigger required initialization to use the OpenPGP feature. Currently a restart is required.

We should add code that discovers the pref change from false to true, and perform all init automatically.
(But I don't want to dynamically disable if the pref is set to false at runtime, the feature will remain enabled until the end of the process lifetime.)