Thunderbird 78.x and enabling OpenPGP by default
Kai Engert
we have identified several aspects of the integrated OpenPGP
implementation for TB 78 that should get improved, prior to declaring
the functionality as stable.
After discussions with Magnus we'd like to suggest that the 78.2 update
should be the first version that enables OpenPGP by default.
In other words, OpenPGP support would still be disabled by default in
the initial 78.0 release.
We'd like to add a preference that allows early adoptors who understand
the limitations of the OpenPGP implementation to enable the
functionality in the 78.0 release.
Beta and Nightly builds would continue to enable the feature by default.
This schedule would give us 2 more months, until end of July, to work on
important improvements and uplift them into the release branch. The 78.2
release is scheduled for 2020-08-25.
Thanks and Regards
Kai
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
Bardot Jérôme
if we can be sure it can easily use in some uses cases that include
mobile device (like smartphone) in order to not make (not powered) users
crazy.
Kai Engert
> I think this kind of functionalities should only be activate by default
> if we can be sure it can easily use in some uses cases that include
> mobile device (like smartphone) in order to not make (not powered) users
> crazy.
Hello Bardot,
please let me explain my original message in more detail, because there
might have been a misunderstanding.
We don't suggest to automatically enable encryption for emails.
The OpenPGP feature enhancement will allow the *optional* use of
encryption and digital signatures.
However, to offer the OpenPGP feature to users, the functionality should
be considered sufficiently stable and complete.
We're not there yet. We'd like to take two more months to develop
further improvements for the new OpenPGP feature.
The usual time to release new features is at the time of a new major
release. So the natural timing would be the 78.0 release, which is
scheduled for end of June.
However, because the schedule of the 78.0 release depends on external
factors (we don't want to change the schedule of the 78.0 release), and
because the new OpenPGP feature isn't yet sufficiently complete, we want
to deviate from that usual approach.
To prevent that users will discover and use a feature, we have the
technical ability to disable the feature, and hide it in the user interface.
That's what we suggest to do: For the initial Thunderbird 78.0 release,
don't yet offer the new OpenPGP feature by default. Keep it disabled by
default. Hide the related user interface by default. Make it impossible
for users to discover the new feature.
Nevertheless, the feature is included in the shipped product. It's just
disabled by default.
We'd also add a new (hidden) configuration option. Users of Thunderbird
78.0, who are willing to test the feature and accept the limitations,
would be able to change that hidden configuration option, and be able to
make use of the OpenPGP feature.
The suggestion is to keep the functionality fully turned off and hidden
by default, for both the Thunderbird 78.0 and 78.1 releases.
However, because the old Thunderbird 68.x version will no longer get
security updates after September, and because the Enigmail OpenPGP
Add-on can no longer be used with Thunderbird 78.x, we want to deliver
the new functionality in Thunderbird 78.x as soon as possible, this
year, before support for Thunderbird 68.x ends.
We hope that Thunderbird 78.2 will be the version that can enable the
new OpenPGP feature by default, meaning, that the related user interface
will be enabled, that the automatic processing of arriving messages will
work, and that users will be able to discover the new feature.
The user would still be required to opt in, by using the Mail account
preferences to configure and enable the active use of the OpenPGP
feature for a specific Mail account.
Jacques Angevelle
You say that the functionality will be disabled and hidden AND Enigmail can no longer be used. For users who use OpenPGP for some messages, that means they will see a major regression if they want to be early adopters of 78.x but can't assume risk of using beta. What is the problem that would prevent leaving the function visible as keys absence prevents it from being used?
Regards
Jacques
Magnus Melin
While it's not unproblematic to delay exposing the built-in OpenPGP functionality, existing Enigmail users would have to take that choice: enable the preference to enable OpenPGP (accepting it's a bit rough around the edges), or use 68.x until the pref is on by default.
Delaying will give us more time to verify things function as they
should as well as doing some basic UI improvements.
-Magnus
Ben Bucksch
First off, I'm happy that you're working on native PGP support for
Thunderbird. This has been the most voted for feature for the longest
time (almost 2 decades) for Thunderbird. I'm also glad that you found a
good base implementation. I know you've worked on SSL in Firefox since
1-2 decades, so I'm happy that we have a competent developer working on
this.
You asked what we think: If you feel that the implementation is not
ready, I think it makes a lot of sense to ship the code and disable it
in the UI, and finish it. That is a very reasonable approach, from a
code merge, stability and end user perspective.
To accommodate existing enigmail users, given that Enigmail won't work
with 78.0, and avoiding that they fall into a hole, how about enabling
at least email decryption and sending? And do that automatically?
This would be implemented by shiping an "Enigmail" update specifically
for 78.x, which does not contain the old Enigmail implementation (which
doesn't work anymore), but effectively does nothing but setting the
preference to allow PGP email decryption and sending. Every one of the
Enigmail users need that. This update avoids that every one of those
users needs to discover that their email is broken (or even that they
accidentally send unencrypted emails!) and manually search for the
preference. It avoids that Enigmail users are broken by 78.0.
Greetings,
Ben
Wayne
Hello Kai,
You say that the functionality will be disabled and hidden AND Enigmail can no longer be used. For users who use OpenPGP for some messages, that means they will see a major regression if they want to be early adopters of 78.x but can't assume risk of using beta.
I'm not sure I totally understand this point. Is it the new
encryption that you don't trust during beta, or Thunderbird code
that you don't trust?
You understand that what will soon be running during the 78 beta
period is not much different from what will actually ship in
78.0?
Do you also know that you can run two releases concurrently?
Kai Engert
> You say that the functionality will be disabled and hidden AND Enigmail
> can no longer be used. For users who use OpenPGP for some messages, that
> means they will see a major regression if they want to be early adopters
> of 78.x but can't assume risk of using beta.
Either you're an early adaptor who accepts the risks of using OpenPGP
code that we still consider beta quality, then you can upgrade to TB 78
manually and enable the feature manually,
or you prefer to use stable code, then you stay on TB 68 and Enigmail
for two additional months.
> What is the problem that
> from being used?
The problem is that users who expect a stable experience would upgrade
to TB 78 and run into the problems we haven't yet fixed.
If you haven't seen the ToDo list:
https://wiki.mozilla.org/index.php?title=Thunderbird:OpenPGP:Status
We want to fix the most important issues from that list, before we
enable it by default.
Kai Engert
>
> To accommodate existing enigmail users, given that Enigmail won't work
> with 78.0, and avoiding that they fall into a hole, how about enabling
> at least email decryption and sending? And do that automatically?
Can you please clarify what behavior you have in mind with "sending"? We
cannot enable encryption unless we have public keys migrated properly,
and treat signed public keys (signed by yourself) as "acceptable for
encryption".
I think we won't yet upgrade 68.x users automatically to 78.x, and
document the OpenPGP status in the 78 release notes. So people won't
"fall into a hole" unless they upgrade proactively.
I think we shouldn't enable the feature partially. I think that would be
even more confusing to understand why some things work and others don't.
> This would be implemented by shiping an "Enigmail" update specifically
> for 78.x, which does not contain the old Enigmail implementation (which
> doesn't work anymore), but effectively does nothing but setting the
> preference to allow PGP email decryption and sending.
automatically upgrade all existing Enigmail users, who are expecting a
stable experience.
> Every one of the
> Enigmail users need that.
with no more security fixes, which will be after 78.3 is released. By
then, we should be able to enable OpenPGP in 78 by default.
> This update avoids that every one of those
> users needs to discover that their email is broken (or even that they
> accidentally send unencrypted emails!) and manually search for the
> preference. It avoids that Enigmail users are broken by 78.0.
shouldn't yet upgraed to 78.0 but wait a little longer.
Ben Bucksch
> On 27.05.20 13:27, Ben Bucksch wrote:
> >
> > To accommodate existing enigmail users, given that Enigmail won't work
> > with 78.0, and avoiding that they fall into a hole, how about enabling
> > at least email decryption and sending? And do that automatically?
>
> Decryption requires the migration to have been completed correctly.
>
> Can you please clarify what behavior you have in mind with "sending"?
> We cannot enable encryption unless we have public keys migrated
> properly, and treat signed public keys (signed by yourself) as
> "acceptable for encryption".
and import from EnigMail and gpg are working already, but with no or
minimal or suboptimal UI. I imagined that key management UI is complex
and probably something you left for the end. However, if the migration
without UI doesn't work yet either (I don't know the exact status), then
of course my proposal does not work.
>
> I think we won't yet upgrade 68.x users automatically to 78.x, and
> document the OpenPGP status in the 78 release notes.
for users of a specific extensions.
> So people won't "fall into a hole" unless they upgrade proactively.
people who do upgrade.
With the additional downgrade block for their profiles that is in the
current release, that would make them all into the hole.
> I think we shouldn't enable the feature partially.
* Enable the feature much earlier for existing users of Enigmail, and
particularly for those that manually upgrade to 78.
* Prioritize the backend functions including key migration, email
sending and reading (encryption and signing, decryption and verification).
* Put key management UI on the back burner
>
>
> > This would be implemented by shiping an "Enigmail" update specifically
> > for 78.x, which does not contain the old Enigmail implementation (which
> > doesn't work anymore), but effectively does nothing but setting the
> > preference to allow PGP email decryption and sending.
>
> If we consider the feature as not yet ready, it seems risky to
> automatically upgrade all existing Enigmail users, who are expecting a
> stable experience.
My proposal is a path for those Enigmail users who manually install
Thunderbird 78.0 upon release, not knowing that PGP doesn't work yet.
> The plan would require that we properly announce that users of
> Enigmail shouldn't yet upgraed to 78.0 but wait a little longer.
they will not. Either because they didn't see the page where you wrote
it, or they skimmed over it and missed it.
Kai Engert
>
> I was assuming that the features for sending encrypted mail, decryption,
> and import from EnigMail and gpg are working already, but with no or
> minimal or suboptimal UI. I imagined that key management UI is complex
> and probably something you left for the end.
Processing of revocations isn't yet hooked up and tested. Extending the
lifetime of your key isn't yet implemented in the UI. We don't yet save
encrypted drafts, we don't yet keep the "encrypt" flag across a saved
draft. We don't yet automatically treat keys that you have already
signed yourself as accepted. We don't yet discover/recover a missing
MDC. We crash with some real world keys and are waiting for RNP library
fixes.
Believe me, if you start with real world keys and real world messages,
you'll quickly notice that many edge cases aren't working correctly yet,
and you don't want to use it as your primary OpenPGP client just yet.
We need a little more time to do our homework, and we'll need more readl
world testing, where problems with common scenarios are discovered,
reported and can get fixed. We shouldn't declare all current Enigmail
users as Beta testers - but start with a group of volunteer testers.
Kai
Ben Bucksch
I completely respect it when you as developer say that it's not ready yet.
Just to clarify one thing, so that we don't misunderstand each other:
On 28.05.20 00:33, Kai Engert wrote:
> We shouldn't declare all current Enigmail users as Beta testers
What about those Enigmail users who *do* manually install TB 78.0? They
cannot use Enigmail anymore. They cannot downgrade anymore, because TB
blocks profile downgrades. They are stuck without any encryption. They
cannot even read their encrypted mail. I am talking specifically about
those.
Kai Engert
> What about those Enigmail users who *do* manually install TB 78.0? They
> cannot use Enigmail anymore. They cannot downgrade anymore, because TB
> blocks profile downgrades. They are stuck without any encryption. They
> cannot even read their encrypted mail. I am talking specifically about
> those.
the number of users who will run into that situation, but it seems
difficult to completely avoid it.
Enigmail could open a tab (each time Thunderbird gets started) with a
warning that says "reminder, please continue to use Thunderbird 68.x
until August-25 because ...".
Or we could try to add a check to Thunderbird 78 that is executed very
early during the startup code (before any profile migration code runs),
which checks if the Enigmail Add-on is present in the profile. If it is,
show a warning "You have the Enigmail Add-on installed, which is no
longer supported by this version of Thunderbird. Integrated OpenPGP
support is under active development, and expected to be ready by
August-25. Please continue to use TB 68 until August-25. Thunderbird
will now quit."
Delaying the stable 78.x release until OpenPGP is sufficiently complete
would be an easier and more reliable approach (e.g. declare 78.0 and
78.1 as beta versions), but in my understanding this isn't an option.
Kai
Jacques Angevelle
Perhaps add a comment : "if you need to install TB 78, you must remove
Enigmail" .
Another question is future use of GPG4Win, GPA & Kleopatra which are
companions of Enigmail for Windows OS. Will keyring be shared with OpenPGP?
Jacques
Le 28/05/2020 à 01:57, Kai Engert a écrit :
> Or we could try to add a check to Thunderbird 78 that is executed very
> early during the startup code (before any profile migration code
> runs), which checks if the Enigmail Add-on is present in the profile.
> If it is, show a warning "You have the Enigmail Add-on installed,
> which is no longer supported by this version of Thunderbird.
> Integrated OpenPGP support is under active development, and expected
> to be ready by August-25. Please continue to use TB 68 until
> August-25. Thunderbird will now quit."
_______________________________________________
Kai Engert
> Another question is future use of GPG4Win, GPA & Kleopatra which are
> companions of Enigmail for Windows OS. Will keyring be shared with OpenPGP?
Thunderbird 78 will not use GnuPG in its default configuration, so you
will not be able to use them with Thunderbird's internal keyring.
No, currently the intention is that the Thunderbird keyring is
considered internal data, stored in the Thunderbird profile directory,
managed by Thunderbird, only.
Kai
Matt Connell
> Thunderbird 78 will not use GnuPG in its default configuration, so you
> will not be able to use them with Thunderbird's internal keyring.
>
> No, currently the intention is that the Thunderbird keyring is
> considered internal data, stored in the Thunderbird profile directory,
> managed by Thunderbird, only.
in the thread.
Does this affect Linux users?
That is to say, will there be an option to use GnuPG, as I am doing now
with Enigmail? I would guess that I am not alone in using my GPG keys
for other uses/applications other than Thunderbird, and I would hate to
have to maintain a separate subkey if Thunderbird can't utilize the
existing GPG agent.
TT Mooney
So best practice would be for everything to leave a Thunderbird decrypted. But that needs to be very clear to the user.
I think I’d be more comfortable with an external private key, but I’m also really interested in a working configuration that’s maintainable.
T
Sent from my iPad
> On 28 May 2020, at 20:36, Kai Engert <ka...@kuix.de> wrote:
Kai Engert
> On 2020-05-28 14:36, Kai Engert wrote:
>> Thunderbird 78 will not use GnuPG in its default configuration, so you
>> will not be able to use them with Thunderbird's internal keyring.
>>
>> No, currently the intention is that the Thunderbird keyring is
>> considered internal data, stored in the Thunderbird profile directory,
>> managed by Thunderbird, only.
>
> Apologies if this is an obvious question; I may have missed the answer
> in the thread.
>
> Does this affect Linux users?
We will use the same implementation for all platforms.
RNP by default for all operations.
Only optionally, if we can get it done in time (maybe later), an option
to fall back to GnuPG for secret key operations, only (to support
smartcards).
Kai Engert
> What about the use case of people saving GPG encrypted attachments (or email archives) out of Thunderbird? They won’t be able to decrypt them externally, I take it.
You will have the ability to import your existing secret key into
Thunderbird (export from GnuPG with --armor).
And also, if a user has initially created the secret key inside
Thunderbird, you will have the ability to backup/export your secret key,
and import it into GnuPG.
Would that work for your scenario?
Jacques Angevelle
version, I also use GnuPG in OpenOffice and would be pleased to continue
without manual synchro between keyrings.
I think all OS is impacted. GPG solution could be described as TB using
an external keyring. With OpenPGP inside TB, external use is broken if
there no way to use this internal keyring everywhere in the OS.
Jacques
Le 28/05/2020 à 23:59, Matt Connell a écrit :
> Apologies if this is an obvious question; I may have missed the answer
> in the thread.
>
> Does this affect Linux users?
>
> That is to say, will there be an option to use GnuPG, as I am doing
> now with Enigmail? I would guess that I am not alone in using my GPG
> keys for other uses/applications other than Thunderbird, and I would
> hate to have to maintain a separate subkey if Thunderbird can't
> utilize the existing GPG agent.
Le 29/05/2020 à 12:33, TT Mooney a écrit :
> What about the use case of people saving GPG encrypted attachments (or email archives) out of Thunderbird? They won’t be able to decrypt them externally, I take it.
>
> So best practice would be for everything to leave a Thunderbird decrypted. But that needs to be very clear to the user.
>
> I think I’d be more comfortable with an external private key, but I’m also really interested in a working configuration that’s maintainable.
>
> T
Wayne Mery
On 28.05.20 01:03, Ben Bucksch wrote:
What about those Enigmail users who *do* manually install TB 78.0? They cannot use Enigmail anymore. They cannot downgrade anymore, because TB blocks profile downgrades. They are stuck without any encryption. They cannot even read their encrypted mail. I am talking specifically about those.
You're right that we should think about those users, and try to minimize the number of users who will run into that situation, but it seems difficult to completely avoid it.
Yes, we will wan to reduce that risk and provide a KB to get out of it if they find themselves in that predicament.
Enigmail could open a tab (each time Thunderbird gets started) with a warning that says "reminder, please continue to use Thunderbird 68.x until August-25 because ...".
Or we could try to add a check to Thunderbird 78 that is executed very early during the startup code (before any profile migration code runs), which checks if the Enigmail Add-on is present in the profile. If it is, show a warning "You have the Enigmail Add-on installed, which is no longer supported by this version of Thunderbird. Integrated OpenPGP support is under active development, and expected to be ready by August-25. Please continue to use TB 68 until August-25. Thunderbird will now quit."
Delaying the stable 78.x release until OpenPGP is sufficiently complete would be an easier and more reliable approach (e.g. declare 78.0 and 78.1 as beta versions), but in my understanding this isn't an option.
Kai
So Kai, Patrick, myself and others have discussed release
planning and the following is a draft plan (emphasis on draft,
subject to change). There will certainly also be point releases
as needed along the way which are not listed. Apologies for the
strange outline numbering, that's how it copied from the doc and
it's too painful to fix.
Steps (dates approximate, provided for planning purposes):
77 beta May 5
OpenPGP landed and available for testing
78 beta June 2
OpenPGP testing goals
Migration of keys and settings from Enigmail (that’s a good test case for TB/RNP because it tests the broad variety of keys that people have)
Key import & export
Email encryption
Email decryption
Testing instructions will be listed at https://wiki.mozilla.org/Thunderbird:OpenPGP - can be enabled by user.
OpenPGP documentation and location for user support will be provided at https://wiki.mozilla.org/Thunderbird:OpenPGP.
Have we gotten enough encryption beta testers and what is the quality of the feedback? Do we need to ask testers for something different? And where do we communicate to ask them?
68.9.0 (concurrent with 78 beta)
Enigmail x.y informs users not to attempt manual update via strongly worded notification
78.0 June 30 (concurrent with 68.10.0)
OpenPGP support disabled by default - can be enabled by user. Enigmail migrator migrates user data to OpenPGP.
68 to 78 background update rate set to 0
Have we gotten enough new encryption testers and feedback?
78.1.0 July 28 (concurrent with 68.11.0)
OpenPGP support disabled by default - can be enabled by user. Enigmail migrator migrates user data to OpenPGP.
68 to 78 background update rate set to 0(?)
Have we gotten enough new encryption testers and feedback?
78.2.0 August 25 (concurrent with 68.12.0)
OpenPGP support enabled by default
Enigmail migrator migrates user data to OpenPGP.
68 to 78 background update rate set to <TBD>?
78.3.0 Sept 22 (no 68.x to be released)
OpenPGP enabled / further refinement
68 to 78 background update rate set to <TBD>?
68 EOL
Enigmail EOL - at least 6 months after TB 68 EOL
Ben Bucksch
> On 29.05.20 12:33, TT Mooney wrote:
>> What about the use case of people saving GPG encrypted attachments
>> (or email archives) out of Thunderbird? They won’t be able to decrypt
>> them externally, I take it.
>
> You will have the ability to import your existing secret key into
> Thunderbird (export from GnuPG with --armor).
>
> And also, if a user has initially created the secret key inside
> Thunderbird, you will have the ability to backup/export your secret
> key, and import it into GnuPG.
>
> Would that work for your scenario?
Hello Kai,
While a commandline would work for me, I don't think it would work for
the majority of users. Most users never use the commandline. Any
features available there simply don't exist for them. This applies to
many of the Enigmail users. There are journalists, Amnesty
International, and many others who need encryption, but are not deep
into computers.
I think an import/export feature would be important. It doesn't have to
be complicated technically. You could just invoke gpg on the
commandline, run the export --armor command that you think the user
should do, catch the output on stdout, and process it to import the keys
into our / OpenPGP key store. And probably vise versa.
That would allow users to have a seamless and interruption free mail
experience would be important. If not, the user might find herself in a
situation where she cannot decrypt her own mail. Either because she uses
K9 Mail on Android, or because she wants to decrypt old mail. Also, you
are surely aware that the PGP world is particularly dependent on key
continuity, and creating new keys for our users is about the worst thing
we can do for the PGP ecosystem. So, key import and export are crucially
important for the health of the system, from day 1. Once the user has 2
separate keys, the mess is there, and it's difficult to undo. Alice has
to eternally deal with 2 decryption keys, and the trust is shaken.
I think a GPG import/export feature is actually more important than a
key management UI for OpenPGP. As long as you can only import the GPG
keys and decrypt/verify and encrypt/sign mail this way, the user can
already be productive, and mail exchange is not disturbed. If you create
new keys, mail exchange is disturbed massively, and the user might still
get mail that she cannot decrypt.
Instead of asking the user to make some simply commandline commands, I
think it's a good time investment to implement that in software.
Enigmail already has the path to the gpg executable, so you just need to
invoke a shell command from JS and redirect stdout.
Magnus Melin
> I think an import/export feature would be important. It doesn't have
> to be complicated technically. You could just invoke gpg on the
> commandline, run the export --armor command that you think the user
> should do, catch the output on stdout, and process it to import the
> keys into our / OpenPGP key store. And probably vise versa.
For existing Enigmail users the plan is to auto-import their existing
keys. This will happen through the Enigmail78 version which will just be
a migrator.
I think Kai was just referring to what one can do at the moment.
-Magnus
Ben Bucksch
>
> For existing Enigmail users the plan is to auto-import their existing
> keys. This will happen through the Enigmail78 version which will just
> be a migrator
Wayne
Correct, delaying releasing 78 for 1-2 months isn't an option.
It seems to me the idea you mention above is a very good one, give users an opportunity to opt out when starting up 78 and be able to go back to 68. But we are now past string freeze, so we need to very quickly navigate that issue.
I would not include dates - dates can change. I wouldn't even
mention releases. We can communicate that information in the
existing enigmail add-on when we know everything is ready.
Wayne
give users an opportunity to opt out when starting up 78 and be able to go back to 68.
So the steps for 78.0 and 78.1 need to add
d. Inform engimail users that they might not want to be using
version 78, and offer link to instructions of how to get back to
version 68.
Ben Bucksch
68.9.0 (concurrent with 78 beta)
Enigmail x.y informs users not to attempt manual update via strongly worded notification
This made the frontpage of the largest IT news site in Germany:
https://www.heise.de/news/Enigmail-warnt-Nutzer-vor-manuellem-Update-auf-Thunderbird-78-4799240.html
The biggest security threat these days is that people or vendors do not make updates. Many Thunderbird users are reluctant to make updates, because they fear regressions. I am scared that this message will reinforce the idea of users that updates are bad. It is this idea in the user's minds that causes the security disasters.
Wayne
I don't see anything in that article that is incorrect. The
message we wanted to get out is that in no uncertain terms should
Enigmail users update to 78 on their own at this time. When the
time is right, the messaging in Engimail will change as will our
external messaging, and users will be automatically updated to 78.
Enigmail is mentioned in the heise article several times, thankfully. If non-Enigmail users think from that article that they shouldn't update then apparently they don't know how to read.
That said, if there is better messaging then now is the time to
provide it. Ryan's blog post will be going out soon.
Nomis101
> We hope that Thunderbird 78.2 will be the version that can enable the
> new OpenPGP feature by default, meaning, that the related user interface
> will be enabled, that the automatic processing of arriving messages will
> work, and that users will be able to discover the new feature.
Can I kindly ask, what the status of the OpenPGP implementation is, now
that ESR had reached 78.2.0?
Wayne Mery
Am 26.05.20 um 19:36 schrieb Kai Engert:
We hope that Thunderbird 78.2 will be the version that can enable the
new OpenPGP feature by default, meaning, that the related user interface
will be enabled, that the automatic processing of arriving messages will
work, and that users will be able to discover the new feature.
Can I kindly ask, what the status of the OpenPGP implementation is, now
that ESR had reached 78.2.0?
We decided to take one more important pgp patch for 78.2.0, and
therefore have delayed the enabling of OpenPGP by default to
78.2.1.
Wolfgang Rosenauer
I'm wondering what the latest status is on smartcard (incl. yubikey)
support?
There were some mails in December last year about some ideas but I
haven't seen any update.
Thanks,
Wolfgang
Am 25.08.20 um 12:06 schrieb Wayne Mery:
Kai Engert
> I'm wondering what the latest status is on smartcard (incl. yubikey)
> support?
> There were some mails in December last year about some ideas but I
> haven't seen any update.
https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards
Kai