Thunderbird 78, Enigmail and OpenPGP secure email
Kai Engert
https://blog.mozilla.org/thunderbird/2019/10/thunderbird-enigmail-and-openpgp/
Two popular technologies exist that add support for end-to-end
encryption and digital signatures to email. Thunderbird has been
offering built-in support for S/MIME for many years, and will continue
to do so.
The Enigmail Add-on has made it possible to use Thunderbird with
external GnuPG software for OpenPGP messaging.
Because Thunderbird 78 will no longer support classic Add-ons, the
current Thunderbird 68.x branch (maintained until Fall 2020) will be the
last that can be used with Enigmail.
As a replacement, the Thunderbird team intends to develop integrated
OpenPGP messaging for the next major version of Thunderbird, which will
be released in summer 2020 (likely version 78).
We are happy that Patrick Brunschwig, who has been developing and
maintaining the Enigmail Add-on for many years, has offered to assist
the Thunderbird development team.
Many details need to be considered for this initiative.
Please have a look at the following article which describes the approach
we'd like to take:
https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
If you have feedback, please post it to this list.
This feature was originally requested in
https://bugzilla.mozilla.org/show_bug.cgi?id=22687
Kai
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
Ludovic Hirlimann
> Please have a look at the following article which describes the approach
> we'd like to take:
> https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
>
> If you have feedback, please post it to this list.
Are you considering leveraging Pronto mail's PGP library (like bugzilla
did a year or so ago) ?
(it doesn't support all encryption protocols, has issues with big keys
(like mine was over 800kb with signatures).
Are we following
https://latacora.singles/2019/07/16/the-pgp-problem.html to make sure
gpg/pgp in thunderbird will follow the new standard and make the wot
more usable ?
Regarding S/Mime the issue I had with it was renewing certs and these
days Find a cert issuer - there's probably oportunities for TB to
partner with someone and get some €€€ throught a S/mime partnersip (eg
referal from tb - someone pays for a cert and Tb get's revenue from it).
Final note I'm very happy to get this email today - because the main
reason I use TB is that I can easily use pgp with it. Thanks Patrick
(and Hi ). Thanks kaie.
Ludo
--
https://www.hirlimann.net/Ludovic/carnet/
Patrick Cloke
Awesome news! I think this is an important feature to bring to our users.
Will there be a migration path from users who are using Enigmail to
Thunderbird native PGP? I understand that not all options, etc. will
want to be supported, but having to not setup PGP again would be nice.
Looking forward to seeing this in Thunderbird!
--Patrick
Kai Engert
> Are you considering leveraging Pronto mail's PGP library (like bugzilla
> did a year or so ago) ?
Are you referring to https://github.com/ProtonMail/openpgpjs ?
That library is a potential candidate for a library that supports
OpenPGP message, its LGPL license could allow us to bundle it with
Thunderbird.
However, looking at the output of "npm-remote-ls openpgp", it has a
large set of dependencies.
In my understanding, if we decided to use OpenPGP.js we'd have to bundle
it together will all its dependencies. To keep those attack vectors
under control, we'd probably have to watch all those dependencies for
security issues, and publish an updated Thunderbird version for every
security incident related to any of those dependent libraries.
Also, bundling might not be acceptable for some downstream distributors,
like Debian, which distributes individual node packages. We'd have to
ensure our bundled OpenPGP.js works with the system module versions
available on downstream consumer system.
Because of the above, it seems preferable to use a C/C++ or Rust library
for OpenPGP message processing.
> Are we following
> https://latacora.singles/2019/07/16/the-pgp-problem.html to make sure
> gpg/pgp in thunderbird will follow the new standard and make the wot
> more usable ?
This article makes very critical statements about PGP in general, such
as not using PGP for encrypting email at all, which is obviously
contrary to our intention.
When you mention a new standard, can you please point out to which part
of the article you're reffering?
It's not yet clear if, or how, or how soon, we might support the Web Of
Trust.
> Regarding S/Mime the issue I had with it was renewing certs and these
> days Find a cert issuer - there's probably oportunities for TB to
> partner with someone and get some €€€ throught a S/mime partnersip (eg
> referal from tb - someone pays for a cert and Tb get's revenue from it).
It might be best to have a separate thread for discussing challenges
with S/MIME.
As a quick reply, I share the impression that the availability of
publicly trusted certificates for personal use with email security seems
to have decreased, especially when considering certificates available
for no cost. And Firefox has recently removed support for the HTML
keygen tag, which will make it more complicated to obtain such
certificates, as it will likely require the use of external command line
tools to create a key pair with the private key only being stored on the
user's own computer.
The use of S/MIME might be more appropriate for corporate or
organizational environments, while OpenPGP might be better suited for
communication between private users, because it doesn't require to
involve a third party CA to get started.
Kai
Kai Engert
> Will there be a migration path from users who are using Enigmail to
> Thunderbird native PGP? I understand that not all options, etc. will
> want to be supported, but having to not setup PGP again would be nice.
Kai
Patrick Cloke
> On 08.10.19 13:50, Patrick Cloke wrote:
>> Will there be a migration path from users who are using Enigmail to
>> Thunderbird native PGP? I understand that not all options, etc. will
>> want to be supported, but having to not setup PGP again would be nice.
> Yes, at least for the keys the user already owns.
>
> Kai
--Patrick
Ludovic Hirlimann
Are we following https://latacora.singles/2019/07/16/the-pgp-problem.html to make sure gpg/pgp in thunderbird will follow the new standard and make the wot more usable ?This article makes very critical statements about PGP in general, such as not using PGP for encrypting email at all, which is obviously contrary to our intention. When you mention a new standard, can you please point out to which part of the article you're reffering?
And that's me forgetting that it was in an other article :
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
Ludo
Ludovic Hirlimann
> organizational environments, while OpenPGP might be better suited for
> communication between private users, because it doesn't require to
> involve a third party CA to get started.
any S/mime message, or even an org managing a CA for that purpose the
last one I know of died in 2009.
I'm raising the issue , but I'm not proposing any soution, but is s/mime
support worth keeping ?
Ludo
Wiktor Kwapisiewicz
> As a replacement, the Thunderbird team intends to develop integrated
> OpenPGP messaging for the next major version of Thunderbird, which will
> be released in summer 2020 (likely version 78).
That's great to hear! Given the number of people that use Thunderbird
daily providing built-in OpenPGP can tremendously lower the effort
needed to encrypt e-mails.
> Please have a look at the following article which describes the approach
> we'd like to take:
> https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
The wiki page is very well written. If you don't mind I've got a few
minor comments:
> We intend to identify and use another existing library that provides support for creating and processing OpenPGP messages, and we will try to reuse parts of Enigmail that aren’t specific to GnuPG.
As far as I know there are two: OpenPGP.js, that is re-used by the
Autocrypt extension [1] and Sequoia [2], that is native and AFAIK
provides a way to talk to GnuPG agent (for keys stored on smartcards).
[1]: https://addons.thunderbird.net/en-US/thunderbird/addon/autocrypt/
> It’s a controversial question whether email software should automatically use opportunistic encryption, or whether the user should be required to actively opt in, prior to using end-to-end email encryption.
The old OpenPGP e-mail header specified "preference" field [3].
[3]:
https://datatracker.ietf.org/doc/html/draft-josefsson-openpgp-mailnews-header-07#section-3.3
> Furthermore, starting to use OpenPGP comes with some responsibility for the future. Once a user distributes their own key to others, they’ve opened Pandora’s box. Others might discover the keys later and send encrypted email at any time in the future.
This can be (somehow) mitigated by using "Let's Encrypt approach". If we
assume a keyserver would be used then setting a short expiry on the user
key and then extending it every couple of months automatically (with no
user input) would provide a "dead man's switch" that'd render the key
unusable if the user stops using Thunderbird.
> For the initial version of Thunderbird with OpenPGP support, Thunderbird 78, we’ll not yet enable OpenPGP encryption for emails automatically. Instead, we’ll require that users opt in, prior to using it. However, it should be easy to opt in, and we might implement a smart user interface, that allows the user to discover the the availability of the OpenPGP messaging features, and offer interactive assistance that makes it easy to get started.
This could also be coupled with something like that "OpenPGP" header,
for example replying to a contact that indicated that they prefer
encrypted e-mail could trigger a bar similar to "forgotten attachment"
asking the user to generate OpenPGP keys.
Thanks for the work in this area!
Kind regards,
Wiktor
--
https://metacode.biz/@wiktor
Kai Engert
> but is s/mime support worth keeping ?
sufficient reason to remove it.
Even if not using S/MIME actively, Thunderbird users can passively
benefit from S/MIME support, by being able to verify the digital
signature in emails. I frequently receive digitally signed S/MIME email
sent to me by banks, companies, insurances or the post office.
Also, I assume there are many corporate Thunderbird users who are still
happy that we support S/MIME.
Kai
Kai Engert
>>
>> When you mention a new standard, can you please point out to which part
>> of the article you're reffering?
>
> And that's me forgetting that it was in an other article :
> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
https://wiki.mozilla.org/Thunderbird:OpenPGP:2020#Key_sharing
Kai Engert
On 08.10.19 13:44, Wiktor Kwapisiewicz wrote:
>> We intend to identify and use another existing library that provides
>> support for creating and processing OpenPGP messages, and we will try
>> to reuse parts of Enigmail that aren’t specific to GnuPG.
>
> As far as I know there are two: OpenPGP.js, that is re-used by the
> Autocrypt extension [1] and Sequoia [2], that is native and AFAIK
> provides a way to talk to GnuPG agent (for keys stored on smartcards).
Thunderbird is distributed under the MPL 2.0 license.
The Sequoia PGP library code uses the GPL v3 license.
IANAL, but in my understanding it means that Thunderbird cannot bundle
the Sequoia library, and therefore it cannot be used.
Another potential option is the RNP [4] library, which depends on the
Botan [5] crypto library.
[4] https://www.rnpgp.com/software/rnp/
[5] https://botan.randombit.net/
Kai
neandr
https://blog.mozilla.org/thunderbird/2019/10/thunderbird-enigmail-and-openpgp/
Two popular technologies exist that add support for end-to-end
encryption and digital signatures to email. Thunderbird has been
to do so.
The Enigmail Add-on has made it possible to use Thunderbird with
external GnuPG software for OpenPGP messaging.
Because Thunderbird 78 will no longer support classic Add-ons, the
current Thunderbird 68.x branch (maintained until Fall 2020) will be the
last that can be used with Enigmail.
OpenPGP messaging for the next major version of Thunderbird, which will
be released in summer 2020 (likely version 78).
maintaining the Enigmail Add-on for many years, has offered to assist
the Thunderbird development team.
Many details need to be considered for this initiative.
we'd like to take:
https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
This feature was originally requested in
https://bugzilla.mozilla.org/show_bug.cgi?id=22687
Tanstaafl
earlier in this thread...
My question is, is this the result of working with and integrating P=P,
which was discussed last year (and possibly early this year)?
Or is this entirely different?
If different, I would like to hear what happened,m because we were all
promised news on this work but nothing ever materialized, that I saw,
but maybe I missed it.
Thanks,
Charles
On Tue Oct 08 2019 04:29:32 GMT-0400 (Eastern Standard Time), Ludovic
Hirlimann <lud...@mozilla.com> wrote:
> On 10/8/19 9:20 AM, Kai Engert wrote:
>> Please have a look at the following article which describes the approach
>> we'd like to take:
>> https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
>>
>> If you have feedback, please post it to this list.
>
>
> Are you considering leveraging Pronto mail's PGP library (like bugzilla
> did a year or so ago) ?
>
> (it doesn't support all encryption protocols, has issues with big keys
> (like mine was over 800kb with signatures).
>
>
> Are we following
> https://latacora.singles/2019/07/16/the-pgp-problem.html to make sure
> gpg/pgp in thunderbird will follow the new standard and make the wot
> more usable ?
>
>
> Regarding S/Mime the issue I had with it was renewing certs and these
> days Find a cert issuer - there's probably oportunities for TB to
> partner with someone and get some €€€ throught a S/mime partnersip (eg
> referal from tb - someone pays for a cert and Tb get's revenue from it).
>
>
> Final note I'm very happy to get this email today - because the main
> reason I use TB is that I can easily use pgp with it. Thanks Patrick
> (and Hi ). Thanks kaie.
>
>
> Ludo
>
_______________________________________________
Phillip Hallam-Baker
Magnus Melin
There has been no real developments on the Thunderbird - pEp
front. The status of those discussions is still at the same stage
they were some years ago: we're still awaiting an initial alpha
prototype that can be evaluated, and after that further
discussions would be had. (Re the prototype, we've been told, pEp
in Enigmail is not it.)
The pEp mode of Enigmail will not be included in the Thunderbird
OpenPGP integration. AFAIK pEp has abandoned using Enigmail as the
delivery mechanism for their technology and are working some kind
of alternative pEp integration for Thunderbird.
-Magnus
Magnus Melin
See my other tb-planning post from a few minutes ago for current status
of Thunderbird and pEp.
-Magnus
Ludovic Hirlimann
TLDR; If any of you here will be at the Singapore IETF, we need to talk.
I know mozillamessaging never did. and this raises another question : Is Thunderbird represented in any internet standard orgs ?
Ludo
Kai Engert
interesting ideas, but we might not be able to spend much with new
research ideas at this time. The Thunderbird release timing is rather
fixed, we'll need to ship a polished and production quality Beta release
by May next year. I'm afraid the limited development resources that we
have available in the security feature area might be fully consumed by
the migration from Enigmail to internal OpenPGP support.
On 08.10.19 20:28, Phillip Hallam-Baker wrote:
> What if Thunderbird was also an end-to-end secure chat client and it
> wasn't limited to a single service provider?
also close to shipping OTR, but we aren't yet ready to announce it.
Hopefully in a few weeks we'll do a call for testing.
Kai Engert
intensive. Paying for flight, hotel, the expensive IETF meeting fee, and
probably not being able to get other work done for about a week, three
times a year, seems like a significant investment to me. If one
implements technology, but doesn't actively define new standards, how
can such participation be justified?
Ben Bucksch
This is fantastic! Thanks for getting PGP included, and for getting Patrick Brunschwig on board. He’s a great guy and very competent developer. I would like to thank Patrick for his awesome work over all the years!
Security-wise, I am also happy to read the following: “To promote secure communication, Thunderbird 78 will encourage the user to perform ownership confirmation of keys used by correspondents, [and] notify the user if the correspondent’s keys change unexpectedly”
These 2 things are crucial for secure communication. If the key is not validated, somebody could be sitting in the middle. Even more important is the key change notification. Without that, somebody could get into the middle, read all messages, and the user would not notice.
This is missing in most “secure messaging” applications with so-called “crypto”, and without this key change notification, there is no trusted communication possible. Thank you that you took attention to such details.
Ben Bucksch
Thank you for your wise position on this. I'm glad to see that we have
crypto competence on board, with you and Patrick Brunschwig.
I completely agree with what you wrote there. It is the right choice,
given the current circumstances.
Here is a potential problem:
> For users who prefer to avoid unencrypted email completely, we might
> offer an advanced configuration, that could require all outgoing email
> to be encrypted, either using any available key, or by requiring the
> use of confirmed keys, only.
I am concerned by such an option. If some advanced or security-conscious
Thunderbird users would enable this, find keys for me, and I would not
be able to read my own mail.
You mention exactly my reason later:
> Once a user distributes their own key to others, they’ve opened
> Pandora’s box. Others might discover the keys later and send encrypted
> email at any time in the future. If the key has been lost, either
> because the computer broke and no backups of they are available, or
> because the user forgot the passphrase that was used to protect the
> key, the incoming encrypted email cannot be read. Also, if the key has
> been lost, the archive of encrypted email that’s still available on
> your mail server can no longer be read either.
I am in that position. I have multiple keys on key servers, because I
sign software. However, I read mail on multiple email clients. Mostly
Thunderbird, but also on Android (where TB doesn't exist). I do not wish
to put the valuable PGP keys that I use to sign software on my cell
phone just to read mail.
There's even a worse situation: An attacker might create a PGP key for
the victim (a normal unsuspecting user that never used Thunderbird nor
GPG), put it on a key server, and Thunderbird users would fetch the key,
encrypt mail to the victim, and the victim would not be able to read her
own mail anymore. So, such opportunistic encryption creates new attack
scenarios, comparable to a DoS (Denial of service) attack, but it would
be in the design and permanent. At least for such senders that enable
such a Thunderbird feature. That's why such a feature is problematic.
Ben Bucksch
organizations, esp. governments, are actively using it, in Thunderbird.
Wiktor Kwapisiewicz
On 09.10.2019 17:13, Kai Engert wrote:
> FYI, it already is. We support XMPP/Jabber and some others, and we're
> also close to shipping OTR, but we aren't yet ready to announce it.
> Hopefully in a few weeks we'll do a call for testing.
multiprotocol support?)
As far as I know OTR has been largely replaced by OMEMO in XMPP/Jabber.
Source:
https://wiki.xmpp.org/web/XMPP_E2E_Security#OTR_.28Off-the-record_Messaging.29
(see also comments about OMEMO on that page).
John Bieling
DNSSEC which I think solves the trust issue. There is/was even an addon
https://addons.thunderbird.net/addon/great-dane-smime/
I use S/MIME and I would be sad if it got removed from Thunderbird.
Why do we always have that discussion to remove stuff from thunderbird?
S/MIME is a standard, isn't it?
John
> On 08.10.19 14:02, Ludovic Hirlimann wrote:
>> is s/mime support worth keeping ?
>
Patrick Cloke
> Hi Kai,
>
> On 09.10.2019 17:13, Kai Engert wrote:
>> FYI, it already is. We support XMPP/Jabber and some others, and we're
>> also close to shipping OTR, but we aren't yet ready to announce it.
>> Hopefully in a few weeks we'll do a call for testing.
>
> Is there a rationale somewhere why OTR was selected? (for example
> multiprotocol support?)
>
> As far as I know OTR has been largely replaced by OMEMO in XMPP/Jabber.
>
> Source:
> https://wiki.xmpp.org/web/XMPP_E2E_Security#OTR_.28Off-the-record_Messaging.29
>
>
> (see also comments about OMEMO on that page).
>
OTR is cross protocol, which fits nicely into what Thunderbird supports.
It is unfortunately hard to get a clear picture of what is worth
implementing for XMPP (i.e. how many users exist that support different
end-to-end encryption technologies). The major downside, in my
understanding, is that OTR does not support multi-user chats. I'm sure
there are some others, but OTR seemed like a good place to start.
There's a bug [1] about implementing OMEMO for anyone who is interested!
--Patrick
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1237416
ba
No details about pEp. Do I miss a statement TB isn't going with pEp anymore?AFAIK pEp is installed with Egnimail, so if Egnimail stops working with >68 which role will pEp play in the future for TB?
Phillip Hallam-Baker
Will
> On 08.10.19 20:28, Phillip Hallam-Baker wrote:
>> What if Thunderbird was also an end-to-end secure chat client and it
>> wasn't limited to a single service provider?
> FYI, it already is. We support XMPP/Jabber and some others, and we're
> also close to shipping OTR, but we aren't yet ready to announce it.
> Hopefully in a few weeks we'll do a call for testing.
the other issues related to add ons, we'd like to know why TB is
spending presumably a lot of resources on chat client encryption?
TB is an email client right?
Why don't you concentrate on getting that bit right first?
There are mountains of unfixed bugs, APIs that are a mess, add ons that
we can't get to work and could do with help, and you are messing around
with chats and OTR?
Exactly what is the direction of travel for TB? Replace email with chat?
You are so late to that party.................
We don't need it - we already have a good chat system, with OTR if we
want it, and a pile of other functionality. Quite simply there are
already much better systems out there.
Chat in TB is just a waste of CPU and coding cycles IMHO. Beyond a
cursory look we have never used it. I'd rather see it dumped completely.
Obviously this has all been discussed behind closed doors? Why isn't the
community consulted about this sort of thing, or is it paying clients only?
<shakeshead>
Phillip Hallam-Baker
Magnus Melin
> we'd like to know why TB is
> spending presumably a lot of resources on chat client encryption?
Thunderbird is committed to ensuring free and private communications.
Not only for chat but email too, which the OpenPGP announcement would
have you know. I think in the larger view of things, ensuring
distributed end-to-end encryption systems for communication are easily
obtainable is very important for freedom of speech and other fundamental
rights.
-Magnus
Óvári
Please integrate Jami into Thunderbird.
Jami works on all platforms that Thunderbird works on. Jami also works on other platforms where Thunderbird doesn't like iPhone and Android.
Jami would also enable a SIP client to be available from within Thunderbird so Address Book contacts could be called.
What do you think?
Thank you
Óvári
Will
The focus of any open source project is invariably what people are prepared to work on.
With any OS project we are involved in (several), if we can't code, we help in support, or documentation, and if nothing else pay.
We are talking about core TB code here. The very base that everyone needs. The bit I guess most TB devs should probably be most focussed on because like - that is the core product??
It isn't our fault if the developers we have asked to help us have told us they don't want to because the code is missing features they require or it is so spaghetti like they don't want to waste their time and ours, or they can't see the point as it will all have to be rewritten again in 5 minutes.
Hey ho, Seems there are plenty of others who feel the same way.
I'll leave them to continue the fight as we will undoubtedly get banned for being out of order or somesuch.
Patrick Cloke
Wiktor,
On 10/11/19 7:23 AM, Wiktor Kwapisiewicz wrote:
On 09.10.2019 21:58, Patrick Cloke wrote:
It is unfortunately hard to get a clear picture of what is worth
implementing for XMPP
XSF publishes Compliance Suites every year that group features that they consider "worth implementing". See for example:I hadn't seen this exact compliance test site before. Thanks! I think it is only half the picture though. If a server implements an XEP, but no clients do, then it is not necessarily worth implementing. (There's also the aspect of trying to understand what clients are popular, I haven't looked into this for XMPP in a very long time though.)
https://xmpp.org/extensions/xep-0412.html
There are also tests run by companies that invest in XMPP heavily:
https://compliance.conversations.im/tests/
(i.e. how many users exist that support different end-to-end encryption technologies).
That's not the impression I got from XSF mailing lists. There are three groups of E2E technologies within XMPP: legacy (OTR and old OpenPGP), recommended (OMEMO and new OMEMO) and there is also MLS that some XSF council members believe will replace OMEMO long-term but the spec is not ready.I should probably join the XSF mailing list... the thing missing from that site is some understanding of how popular each of those clients are. (What percentage of the user population supports it, not what percentage of clients do.) Anyway, I'm not against supporting OMEMO, but supporting OTR was a good baseline since it helps all the protocols implemented in Thunderbird, and a bunch of the work had already been done a few years ago. Kai and Alex finished integrating it.
Currently OMEMO is widely implemented, see: https://omemo.top/
OTR, as the wiki page indicates, is used in either legacy clients where multiprotocol support is necessary. (There is also OTRv4 in development supported by one client that showcases it: https://coy.im ).I've seen the OTRv4 stuff, a bit, but haven't been plugged into whether clients really plan to implement it or not. My understanding is that it is very incompatible with OTRv3, which is unfortunate from a technical standpoint.
The major downside, in my understanding, is that OTR does not support multi-user chats. I'm sure
there are some others, but OTR seemed like a good place to start.
There's a bug [1] about implementing OMEMO for anyone who is interested!
Thanks for the reference!
No problem. I think it'd be good to have multiple options here. Hopefully the other users you're talking to have at least one that overlaps! I'm unsure how hard it would be to incorporate OMEMO, but I'd be willing to help guide someone who is interested.
Last thing I'll say is that if there are specific XMPP features
that are missing from Thunderbird please
start by filing a bug (probably a bug per XEP / feature).
Unfortunately most of my use of XMPP is via GTalk [1] which has a
pretty terrible feature set.
--Patrick
[1] Yes, it still works.
Tanstaafl
> On 10-10-2019 13:04, Will wrote:
>> we'd like to know why TB is
>> spending presumably a lot of resources on chat client encryption?
>
> Thunderbird is committed to ensuring free and private communications.
> Not only for chat but email too, which the OpenPGP announcement would
> have you know. I think in the larger view of things, ensuring
> distributed end-to-end encryption systems for communication are easily
> obtainable is very important for freedom of speech and other fundamental
> rights.
client, not a Chat client, and that should take a -very high- priority.
Once the email code is rewritten and all major/known bugs squashed, then
and only then should PAID resources (volunteers are of course always
welcome to work on whatever they want) be focused on chat and other
extraneous features.
If PAID resources are being used for Chat and other non-email type work,
then I question the validity of such decisions.
Will
> On 10-10-2019 13:04, Will wrote:
>> we'd like to know why TB is
>> spending presumably a lot of resources on chat client encryption?
>
> Thunderbird is committed to ensuring free and private communications.
> Not only for chat but email too, which the OpenPGP announcement would
> have you know. I think in the larger view of things, ensuring
> distributed end-to-end encryption systems for communication are easily
> obtainable is very important for freedom of speech and other
> fundamental rights.
>
time, and fully support the reasons for it.
We're not sure what relevance OpenPGP has to chat systems - that is just
conflating things. We understand the moves with OpenPGP for email.
However, there is a suggestion you are adding OTR to Thunderbird which
suggests you are trying to make it more a chat client and we just can't
see the logic behind that, especially when there are so many issues in
the basic email and calendar client itself.
Trying to compete in an already crowded *chat* market where you are up
against some seriously big players seems odd. We don't need TB for that
- there are much better solutions out there that fulfil your aspirations.
Why not just have hooks to use other systems, be that Signal or
whatever? Let the add on devs decide what they want to plug in.
TB are probably concerned that ultimately (in the long term) chat is
going to make email, and therefore TB, redundant. That really needs an
open conversation in itself.