Bugzilla

Based on the comments that were given above, you have convinced me that my earlier suggestion for solving this bug shouldn't be done.

To summarize, I had earlier suggested to introduce a new global passphrase that would cover all OpenPGP passphrase. I no longer want to do that.

Instead, I want to offer the behavior that users know from GnuPG, that each secret key may be protected using an independent passphrase. That is, it's user choice whether the user wishes to use the same passphrase for all their keys, or separate passphrases for their keys.

Now, the challange for me was, how would I implement this mode.

Because Thunderbird currently supports the modes "protection based on a global primary password" and "no protection if no primary password is set", I cannot drop those modes. Note that those modes were pre-existing in Thunderbird, they had been always used with secret keys for S/MIME certificates. So initially, for consistency, it was easiest to use the same behavior for OpenPGP secret keys, too. (Justification, because at the time we had to integrate Enigmail, there were too many work items, and I had to simplify wherever possible.)

This means, going forward, Thunderbird will have to support different protection modes for OpenPGP secret keys in parallel.

I have worked on an enhancement, which implements the following behavior:

Using TB's OpenPGP Key Manager, when viewing the details of a key pair, the current passphrase protection mode for the key is shown.

For all existing keys from past TB operation, it will display it either as "unprotected" (which in fact means an automatic passphrase is used for the underlying key storage, but that passphrase can be accessed automatically), or as "protected using Thunderbird's primary password".

That screen, which displays the current status of passphrase protection, will offer the user to change the protection mode for this particular key (including its subkeys).

Once a key has been changed in that way, and an individual passphrase has been set, TB will prompt the user to unlock the key, prior to signing/decrypting or other private key modifications (e.g. revoking or changing expiration).

I have an initial implementation that seems to work. The following parts are not yet implemented:

- timeout based caching for passwords.
  Currently, if a used defined passphrase is configured, it must be entered for each operation

- once timeout based caching is implemented, a global way to clear the cached passwords

- asking the user for their preferred mode of passphrase protection when importing or generating a new key

I want to implement those remaining pieces. I just don't know if I complete everything in time for this year's 115 release.

We have a "user interface string freeze" on May 11. I want to try to get all necessary strings into shape before that date. If I succeed, I might have time until early June to finalize the functionality.

I couldn't work on this earlier, there were too many other priority work items waiting for me during the past year. But at least we're making progress. So, should I fail to get this feature done in time for this year's major 115 release, there's hope that it would be available in the Beta versions that we release throughout the following year.

Of course, this all also depends on acceptance of this new approach, both from TB's code and UI reviewers, and I'd also like to listen to you, the community, whether this now appears to be better approach, an approach that makes sense to you.

I'd like to provide a test binary with this functionality, with the current (incomplete) implementation, and I'd appreciate feedback, based on the combination of this explanation and the functional behavior that you can test.

Based on the comments that were given above, you have convinced me that my earlier suggestion for solving this bug shouldn't be done.

To summarize, I had earlier suggested to introduce a new global, common passphrase that would cover all OpenPGP keys. I no longer want to do that.

Instead, I want to offer the behavior that users know from GnuPG, that each secret key may be protected using an independent passphrase. That is, it's user choice whether the user wishes to use the same passphrase for all their keys, or separate passphrases for their keys.

Now, the challange for me was, how would I implement this mode.

Because Thunderbird currently supports the modes "protection based on a global primary password" and "no protection if no primary password is set", I cannot drop those modes. Note that those modes were pre-existing in Thunderbird, they had been always used with secret keys for S/MIME certificates. So initially, for consistency, it was easiest to use the same behavior for OpenPGP secret keys, too. (Justification, because at the time we had to integrate Enigmail, there were too many work items, and I had to simplify wherever possible.)

This means, going forward, Thunderbird will have to support different protection modes for OpenPGP secret keys in parallel.

I have worked on an enhancement, which implements the following behavior:

Using TB's OpenPGP Key Manager, when viewing the details of a key pair, the current passphrase protection mode for the key is shown.

For all existing keys from past TB operation, it will display it either as "unprotected" (which in fact means an automatic passphrase is used for the underlying key storage, but that passphrase can be accessed automatically), or as "protected using Thunderbird's primary password".

That screen, which displays the current status of passphrase protection, will offer the user to change the protection mode for this particular key (including its subkeys).

Once a key has been changed in that way, and an individual passphrase has been set, TB will prompt the user to unlock the key, prior to signing/decrypting or other private key modifications (e.g. revoking or changing expiration).

I have an initial implementation that seems to work. The following parts are not yet implemented:

- timeout based caching for passwords.
  Currently, if a used defined passphrase is configured, it must be entered for each operation

- once timeout based caching is implemented, a global way to clear the cached passwords

- asking the user for their preferred mode of passphrase protection when importing or generating a new key

I want to implement those remaining pieces. I just don't know if I complete everything in time for this year's 115 release.

We have a "user interface string freeze" on May 11. I want to try to get all necessary strings into shape before that date. If I succeed, I might have time until early June to finalize the functionality.

I couldn't work on this earlier, there were too many other priority work items waiting for me during the past year. But at least we're making progress. So, should I fail to get this feature done in time for this year's major 115 release, there's hope that it would be available in the Beta versions that we release throughout the following year.

Of course, this all also depends on acceptance of this new approach, both from TB's code and UI reviewers, and I'd also like to listen to you, the community, whether this now appears to be better approach, an approach that makes sense to you.

I'd like to provide a test binary with this functionality, with the current (incomplete) implementation, and I'd appreciate feedback, based on the combination of this explanation and the functional behavior that you can test.