Re: Future OpenPGP Support in Thunderbird
> Werner's implementation has an excellent reputation, and it's the only one > I personally trust completely. You state this so matter-of-factly, I feel compelled to point out that among cryptographers, libgcrypt's reputation is not all that great... https://twitter.com/ciphergoth/status/1179959883589771265 - V ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
>> GnuPG has steadfastly refused to create an OpenPGP library programmers >> can use directly, > > I was under the impression that gpgme is just such a library. It is not. Under the hood, GPGME works by launching an entirely new process and directing it via interprocess communication. Hopefully this puts the rest of my paragraph in perspective: "... on the grounds that security is improved by adding process separation between the application process and the GnuPG process. There's a lot to be said for this argument. There's a lot to be said for the counterargument: that the additional complexity involved in communicating across a process boundary turns it into a false savings." Regardless of whether you interface with GnuPG directly (as Enigmail does) or through a library (as GPGME-using applications do), you're still running GnuPG in a separate process and communicating across a process boundary. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
> Actually, the Enigmail / GnuPG duo is one of the best examples of how > different software parts could work together, thus increasing the > prevalence of both parts by magnitudes, pushing a technique which the > world really needs, and making it usable for the masses. Enigmail / > GnuPG is by fare more than its sum. And at the same time, less. Remember what Efail showed us: that the interface between GnuPG and clients calling it is remarkably subtle and prone to misinterpretation. It isn't just Enigmail which got bit by this, either: a *lot* of email clients got hit. GnuPG has steadfastly refused to create an OpenPGP library programmers can use directly, on the grounds that security is improved by adding process separation between the application process and the GnuPG process. There's a lot to be said for this argument. There's a lot to be said for the counterargument: that the additional complexity involved in communicating across a process boundary turns it into a false savings. I'm not sure which one I believe, myself. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 19.10.2019 17:20, Patrick Brunschwig wrote: > >> Why not stick with that and focus on what has made Enigmail >> successful? > What is the reason in your eyes that made Enigmail successful? > It is the ingenious mixture of integration / ease-of-use on one hand (setting it up (normally) is a no-brainer, including key generation and key upload, it allows for per-recipient rules, it provides a nice GUI for a task which actually is complex, it allows subject encryption, it allows using hardware tokens, it provides PGP/MIME and PGP/inline, and it integrates fantastically; heck, the PGP settings even are integrated into the account settings, exactly where they belong!) and on the other hand the unlimited possibilities of GnuPG (command line, configuration). Last, but not least, we must not forget security issues. Implementing PGP correctly is a hairy task, given the long history of security problems in different implementations. Werner's implementation has an excellent reputation, and it's the only one I personally trust completely. It is exactly the division of tasks which may have contributed to Enigmail's success more than one would imagine. After all, email encryption users do care about the underlying engine. We all know what we would have to expect if the TB team would rewrite the thing itself (which you have ruled out) or would use some library which hasn't been tested as rigorously as GnuPG. Actually, the Enigmail / GnuPG duo is one of the best examples of how different software parts could work together, thus increasing the prevalence of both parts by magnitudes, pushing a technique which the world really needs, and making it usable for the masses. Enigmail / GnuPG is by fare more than its sum. Each of the above reasons has made Enigmail such successful (and GnuPG, or course). Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Sat, 2019-10-19 at 17:20 +0200, Patrick Brunschwig wrote: > Jeff Allen via Gnupg-users wrote on 18.10.2019 16:02: > [...] > > My take on your original explanation of the reason for Enigmail's > > pending demise is that a changed Thunderbird plug-in scheme makes > > it > > more efficient to build Enigmail functionality into the MUA. > > That's only the 2nd half of the explanation. 1st and foremost, the > changed plugin scheme comes along with a completely new API (that > does > not even exist completely by now). This would require me to rewrite > almost all of Enigmail from scratch. I don't have enough free time > for > doing that, nor would I be interested in it. This, and nothing else, > was > initially the reason why we started the discussion with the > Thunderbird > team. I understand not wanting to rewrite Enigmail from scratch using a new API. If you have neither the time nor the desire to do it, I'm glad the Thunderbird team is willing to take over. My concern is how OpenPGP support is to be implemented. IIRC, you stated that it is too soon to know how much of Enigmail's functionality will be included. To me that is less important than how much of GnuPG's functionality will be incorporated. I can live without Enigmail's key manager and per- recipient rules if there is smartcard support and the ability to encrypt to multiple keys and to keys without a UID that matches the recipient's email address. If Thunderbird uses another OpenPGP library instead of calling GnuPG, I suspect some of those capabilites will vanish. > > > Why not stick with that and focus on what has made Enigmail > > successful? > > What is the reason in your eyes that made Enigmail successful? > Enigmail enabled a popular cross-platform email client to interface with GnuPG with all its capabilities. I've been trying out Evolution for the past few days. It doesn't have the special features Enigmail provides, but it does support GPG-encrypted email. It uses the keys on my Yubikey and aliases in my gpg.conf group lines. It is quite similar to using the earliest versions of Enigmail. Evolution's main limitation is that it is Linux only, not cross-platform. Windows and Mac users are out of luck. Jeff Allen signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Jeff Allen via Gnupg-users wrote on 18.10.2019 16:02: [...] > My take on your original explanation of the reason for Enigmail's > pending demise is that a changed Thunderbird plug-in scheme makes it > more efficient to build Enigmail functionality into the MUA. That's only the 2nd half of the explanation. 1st and foremost, the changed plugin scheme comes along with a completely new API (that does not even exist completely by now). This would require me to rewrite almost all of Enigmail from scratch. I don't have enough free time for doing that, nor would I be interested in it. This, and nothing else, was initially the reason why we started the discussion with the Thunderbird team. > Why not stick with that and focus on what has made Enigmail > successful? What is the reason in your eyes that made Enigmail successful? -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Thu, 2019-10-17 at 17:40 +0200, Patrick Brunschwig wrote: > In all cases, we certainly won't re-write GnuPG or similar. The > question > on the table is: do we continue to use GnuPG (be it directly or via > gpgme), or do we use a different OpenPGP implementation (and if yes > which one). There are certainly good arguments for both. > I am a GnuPG user, not an expert and certainly not a developer, so you may take my suggestions with a grain of salt. Following this thread about future OpenPGP support in Thunderbird prompted me to begin trying other MUAs. Why? Because if Thunderbird implements its own OpenPGP scheme, I wonder whether it will include features I consider important like smartcard support. It is unlikely to have a configuration file like gpg.conf that enables me to fine-tune both email and file encryption. For the past couple of days I have been using Evolution. It just works with GnuPG. I don't know or care how. It encrypts, decrypts and verifies signatures. There was no set-up required. My Yubikey works because Evolution calls GnuPG instead of using a proprietary implementation. AFAIK only GPG does that. Protonmail, Mailvelope, FlowCrypt, and Mailfence do not. You could probably build in smartcard support and any other feature I can name, but why grapple with what GnuPG already does well? Why spend your time trying to head off the next security threat when Werner & Co. will do it for you? Enigmail has great features like the key manager and per-recipient rules. Focus on those. Make Thunderbird encryption easy to use for novices without driving off more experienced users. Like Enigmail, I use only a tiny fraction of GPG's commands and options. The fact that GPG can do things I find esoteric is of little concern to me, but I'm glad those features are there for people who need them. The complexity of GnuPG does not make its use complex the average users or for apps providing GPG front-ends. They simply ignore what they don't need. The only thing I see that internal OpenPGP accomplishes is saving the Windows user the task of installing GnuPG. Anyone who uses Thunderbird knows how to install software. You can probably arrange with Werner for a permanent link to the latest simple installer. Automatically check for GnuPG when Thunderbird is installed on Windows. If it isn't there, offer one-click installation. I started using Thunderbird because of Enigmail, not the other way around. I haven't been a fan of some recent developments like pEp and defaulting to "junior" mode, but I recognize their usefulness to new users and can easily work around them myself. My take on your original explanation of the reason for Enigmail's pending demise is that a changed Thunderbird plug-in scheme makes it more efficient to build Enigmail functionality into the MUA. Why not stick with that and focus on what has made Enigmail successful? Jeff Allen signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 16-10-2019 17:37, Binarus wrote: > - either in understanding the APIs and command line parameters of a > library / utility, and to keep up with changes, or > > - in re-inventing the wheel, which in this case for sure will cost much > more time and eventually produce catastrophic security breaches and > software which is drastically inferior compared to what we have now. There is a 3rd option: build the library (open source anyway) and build it directly into the product. That has the advantage of using existing, tested code, allows to dump a lot of complexity for unused edge cases and prevents the problems with different library versions with changes between versions. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Binarus wrote on 16.10.2019 17:37: > > > On 16.10.2019 13:07, Patrick Brunschwig wrote: >> worry for me. The main problem is the additional complexity that it >> brings if you require an external component that you cannot *fully* >> control. This covers topics like different behavior of different >> versions, but also configuration issues, users rights to install >> something on their PC and more. Gpgme may handle some of these issues, >> but the fact remains: an external component makes things a lot more >> complex, especially for support. > > I think this is the usual trade-off. One has to put time > > - either in understanding the APIs and command line parameters of a > library / utility, and to keep up with changes, or > > - in re-inventing the wheel, which in this case for sure will cost much > more time and eventually produce catastrophic security breaches and > software which is drastically inferior compared to what we have now. > > After all, everybody uses libraries and utilities. It is just reasonable > to have an expert work on a library or utility which uses techniques and > mathematical stuff which non-specialists never will understand in > detail, and have the non-specialists use that library or utility, > instead of letting them re-develop the same stuff, probably introducing > all sorts of security flaws and producing inferior software. > > When I have a bash script under Linux which invokes a compiler using a > complicated command line, I wouldn't come to the idea to re-develop that > compiler and integrate it directly into bash because that compiler's > command line switches could change in the next version ... > > I am still convinced that re-writing GnuPG (including all functions like > hardware tokens, subject encryption etc.) in a secure manner is a > hundred times more complex and a million times more error-prone than > tracking a few changes to its command line switches or error codes ever > could be. Apart from that, there is GpgME, as already has been stated. In all cases, we certainly won't re-write GnuPG or similar. The question on the table is: do we continue to use GnuPG (be it directly or via gpgme), or do we use a different OpenPGP implementation (and if yes which one). There are certainly good arguments for both. -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 16.10.2019 13:07, Patrick Brunschwig wrote: > worry for me. The main problem is the additional complexity that it > brings if you require an external component that you cannot *fully* > control. This covers topics like different behavior of different > versions, but also configuration issues, users rights to install > something on their PC and more. Gpgme may handle some of these issues, > but the fact remains: an external component makes things a lot more > complex, especially for support. I think this is the usual trade-off. One has to put time - either in understanding the APIs and command line parameters of a library / utility, and to keep up with changes, or - in re-inventing the wheel, which in this case for sure will cost much more time and eventually produce catastrophic security breaches and software which is drastically inferior compared to what we have now. After all, everybody uses libraries and utilities. It is just reasonable to have an expert work on a library or utility which uses techniques and mathematical stuff which non-specialists never will understand in detail, and have the non-specialists use that library or utility, instead of letting them re-develop the same stuff, probably introducing all sorts of security flaws and producing inferior software. When I have a bash script under Linux which invokes a compiler using a complicated command line, I wouldn't come to the idea to re-develop that compiler and integrate it directly into bash because that compiler's command line switches could change in the next version ... I am still convinced that re-writing GnuPG (including all functions like hardware tokens, subject encryption etc.) in a secure manner is a hundred times more complex and a million times more error-prone than tracking a few changes to its command line switches or error codes ever could be. Apart from that, there is GpgME, as already has been stated. Regarding the user rights to install software: That was the reason why I thought about bundling the installers and installing both parts in the same directory. Even updates to GnuPG then could be handled by TB's update system (this is only an educated guess - I don't know if the licenses would allow this). If TB would use GpgME, this problem even would not exist in the first place. GpgME would just be another library lying around in TB's installation directory (under Windows, probably a DLL) and for sure could be updated via TB's update system. Just my 2 cents ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Werner Koch wrote on 16.10.2019 13:54: > On Wed, 16 Oct 2019 13:07, Patrick Brunschwig said: > >> something on their PC and more. Gpgme may handle some of these issues, >> but the fact remains: an external component makes things a lot more >> complex, especially for support. > > Right GPGME handles this all pretty well and I have suggested often > enough that you should move to GPGME so that we can better support > Enigmail. Your comment about external components is right from a > company POV; however Enigmail is also an external component to TB and > thus TB suffers from very similar problem. GpgOL and GnuPG both are Which is why the step to implement OpenPGP in Thunderbird is the right way to go. > maintained by us and thus I know very well this helps to reduce > friction. We're getting slightly off-topic, but still: You're perfectly right with everything you say. But you seem to underestimate the difference between zipping an extension that is pure JavaScript, and preparing an extension that needs to contain compiled libraries for multiple platforms in order to cater for all variants of pre-installed GnuPG installations and all variations of Thunderbird installations (to be precise, at the very least I'd have to ship for 6 platforms: Win/mac/Linux * 32/64 bit). Frankly speaking, if I would consider to switch to a library instead of calling GnuPG directly, I would at first evaluate OpenPGP.js in Enigmail -- that would be a lot more natural. -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Wed, 16 Oct 2019 10:46, Martijn Brinkers said: > I actually spend a lot of time investigating the impact of EFAIL on > S/MIME and it's my opinion that the real impact has been overblown. In > all my experiments, and I can tell you I have done a lot of them, I have > not been able to force a mail client to actually forward the decrypted > content to a remote system. I recall that you mentioned this in the past and I have not seen any statement to the contrary. In fact the whole attack is nearly 20 years old and even back then it was hard to construct a case where the non-authenticated encryption could be abused. When the PGP folks and me discussed the attack around the year 2000, we knew that and suggested signed mails as a solid counter-measurement. The MDC was then introduced mainly to counter the more or less theoretical attack and to be on the safe side in case better attacks would be developed. The media and political coverage (we had working groups and internal meetings) of the efail paper however required some extra measurements to take. > I think the problem with the paper was that they discusses two separate > issues. The issue with Efail-2 was serious but that was more an mail > client issue. I fully agree here. As usual reports about the MUA failures spread for months without mentioning that all the major MUAs fixed the bug within a few days or weeks or even had fixed it at the time the paper was published. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Wed, 16 Oct 2019 13:07, Patrick Brunschwig said: > something on their PC and more. Gpgme may handle some of these issues, > but the fact remains: an external component makes things a lot more > complex, especially for support. Right GPGME handles this all pretty well and I have suggested often enough that you should move to GPGME so that we can better support Enigmail. Your comment about external components is right from a company POV; however Enigmail is also an external component to TB and thus TB suffers from very similar problem. GpgOL and GnuPG both are maintained by us and thus I know very well this helps to reduce friction. The move to integrate OpenPGP in TB is important but also pretty risky if it won't work for everyone right away from the start. The big advantage of TB/Enigmail is that it is cross-platform and often the only way to have encrypted mail on macOS. I know several media companies who badly suffered when GpgTools were not able to get their plugin working on a new macOS version. Their journalists were then forced to use TB and not their, for whatever reason, beloved apple mailer. Let's hope that at least of one is always working. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Binarus wrote on 16.10.2019 10:47: > > On 14.10.2019 16:15, Jeff Allen via Gnupg-users wrote: >>> I don't know either, but perhaps it is in the debug logs the Enigmail >>> team analyzes? >> >> I have used Enigmail since its inception and have never knowingly >> submitted a log or answered a survey and have always assumed Enigmail >> does not phone home. > > I am sure that it doesn't phone home. However, to give an example, I had You can be certain that I'd never implement that. [...] > I suppose that the Enigmail team gets quite a lot of such debug logs. > But I still can't tell (and currently don't have the time to > investigate) if those logs can tell which keys had been generated by > Enigmail and which had been generated externally, so the whole thing was > a guess anyway. Yes, I did and do get quite a lot of debugging log files, and even more support requests. And I really speak from experience when I say that the vast majority of the users of Enigmail don't store their private keys on external devices. [...] > So why not take Enigmail, integrate it into TB, and bundle Gpg4Win setup > with TB setup? All software they ever could develop themselves will be > inferior compared to that package, at least in the first time. I have almost 17 years of experience with supporting Enigmail. About 90% of all support requests that I get turn out to be setup issues with GnuPG. Interestingly, most of them are on Linux, even though all Linux distributions I know ship GnuPG. The bundling/shipping would not be a worry for me. The main problem is the additional complexity that it brings if you require an external component that you cannot *fully* control. This covers topics like different behavior of different versions, but also configuration issues, users rights to install something on their PC and more. Gpgme may handle some of these issues, but the fact remains: an external component makes things a lot more complex, especially for support. -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
> Efail-1 was what Werner is talking about here. It was a pretty bad > blow to S/MIME, but far less so to OpenPGP, since OpenPGP has had > countermeasures in place for almost twenty years. Efail-1's impact > on OpenPGP was, is, minimal. I actually spend a lot of time investigating the impact of EFAIL on S/MIME and it's my opinion that the real impact has been overblown. In all my experiments, and I can tell you I have done a lot of them, I have not been able to force a mail client to actually forward the decrypted content to a remote system. The CBC attack is serious because modifying encrypted content is not something you expect from a security point of view. But the real life impact is not as big as they wanted us to believe (IMHO). I have asked the EFAIL authors for examples on real life attacks (of the CBC problem related to S/MIME) but I never got a real answer whether they were able to use the attack in real life situation. I think the problem with the paper was that they discusses two separate issues. The issue with Efail-2 was serious but that was more an mail client issue. Kind regards, Martijn ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 14.10.2019 16:15, Jeff Allen via Gnupg-users wrote: >> I don't know either, but perhaps it is in the debug logs the Enigmail >> team analyzes? > > I have used Enigmail since its inception and have never knowingly > submitted a log or answered a survey and have always assumed Enigmail > does not phone home. I am sure that it doesn't phone home. However, to give an example, I had a problem some years ago where Enigmail didn't work correctly any more when a certain other extension was installed, or vice versa. I published that problem somewhere (can't remember exactly) and got the advice to turn on Enigmail debugging and send the debug log to a certain email address or to publish it (again, can't remember). Of course, I followed that advice (after having examined the log file and having convinced myself that there was no critical data in it, as expected). I suppose that the Enigmail team gets quite a lot of such debug logs. But I still can't tell (and currently don't have the time to investigate) if those logs can tell which keys had been generated by Enigmail and which had been generated externally, so the whole thing was a guess anyway. The vast majority of users also don't use GnuPG for anything else than email. These users don't care where their key is stored, nor which software under the hood is used for the crypto. All they care is that encryption works smoothly. >>> >>> And this? >>> >> >> I am also not sure about this. As far as it concerns Windows, the first >> part of the statement may be true. > > All the statements might be true. My question was "How do you know?" Good point. I see. >> I am not sure where this will lead to. It sounds as if you were >> suggesting to give up on privacy, encryption and authentication for that >> reason. > > Not at all. My point was that I doubt OpenPGP's inclusion in > Thunderbird will have a major impact on the number of people encrypting > their email I think that even a minor impact would be desirable. The problem is: If it is done wrong (essential features missing, e.g. subject encryption, no exchange of keys with external tools, no hardware token support etc.), it could prevent a large part of today's encryption users from using encryption in the future, i.e. it even could reduce encryption prevalence. Personally, I am not sure what I'd do if the integration of PGP in TB would be broken (i.e. no subject encryption, no control over key generation and so on). Theoretically, I could move to another MUA which provides a reasonable workflow for PGP, but due to pressure of time and due to flaws or missing features in other MUAs I eventually would have to stick with TB, even if I couldn't reasonably use PGP any more. >> While I agree with you that this problem exists and is quite difficult >> to solve (eventually it needs another decade), I am absolutely sure that >> bad and difficult software will make it worse, but good and usable >> software will help in solving it. The fact that the problem exists does >> not mean that nobody should try to solve it by providing easier-to-use, >> fully integrated software with reasonable default settings. > > Here we disagree. I believe that existing software is not that > difficult to use. The problem, if there is one, is that most people > simply aren't interested. Twenty years ago I thought that everyone > would soon be using end-to-end encrypted email. Twenty years from now > they still won't be. Here the integration could really help. For example, keys could be automatically generated whenever a new email account is created in TB. Then, when sending the first message using that account, a dialog could popup asking the user: "We already have completely setup your PGP keys. Do you want to authenticate this and further messages, and do you want to attach your public key to each message so that the correspondents can encrypt their replies to you, and do you want to upload your public key to server x.y.z so that everybody can send you encrypted messages and can verify your signature?" I bet that 80% of users would answer this dialog by clicking "Yes", and I think this would really help. But once again, if too many features are missing in the integration, this will throw back email encryption prevalence by one or two decades because TB / Enigmail presumably is the most widespread software for email encryption, and I am not sure how many users could move to another MUA if PGP is broken / not fully usable in TB. >> There are many reasons to think so (the following applies to ProtonMail >> as well as Tutanota): >> >> 1) To actually use those services in a reasonable manner, you have to >> opt-in for a paid contract. For most of us, this is a matter of >> principle. Why should we pay for a thing that used to be free all the >> time? (Note: I don't want to judge that attitude - I am just stating how >> it is). > > > > But "free" email has never been free from the likes of Gmail, Yahoo, >
Re: Future OpenPGP Support in Thunderbird
> I'm confused. I thought the whole efail thing was about crafting a > plain text message that says "Good signature verified" and fools the > user even though it was never run through pgp or had its signature > verified with s/mime. I'd suggest reading the Efail paper. The vast majority of the news coverage was shoddy. Efail included two *completely separate* attacks in their paper, which the news media overwhelmingly conflated into a single attack. I'll call them Efail-1 and Efail-2 here. Efail-1 was what Werner is talking about here. It was a pretty bad blow to S/MIME, but far less so to OpenPGP, since OpenPGP has had countermeasures in place for almost twenty years. Efail-1's impact on OpenPGP was, is, minimal. Efail-2 wasn't an attack on OpenPGP at all, but instead showed how poorly email clients and/or email plugins communicated with GnuPG. It was possible for GnuPG to give a correct warning that someone was playing games with the message, and for the email client to disregard this warning and present it to the user as authentic. Efail-1 had minimal applicability to GnuPG; Efail-2 had none whatsoever (except, arguably, some of the messages GnuPG gave were ambiguous: I think they were, but Werner disagrees). ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Werner Koch writes: > authenticated encryption is different from signed and encrypted mails. > There are relative easy attacks on the encryption layer if standard > encryption modes like CBC (as in S/MIME) are used. Whether this really > affects users is a different question but they can be used to leverage > implementation flaws in MUAs to full plaintext leaks. This is known for > 20 years and made it last year again to the media under the term EFAIL. I'm confused. I thought the whole efail thing was about crafting a plain text message that says "Good signature verified" and fools the user even though it was never run through pgp or had its signature verified with s/mime. > Granted, encrypted+signed mails can to a large extend also mitigate the > threat. But there are still reasons why signatures can't be used or > need to be verified only at a latter time in the workflow. > > OpenPGP had a mitigation against this since 2000 and was widely deployed > by 2003. However S/MIME never implemented this despite of 10 years old > RFCs describing methods for such a mitigation, called authenticated > encryption (AE or AEAD). AFAICS, that is for encryption+sign. If you just want to sign, it sounds like you are saying that is broken. I don't see how. You can't modify the message and keep the hash unchanged, and you can't encrypt a new hash because you don't have the sender's private key. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 14.10.2019 22:45, Werner Koch wrote: > On Mon, 14 Oct 2019 20:43, Kristian Fiskerstrand said: > >> was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC. >> Details need to be discussed, but it would be an optional solution, that > > Given that TB already has smartcard support it would be easy if the new > code just makes use of that code. Of course the code then needs to > touch the NSS part of Mozilla and can't just go with RNP. That would be > a more integrated solution than any other hack. > > Right, separate software will be required but that is the usual case > with smartcards. For example Scute can be used to provide card services > via GnuPG (and also allow for on-disk GnuPG. Note that GnuPG 2.3 will > be much more flexible in regard to smartcard use and how it can interact > with TB via Scute. Scute might very well be a good alternative to reach out to, but I'm not too optimistic regarding the likelihood of getting anything related to OpenPGP directly into NSS, hence expecting anything that requires development needs to be done through other vectors. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
> I have used Enigmail since its inception and have never knowingly > submitted a log or answered a survey and have always assumed Enigmail > does not phone home. It does not. > Here we disagree. I believe that existing software is not that > difficult to use. The problem, if there is one, is that most people > simply aren't interested. There's excellent academic research into why. I heartily recommend reading this paper: "Secrecy, Flagging, and Paranoia: Adoption Criteria in Encrypted Email". Shirley Gaw, Ed Felten, and Patricia Fernandez-Kelly, out of Princeton University. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136.5612&rep=rep1&type=pdf ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Mon, 14 Oct 2019 20:43, Kristian Fiskerstrand said: > was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC. > Details need to be discussed, but it would be an optional solution, that Given that TB already has smartcard support it would be easy if the new code just makes use of that code. Of course the code then needs to touch the NSS part of Mozilla and can't just go with RNP. That would be a more integrated solution than any other hack. Right, separate software will be required but that is the usual case with smartcards. For example Scute can be used to provide card services via GnuPG (and also allow for on-disk GnuPG. Note that GnuPG 2.3 will be much more flexible in regard to smartcard use and how it can interact with TB via Scute. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 14.10.2019 18:54, Juergen Bruckner via Gnupg-users wrote: > Hello to all, > > well it's a good thing, that openPGP shall be included to TB directly. > > But ... as the Mozilla wiki [1] states in the FAQ-Section the following: > > > Q: Will OpenPGP cards be supported for private key storage ? > > A: Probably not, because we don't use the GnuPG software that's usually >required to access OpenPGP smartcards. I agree OpenPGP smartcard/token support is a must have, and brought this up during this during this weekend's OpenPGP summit; please see the [notes] section "Workshop: Thunderbird & OpenPGP" for some of the discussion, specifically """ Although RNP doesn't support smartcards currently, a potential solution was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC. Details need to be discussed, but it would be an optional solution, that only works if the user has installed software (scd etc.) in addition to Thunderbird. How would this work? GnuPG as an optional dependency? Outsourcing smartcard handling to scdaemon (scd), which is available cross-platform through Unix socket or TCP/IP (windows) with usual user system protection? Or... extend the RNP library to talk to scd? Needs discussion and contributors, but that should wait until we're certain what library TB will use. """ References: [notes] https://wiki.gnupg.org/OpenPGPEmailSummit201910Notes -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Hello to all, well it's a good thing, that openPGP shall be included to TB directly. But ... as the Mozilla wiki [1] states in the FAQ-Section the following: Q: Will OpenPGP cards be supported for private key storage ? A: Probably not, because we don't use the GnuPG software that's usually required to access OpenPGP smartcards. This will not be usefull for me or my company, as we only use PGP Keys stored on smartcards. So I guess we will have to take TB down and find other solutions. m2c Juergen [1] https://wiki.mozilla.org/Thunderbird:OpenPGP:2020 -- Juergen M. Bruckner juer...@bruckner.tk smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Mon, 14 Oct 2019 10:54, Phillip Susi said: >> encryption protocol is S/MIME and the last time I checked S/MIME (well, >> CMS for the nitpickers) does not supoport any kind of authenticated >> encryption. In contarst OpenPGP provides this nearly for 2 decades. > > What do you mean? S/MIME authenticates the user's identity via the CA. authenticated encryption is different from signed and encrypted mails. There are relative easy attacks on the encryption layer if standard encryption modes like CBC (as in S/MIME) are used. Whether this really affects users is a different question but they can be used to leverage implementation flaws in MUAs to full plaintext leaks. This is known for 20 years and made it last year again to the media under the term EFAIL. Granted, encrypted+signed mails can to a large extend also mitigate the threat. But there are still reasons why signatures can't be used or need to be verified only at a latter time in the workflow. OpenPGP had a mitigation against this since 2000 and was widely deployed by 2003. However S/MIME never implemented this despite of 10 years old RFCs describing methods for such a mitigation, called authenticated encryption (AE or AEAD). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Werner Koch via Gnupg-users writes: > Still, TB is still subject to those attacks because their primary > encryption protocol is S/MIME and the last time I checked S/MIME (well, > CMS for the nitpickers) does not supoport any kind of authenticated > encryption. In contarst OpenPGP provides this nearly for 2 decades. What do you mean? S/MIME authenticates the user's identity via the CA. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 10/14/19 3:40 AM, Binarus wrote: > > On 13.10.2019 22:27, Jeff Allen via Gnupg-users wrote: >> On 10/13/19 2:21 AM, Patrick Brunschwig wrote: >>> The vast majority of users of Enigmail (somewhere around 98%) don't use >>> external built keys. >> >> How do you know this? >> > > I don't know either, but perhaps it is in the debug logs the Enigmail > team analyzes? I have used Enigmail since its inception and have never knowingly submitted a log or answered a survey and have always assumed Enigmail does not phone home. >>> The vast majority of users also don't use GnuPG for >>> anything else than email. These users don't care where their key is >>> stored, nor which software under the hood is used for the crypto. All >>> they care is that encryption works smoothly. >> >> And this? >> > > I am also not sure about this. As far as it concerns Windows, the first > part of the statement may be true. All the statements might be true. My question was "How do you know?" > I disagree with the second part of the statement, though. Most of the > people who think about privacy and email encryption / authentication at > all are educated, non-average users who want to be sure that there are > no backdoors in their software and that they use it as safely as > possible (meaning that they care about software, algorithms and > ciphers), and who want to backup their keys (meaning that they care > where the keys are stored). And yes, I want to decide on my own if my > key is ED25519, RSA1024 or RSA4096 :-) I agree and think Patrick underestimates the number of GnuPG/Enigmail users who care a lot about the details. My argument in the other thread was that folks who value privacy and encryption but can't be burdened by the details have reasonably secure easy-to-use options available. Enigmail is, of course, one of them. >>> The most important aspects from our side are the following: The chosen >>> solution must run smoothly for the ~20M users of Thunderbird without >>> causing a large amount of support/setup issues. >> >> Presumably those ~20,000,000 will have to opt-in to use Thunderbird >> encryption. Most won't for the same reason they don't install and use >> Enigmail now. They don't particularly care about privacy, and the few >> who do care correspond with people who don't. >> > > I am not sure where this will lead to. It sounds as if you were > suggesting to give up on privacy, encryption and authentication for that > reason. Not at all. My point was that I doubt OpenPGP's inclusion in Thunderbird will have a major impact on the number of people encrypting their email. > While I agree with you that this problem exists and is quite difficult > to solve (eventually it needs another decade), I am absolutely sure that > bad and difficult software will make it worse, but good and usable > software will help in solving it. The fact that the problem exists does > not mean that nobody should try to solve it by providing easier-to-use, > fully integrated software with reasonable default settings. Here we disagree. I believe that existing software is not that difficult to use. The problem, if there is one, is that most people simply aren't interested. Twenty years ago I thought that everyone would soon be using end-to-end encrypted email. Twenty years from now they still won't be. >>> We want to have >>> something that satisfies as many users of Enigmail as possible. We >>> certainly don't want to have people run away from Thunderbird because of >>> OpenPGP. >> >> [Snip] >> >> Is there any reason to think that folks who object to easy-to-use >> proprietary encrypted email solutions from ProtonMail and Tutanota will >> embrace a proprietary encrypted email solution from Thunderbird? >> > > There are many reasons to think so (the following applies to ProtonMail > as well as Tutanota): > > 1) To actually use those services in a reasonable manner, you have to > opt-in for a paid contract. For most of us, this is a matter of > principle. Why should we pay for a thing that used to be free all the > time? (Note: I don't want to judge that attitude - I am just stating how > it is). But "free" email has never been free from the likes of Gmail, Yahoo, GMX, etc. While you don't pay a yearly fee, you trade your privacy for a few bucks. You open yourself to tracking and targeted advertising. Your email is anything but private. A couple years back both Google and Yahoo claimed to be working on E2EE. I wonder why it never happened? The free versions of ProtonMail, Tutanota and Mailfence at least preserve your privacy. They aren't monetized through advertising and tracking. Instead they sell premium services to people who want more capacity or features. Many people I know do email exclusively on their smart phones. They don't use an MUA and don't care about POP3, IMAP or SMTP. Their view of using email services in a reasonable manner doesn't comport with yours or mine. I hope I am wrong and Thunderbird's
Re: Future OpenPGP Support in Thunderbird
On 14.10.2019 09:17, Patrick Brunschwig wrote: > Binarus wrote on 13.10.2019 18:27: > [...] >> 1) The schedule >> >> We have all been educated to update our applications (notably, "internet >> applications" like browser and email clients) as soon as updates are >> available; at least, this is true for security updates. >> >> Despite release plans, I think nobody knows for sure how much time >> actually will pass between TB 72's predecessor and TB 78, and how many >> security updates will be released between these versions. >> >> During that time, I either can't use Enigmail (if I decide to install >> the security updates), or I have to ignore the security updates >> (possibly putting me to risk). >> >> Did I understand this correctly? > > The current stable version of Thunderbird is 68 (and 60 for a few more > weeks); the next stable version will be 78. Users of Enigmail staying on > the stable version of Thunderbird will receive all security updates > until TB 78 will be available. Thunderbird 69 ... 77 are only released > as beta versions that are not intended for end users. > I see. Thank you very much for the clarification. This relieves a lot of tension. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 13.10.2019 22:27, Jeff Allen via Gnupg-users wrote: > On 10/13/19 2:21 AM, Patrick Brunschwig wrote: >> The vast majority of users of Enigmail (somewhere around 98%) don't use >> external built keys. > > How do you know this? > I don't know either, but perhaps it is in the debug logs the Enigmail team analyzes? >> The vast majority of users also don't use GnuPG for >> anything else than email. These users don't care where their key is >> stored, nor which software under the hood is used for the crypto. All >> they care is that encryption works smoothly. > > And this? > I am also not sure about this. As far as it concerns Windows, the first part of the statement may be true. There is plenty of software to encrypt single files or directories for Windows, including the software which is part of the O/S. People probably tend to go the easiest way, even if another solution would be safer and technically superior. I don't know the situation under Linux well enough to comment. I disagree with the second part of the statement, though. Most of the people who think about privacy and email encryption / authentication at all are educated, non-average users who want to be sure that there are no backdoors in their software and that they use it as safely as possible (meaning that they care about software, algorithms and ciphers), and who want to backup their keys (meaning that they care where the keys are stored). And yes, I want to decide on my own if my key is ED25519, RSA1024 or RSA4096 :-) >> The most important aspects from our side are the following: The chosen >> solution must run smoothly for the ~20M users of Thunderbird without >> causing a large amount of support/setup issues. > > Presumably those ~20,000,000 will have to opt-in to use Thunderbird > encryption. Most won't for the same reason they don't install and use > Enigmail now. They don't particularly care about privacy, and the few > who do care correspond with people who don't. > I am not sure where this will lead to. It sounds as if you were suggesting to give up on privacy, encryption and authentication for that reason. While I agree with you that this problem exists and is quite difficult to solve (eventually it needs another decade), I am absolutely sure that bad and difficult software will make it worse, but good and usable software will help in solving it. The fact that the problem exists does not mean that nobody should try to solve it by providing easier-to-use, fully integrated software with reasonable default settings. >> We want to have >> something that satisfies as many users of Enigmail as possible. We >> certainly don't want to have people run away from Thunderbird because of >> OpenPGP. > > [Snip] > > Is there any reason to think that folks who object to easy-to-use > proprietary encrypted email solutions from ProtonMail and Tutanota will > embrace a proprietary encrypted email solution from Thunderbird? > There are many reasons to think so (the following applies to ProtonMail as well as Tutanota): 1) To actually use those services in a reasonable manner, you have to opt-in for a paid contract. For most of us, this is a matter of principle. Why should we pay for a thing that used to be free all the time? (Note: I don't want to judge that attitude - I am just stating how it is). 2) None of that services supports IMAP or POP3. I would be totally crazy if I would make myself totally dependent on companies or services which won't let me download my messages and integrate them into my email client. What happens if those companies suddenly stop their service and you haven't downloaded your messages yet (which anyway seems to be impossible)? Or if you decide that you want to use another service? How long will you be able to access your messages after you have stopped paying your old service? Will they delete your messages until the quota for free usage is reached again? I insist on having all important data, including email messages, in-house and under my complete control, and I strongly advise each of my customers to do the same. So far, all of them are following that advice. Therefore, such services never will have any chance to do business with my customers. 3) I have several email addresses. I am definitely not ready to use a different website or different software for each of them. That is, there is absolutely no chance that I ever will use a service which does not provide POP3 or IMAP (or, for the protocol, their successors). I want *one* MUA (like Thunderbird) to be able to manage *all* of my email messages in *one* place (For example, ever needed to search for a message for which you can't remember the account it was received on? - The global search in TB is very handy here. Further reasons: junk filtering, action filters (automatically moving certain messages in subfolders) and so on, all managed at one place, public folders, shared folders and so on). 4) I doubt that these services can be legally used b
Re: Future OpenPGP Support in Thunderbird
Binarus wrote on 13.10.2019 18:27: [...] > 1) The schedule > > We have all been educated to update our applications (notably, "internet > applications" like browser and email clients) as soon as updates are > available; at least, this is true for security updates. > > Despite release plans, I think nobody knows for sure how much time > actually will pass between TB 72's predecessor and TB 78, and how many > security updates will be released between these versions. > > During that time, I either can't use Enigmail (if I decide to install > the security updates), or I have to ignore the security updates > (possibly putting me to risk). > > Did I understand this correctly? The current stable version of Thunderbird is 68 (and 60 for a few more weeks); the next stable version will be 78. Users of Enigmail staying on the stable version of Thunderbird will receive all security updates until TB 78 will be available. Thunderbird 69 ... 77 are only released as beta versions that are not intended for end users. -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 10/13/19 2:21 AM, Patrick Brunschwig wrote: > The vast majority of users of Enigmail (somewhere around 98%) don't use > external built keys. How do you know this? > The vast majority of users also don't use GnuPG for > anything else than email. These users don't care where their key is > stored, nor which software under the hood is used for the crypto. All > they care is that encryption works smoothly. And this? > The most important aspects from our side are the following: The chosen > solution must run smoothly for the ~20M users of Thunderbird without > causing a large amount of support/setup issues. Presumably those ~20,000,000 will have to opt-in to use Thunderbird encryption. Most won't for the same reason they don't install and use Enigmail now. They don't particularly care about privacy, and the few who do care correspond with people who don't. > We want to have > something that satisfies as many users of Enigmail as possible. We > certainly don't want to have people run away from Thunderbird because of > OpenPGP. If responses to my posts in the "We have GOT TO make things simpler" thread are any indication, you'll be looking at quite a few back sides. Is there any reason to think that folks who object to easy-to-use proprietary encrypted email solutions from ProtonMail and Tutanota will embrace a proprietary encrypted email solution from Thunderbird? Jeff Allen signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 13.10.2019 18:51, Werner Koch wrote: > On Sun, 13 Oct 2019 18:27, Binarus said: > >> keys' IDs were formally wrong so that key servers didn't accept the >> keys. The easiest possible solution was to re-generate these keys using > > For the records: Not /keyservers/ but one specific keyserver which runs > on a not yet matured enough code base and is thus expected to have bugs. > Thank you very much for your remark. Actually, I have meant this to be just an example for the problems to expect if too many features are missing. Secondly, I suspect that there are more keyservers out there (running other software) which also would reject those keys (I didn't try, though, so this is speculation). Thirdly, this is the keyserver which is preset in Enigmail (I didn't change the default). For naive users like me, it is not possible to check a keyserver's software version and to analyze how mature / stable it is. I even wouldn't come to that idea, because this is the default keyserver in a well-known software package :-) If I wouldn't have been able to generate correct keys / IDs using GnuPG directly, I eventually would have given up on encryption. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Sun, 13 Oct 2019 18:27, Binarus said: > keys' IDs were formally wrong so that key servers didn't accept the > keys. The easiest possible solution was to re-generate these keys using For the records: Not /keyservers/ but one specific keyserver which runs on a not yet matured enough code base and is thus expected to have bugs. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 08.10.2019 09:08, Patrick Brunschwig wrote: > The Thunderbird developers have announced that they will implement > OpenPGP support in Thunderbird 78 [1]. Support for Thunderbird in > Enigmail will therefore be discontinued. > > [Snip] > > I will continue to support and maintain Enigmail for Thunderbird 68 > until 6 months after Thunderbird 78 will have been released (i.e. a few > months beyond Thunderbird 68 EOL). Enigmail will not run anymore on > Thunderbird 72 beta and newer. IMHO, integrating PGP into TB in general is a good decision. However, I have two concerns (being a naive user, and being far away from understanding the technical aspects). 1) The schedule We have all been educated to update our applications (notably, "internet applications" like browser and email clients) as soon as updates are available; at least, this is true for security updates. Despite release plans, I think nobody knows for sure how much time actually will pass between TB 72's predecessor and TB 78, and how many security updates will be released between these versions. During that time, I either can't use Enigmail (if I decide to install the security updates), or I have to ignore the security updates (possibly putting me to risk). Did I understand this correctly? I am not on a level that I would use GnuPG on the command line to encrypt or authenticate my messages (encryption is fascinating, and if I had the time, it would be a pleasure to dive deeply into this subject, but for the time being, I just need it working), so I am dependent on the TB / Enigmail duo (at least until TB 78). 2) The features When integrating PGP into TB, IMHO great attention must be paid that none of the important features of Enigmail / GnuPG get lost, not even in the first version. The statement that the first implementation probably will be "less feature-rich" than Enigmail (let alone GnuPG) really frightens me and lets me expect all sorts of problems. For example, even I (as a non-advanced user) recently had an issue where I could not use PGP keys which were generated by Enigmail, because the keys' IDs were formally wrong so that key servers didn't accept the keys. The easiest possible solution was to re-generate these keys using GnuPG on the command line (despite my statement above ...) and import them into Enigmail. This simple case shows that we actually need the full functionality of a mature software package like GnuPG from the beginning on (note that my problem was ridiculously simple, but even then I couldn't easily solve it using Enigmail alone). My feeling is that TB (and probably email encryption / authentication per se) will lose a lot of users (including me) if the first implementation lacks essential features, makes the encryption setup fail due to common problems (like mine), or makes encryption unusable or difficult in any other way. By the way, being able to encrypt the subject of an encrypted message also is one of the essential features (thanks, Patrick, and thanks, Werner, that you finally have made this possible a while ago!) ... Just my 2 cents ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Werner Koch via Gnupg-users wrote on 13.10.2019 11:56: > On Sat, 12 Oct 2019 12:43, Chris Narkiewicz said: > >> Do you know why they resited OpenPGP adoption it so much? > > iirc, they said that they want to support only one protocol and settled > for S/MIME. This still did not explain why they rejected our proposal > to clean up their S/MIME code and implement missing stuff so that TB > could be used for tasks of the German administrative and to be > compatible with a wider range of S/MIME implementations. The plan was > to do that all within TB and without external dependencies. I think there are two reasons why TB changed their minds: 1. there are different people working on Thunderbird than years ago. 2. in the past, TB was a direct part of Mozilla. Now, Thunderbird is an independent organization under the umbrella of the Mozilla Foundation, with an independent council and their own independent financial income stream. These two factors lead to a completely different mindset towards what is good for TB. -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Sat, 12 Oct 2019 12:43, Chris Narkiewicz said: > Do you know why they resited OpenPGP adoption it so much? iirc, they said that they want to support only one protocol and settled for S/MIME. This still did not explain why they rejected our proposal to clean up their S/MIME code and implement missing stuff so that TB could be used for tasks of the German administrative and to be compatible with a wider range of S/MIME implementations. The plan was to do that all within TB and without external dependencies. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
By the Way, this goes for the vast Majority of People that drives, heats aso. by Oil and Gas as well. Am 2019-10-13 um 08:21 schrieb Patrick Brunschwig: BruderB wrote on 12.10.2019 10:43: Hej all, Am 12.10.19 um 08:23 schrieb Robert J. Hansen: they're going to insist on running their own keyring internal to Thunderbird which isn't shared with anything else. (I imagine *importing* from a GnuPG keyring will be supported, but *sharing* a keyring is right out.) _They_ can insist on whatever they want. If they close their shop towards external built keys (for example with xca), they hopefully won't find much acceptance. The vast majority of users of Enigmail (somewhere around 98%) don't use external built keys. The vast majority of users also don't use GnuPG for anything else than email. These users don't care where their key is stored, nor which software under the hood is used for the crypto. All they care is that encryption works smoothly. I'm sorry, but everything written here is pure speculation. We are still in the phase of considering our options. Depending on the chosen approach, we may just as well end up with something completely different than what you'd imagine. The most important aspects from our side are the following: The chosen solution must run smoothly for the ~20M users of Thunderbird without causing a large amount of support/setup issues. We want to have something that satisfies as many users of Enigmail as possible. We certainly don't want to have people run away from Thunderbird because of OpenPGP. -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -- -== Jan-Peter Rühmann & Kuma =- Gubkower Str.7 [ Tel.: +49 38205 65484 ] jan-pe...@ruehmann.name 18195 Cammin / Prangendorf [ FAX: +49 38205 65212 ] https://www.ruehmann.name WhatsApp: 491621316054 [ Tel.: +49 38205 65215 ] Twitter: @JPRuehmann [ Mobil: +49 162 1316054 ] IT-Servicetechniker -=- Die Verwendung der Daten zu Werbezwecken ist verboten. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
BruderB wrote on 12.10.2019 10:43: > Hej all, > > Am 12.10.19 um 08:23 schrieb Robert J. Hansen: >> they're going to insist on running their own keyring internal to >> Thunderbird which isn't shared with anything else. (I imagine >> *importing* from a GnuPG keyring will be supported, but *sharing* a >> keyring is right out.) > > _They_ can insist on whatever they want. If they close their shop > towards external built keys (for example with xca), they hopefully won't > find much acceptance. The vast majority of users of Enigmail (somewhere around 98%) don't use external built keys. The vast majority of users also don't use GnuPG for anything else than email. These users don't care where their key is stored, nor which software under the hood is used for the crypto. All they care is that encryption works smoothly. I'm sorry, but everything written here is pure speculation. We are still in the phase of considering our options. Depending on the chosen approach, we may just as well end up with something completely different than what you'd imagine. The most important aspects from our side are the following: The chosen solution must run smoothly for the ~20M users of Thunderbird without causing a large amount of support/setup issues. We want to have something that satisfies as many users of Enigmail as possible. We certainly don't want to have people run away from Thunderbird because of OpenPGP. -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Sat, Oct 12, 2019 at 08:07:58AM -0400, Mark H. Wood wrote: Humph, I was already grumpy about Mozilla products' insistence on having their own insular X.509 store, meaning that I have to install certificates twice (once for Firefox, again for *everything else*.) Slightly off-topic for this list, but on unix-like systems, you can force Firefox to use the system store of X.509 certificates (in /etc/ssl/certs) by replacing Firefox’s libnssckbi.so library by the libp11-kit.so library from the p11-kit project [1,2]. This also works with Thunderbird and with LibreOffice. - Damien [1] https://p11-glue.github.io/p11-glue/p11-kit.html [2] https://askubuntu.com/questions/244582/add-certificate-authorities-system-wide-on-firefox/1036637#1036637 signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Sat, Oct 12, 2019 at 10:13:59AM +0300, Teemu Likonen via Gnupg-users wrote: > Philipp Klaus Krause [2019-10-08T15:34:28+02] wrote: > > > It would be really nice, if Thunderbird could add an option to use the > > gpg key storage instead of its own, [...] > > I agree with that even though I have never really used Thunderbird. > > But using a custom key storage and implementation (or do they use > Sequoia PGP library?) is an interesting choice in the world of Unix-like > systems. It's pretty much the normal way elsewhere, though. > > PGP and GnuPG and the related communities have tried really hard to > build a system based on person's long-term identity keys. All that web > of trust thing relies on keys that are used relatively long time. But as > we know this doesn't work for most people. People are really bad at > maintaining long-term identity keys. I think this is the most important > reason why other software just auto-generate "device keys" or > "application keys" and exchange them. They just forget about the > identity part and keys' usage in the long term. Change your phone or > just reinstall the application and you'll have new keys. Keys come and > go and it's perfectly normal. That would be one of the reasons why I tend to avoid "other software". My primary use-case is identity, not secrecy. I am not alone: quite a few employers are at last discovering crypto signatures in their efforts to combat spear-phishing, and spending quite a bit of money and effort to deploy them. (I accept that most of them are using S/MIME rather than OpenPGP, but that's a detail; identity is important.) > Thunderbird seems to be going to that direction and it is probably a > good thing. From the mindset of crypto nerds (like us) or Unixy tool box > this can be a barrier, obviously. Humph, I was already grumpy about Mozilla products' insistence on having their own insular X.509 store, meaning that I have to install certificates twice (once for Firefox, again for *everything else*.) Maybe there will be an add-on, so that those who care can choose to integrate Thunderbird into their systems rather than having it still standing off to one side haughtily awaiting special treatment. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 12/10/2019 12:14, Werner Koch via Gnupg-users wrote: > After 20 years of strong resistance against implementing OpenPGP [1], they > finally seem to do it. That is a good move. Do you know why they resited OpenPGP adoption it so much? Cheers, Chris ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Fri, 11 Oct 2019 21:48, qwrd said: > Storing private keys on a smartcard is a noteworthy security > enhancement, and I would like to see smartcard support being available > in Thunderbird. Either via GnuPG or some other mechanism. Take a Yubikey or an OpenPGP smartcard, install Scute (pcks#11 provider) and GnuPG and you are done. Either S/MIME or OpenPGP. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Sat, 12 Oct 2019 02:23, Robert J. Hansen said: > on Enigmail was very real. It was created by an ambiguity in how GnuPG > returns error states: just because GnuPG says "decryption OK" doesn't Nope. They did not read the documentation and did not checked error codes. We suggest for a reason to use GPGME to make error checking easy. You can't just code things down along some specs without thinking over the implications. Still, TB is still subject to those attacks because their primary encryption protocol is S/MIME and the last time I checked S/MIME (well, CMS for the nitpickers) does not supoport any kind of authenticated encryption. In contarst OpenPGP provides this nearly for 2 decades. Mozilla has not even stepped forward and implemented one of the meanwhile old proposal to move to AE. So Microsoft had to take the lead to do this (rumors are that the next OL version will allow for GCM mode) After 20 years of strong resistance against implementing OpenPGP [1], they finally seem to do it. That is a good move. Shalom-Salam, Werner [1] Back in ~1999, when Mozilla rewrote the entire mail engine, I implemented a first version of PGP/MIME code which was rejected due to their policy of only supporting S/MIME. For a term paper a German student later took up on my code, extended and cleaned it up. Again it was rejected. About 2005 we had a meeting with them to propose that we implement S/MIME again in a way that would comply to the strong policy requirements here in Germany and also to implement OpenPGP as an additional protocol. It was again rejected. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Fri, 11 Oct 2019 20:18, Philipp Klaus Krause said: > They don't want users to require to install gpg first. And they don't > want to ship gpg with Windows installers, since it isn't MPL. The latter is just plain bullshit. There are even many proprietary products which bundle gpg or other GPL code with their proprietary or MPL licensed code. Not just small companies but large ones with huge and conservative legal departments. The actual requirements for distribution are easy to fulfill and are actually easier with the GPLv3 than with the v2. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Hej all, Am 12.10.19 um 08:23 schrieb Robert J. Hansen: > they're going to insist on running their own keyring internal to > Thunderbird which isn't shared with anything else. (I imagine > *importing* from a GnuPG keyring will be supported, but *sharing* a > keyring is right out.) _They_ can insist on whatever they want. If they close their shop towards external built keys (for example with xca), they hopefully won't find much acceptance. regards, B. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Which ccomplexity? Creating the Key is the only thing that the normal User has to do, That is possible via a Menue Entry. I don´t see the Problem. Am 2019-10-11 um 21:49 schrieb Chris Narkiewicz via Gnupg-users: On 09/10/2019 08:06, Tony Lane via Gnupg-users wrote:> It doesn't do that? Why would they choose to tightly couple TB with OpenPGP? If I have to maintain two key databases, that's a dealbreaker for me. Dealing with GnuPG complexity is a deal breaker for ordinary users, preventing adoption. You need to look at it from product/business development perspective and it makes perfect sense that they want to ship their own UX. Also, they mention that the key management workflow is something they plan to address. Cheers, Chris ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users Thanks, -- -== Jan-Peter Rühmann & Kuma =- Gubkower Str.7 [ Tel.: +49 38205 65484 ] jan-pe...@ruehmann.name 18195 Cammin / Prangendorf [ FAX: +49 38205 65212 ] https://www.ruehmann.name WhatsApp: 491621316054 [ Tel.: +49 38205 65215 ] Twitter: @JPRuehmann [ Mobil: +49 162 1316054 ] IT-Servicetechniker -=- Die Verwendung der Daten zu Werbezwecken ist verboten. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
> PGP and GnuPG and the related communities have tried really hard to > build a system based on person's long-term identity keys. All that web > of trust thing relies on keys that are used relatively long time. But as > we know this doesn't work for most people. People are really bad at > maintaining long-term identity keys. A few years ago at Circumvention (the first Internet Freedom Festival), I was asked to give an impromptu talk on Things You're Doing Wrong With OpenPGP. The first thing on my list was certificate lifetime. We teach people the importance of maintaining their certificate for the long haul, but we also know very few people are capable of doing that. What we *don't* teach them is how to rebuild their trust network after a loss-of-certificate event. So when someone loses their cert, or has a system compromise, or their YubiKey goes through the laundry, or what-have-you, they get a double whammy of failure: they feel like a failure because they didn't do this thing that was expected of them (keep the cert for 20+ years, never mind how unreasonable that it), and they feel like a failure for not knowing how to recover from it. So instead: teach people that it's okay to lose a cert, so long as you have a plan to come back from it. Then if their Yubi goes through the laundry they (a) don't feel like a failure and (b) already have a plan for how to move forward. Seriously, ending the Cult of the Long-Term Certificate is one of the simple but good things I think we should be embracing for the sake of users. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Philipp Klaus Krause [2019-10-08T15:34:28+02] wrote: > It would be really nice, if Thunderbird could add an option to use the > gpg key storage instead of its own, [...] I agree with that even though I have never really used Thunderbird. But using a custom key storage and implementation (or do they use Sequoia PGP library?) is an interesting choice in the world of Unix-like systems. It's pretty much the normal way elsewhere, though. PGP and GnuPG and the related communities have tried really hard to build a system based on person's long-term identity keys. All that web of trust thing relies on keys that are used relatively long time. But as we know this doesn't work for most people. People are really bad at maintaining long-term identity keys. I think this is the most important reason why other software just auto-generate "device keys" or "application keys" and exchange them. They just forget about the identity part and keys' usage in the long term. Change your phone or just reinstall the application and you'll have new keys. Keys come and go and it's perfectly normal. Thunderbird seems to be going to that direction and it is probably a good thing. From the mindset of crypto nerds (like us) or Unixy tool box this can be a barrier, obviously. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tliko...@iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
> Why the heck don't they just run gpg the way enigmail did? Three major reasons: 1. License incompatibility. GnuPG is GPLv3, and Mozilla uses the Mozilla Public License. They're not compatible. Arguably (and I believe _correctly_) distributing GnuPG with Moz wouldn't be a dealbreaker, as mere aggregation is different from actually linking, but lawyers are by nature conservative. Moz has already said their lawyers won't let them do this. 2. Dependencies. Mozilla will not accept responsibility for users doing foolish things with their gpg.conf files, because those users will expect Mozilla to fix it for them. It's a dealbreaker. This is also why Mozilla has declared they won't even support using GnuPG keyrings -- they're going to insist on running their own keyring internal to Thunderbird which isn't shared with anything else. (I imagine *importing* from a GnuPG keyring will be supported, but *sharing* a keyring is right out.) 3. Enigmail has shown them the limitations of GnuPG. The Efail attack on Enigmail was very real. It was created by an ambiguity in how GnuPG returns error states: just because GnuPG says "decryption OK" doesn't mean it was decrypted okay. (Whether Enigmail should've understood this, or whether GnuPG should have not returned such an ambiguous message, is an open question and not one I'm interested in discussing.) Rather than repeat Enigmail's interface, which historically had its fair share of security problems, Mozilla has decided to go a different route. More power to 'em. I love Enigmail, but it's the nature of all software that at some point we learn how to do things better. When we learn how to do things better, we should elect to do them better rather than stay mired in the past. (... and that principle, applied to OpenPGP, suggests throwing out a whole lot of cruft. Which is another open question I'm not interested in discussing, except to throw it out there for people to think about.) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
> >> On 9 Oct 2019, at 04:47, Philipp Klaus Krause wrote: >> >> It would be really nice, if Thunderbird could add an option to use the >> gpg key storage instead of its own, but so far the developers want to >> always keep the Thunderbird key storage separately (thoug they are >> considering functionality to import keys from gpg to Thunderbird): > > Agreed. Such functionality is vital for those of us who use smartcards. > > A > I would like to second this. Storing private keys on a smartcard is a noteworthy security enhancement, and I would like to see smartcard support being available in Thunderbird. Either via GnuPG or some other mechanism. Mis > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Am 11.10.19 um 20:15 schrieb Phillip Susi: > Why the heck don't they just run gpg the way enigmail did? > They don't want users to require to install gpg first. And they don't want to ship gpg with Windows installers, since it isn't MPL. Philipp signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 09/10/2019 08:06, Tony Lane via Gnupg-users wrote:> It doesn't do that? Why would they choose to tightly couple TB with > OpenPGP? If I have to maintain two key databases, that's a dealbreaker for me. Dealing with GnuPG complexity is a deal breaker for ordinary users, preventing adoption. You need to look at it from product/business development perspective and it makes perfect sense that they want to ship their own UX. Also, they mention that the key management workflow is something they plan to address. Cheers, Chris ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 11/10/2019 19:15, Phillip Susi wrote: > Why the heck don't they just run gpg the way enigmail did? They don't want to bundle GnuPG because of GnuPG licence: https://wiki.mozilla.org/Thunderbird:OpenPGP:2020#OpenPGP_engine Requiring user to set up GnuPG separately is out of question if they want to achieve any sensible level of adoption. There is another matter of key distribution and I guess they plan on taking control over it to provide acceptable level of UX. Cheers, Chris ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Philipp Klaus Krause writes: > While having OpenPGP support directly in Thunderbird is probably a good > thing, I found it convenient to just use the gpg kerys for Email > encryption and signing (and conversely, being able to just use keys > imported via Enigmail to encrypt files using gpg). > It would be really nice, if Thunderbird could add an option to use the > gpg key storage instead of its own, but so far the developers want to > always keep the Thunderbird key storage separately (thoug they are > considering functionality to import keys from gpg to Thunderbird): Why the heck don't they just run gpg the way enigmail did? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Hello I think it is an good Idea for such OSes as Windows or MAC that mainly depends on closed completely integrated Software. But for Linux/Unix and alike it goes against the main principles of that Software. And I think it will disturb the Development and Evolution of Software such as PeP, PGP, OpenPGP and so on what´s bad. Am 2019-10-09 um 08:23 schrieb Andrew Gallagher: On 9 Oct 2019, at 04:47, Philipp Klaus Krause wrote: It would be really nice, if Thunderbird could add an option to use the gpg key storage instead of its own, but so far the developers want to always keep the Thunderbird key storage separately (thoug they are considering functionality to import keys from gpg to Thunderbird): Agreed. Such functionality is vital for those of us who use smartcards. A ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users I hope Mozilla will rethink that. Thanks, -- -== Jan-Peter Rühmann & Kuma =- Gubkower Str.7 [ Tel.: +49 38205 65484 ] jan-pe...@ruehmann.name 18195 Cammin / Prangendorf [ FAX: +49 38205 65212 ] https://www.ruehmann.name WhatsApp: 491621316054 [ Tel.: +49 38205 65215 ] Twitter: @JPRuehmann [ Mobil: +49 162 1316054 ] IT-Servicetechniker -=- Die Verwendung der Daten zu Werbezwecken ist verboten. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Patrick Brunschwig wrote: > The Thunderbird developers have announced that they will implement OpenPGP > support in Thunderbird 78 [1]. A long awaited news indeed! > Support for Thunderbird in Enigmail will therefore be discontinued. Pity, but I hope it will be better that way. In particular I hope, that Mozilla will not follow your example and won’t entice users to proprietary isolated keyserver [0] instead of distributed SKS network thus splitting the keybase. And won’t promote standards [1] that suspiciously resemble embrace-extend-and-extinguish tactics employed against PGP either. [0] https://keys.openpgp.org [1] https://pep.security signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Hi Patrick, >The Thunderbird developers and I have therefore agreed that it's much >better to implement OpenPGP support directly in Thunderbird. The set of >functionalities will be different than what Enigmail offers, and at >least initially likely be less feature-rich. But in my eyes, this is by >far outweighed by the fact that OpenPGP will be part of Thunderbird and >no add-on and no third-party tool will be required. Great news overall and thanks for the announcement. Thunderbird with direct OpenPGP integration has long been overdue IMHO. So according to the wiki page [1] I understand that the secret keys will be managed by Thunderbird. That is quite a limitation I think, in contrast to reusing a GPG agent of some sort. Depending on the chosen alternative, it might offer better OS integration, a long time proven secure process architecture, possible reuse with only one central key store and most of all integration with hardware tokens. I personally would not entrust my private keys to a mail application that also displays HTML and possibly executes JavaScript etc. after what we have seen with Efail for example. So could you please elaborate or extend the wiki page to clear up how hardware tokens fit into the new picture? Thanks and kind regards. André [1]: https://wiki.mozilla.org/Thunderbird:OpenPGP:2020 -- Greetings... From: Andre Colomb ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/8/19 9:34 AM, Philipp Klaus Krause wrote: > It would be really nice, if Thunderbird could add an option to use the > gpg key storage instead of its own, but so far the developers want to > always keep the Thunderbird key storage separately (thoug they are > considering functionality to import keys from gpg to Thunderbird): It doesn't do that? Why would they choose to tightly couple TB with OpenPGP? If I have to maintain two key databases, that's a dealbreaker for me. Welp, looks like I won't be upgrading. Thanks Mozilla. -BEGIN PGP SIGNATURE- iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXZ2G+QAKCRDo8fj9gx4T 04hBAgkBa3KJriiIvDBG91RKezHEYrPK10Y8Rcc4rYa4RSTq266MGgNu8R0lY8q9 dSYL6JgM+aRvfvD56bclhkTVl/mROJECBiIeo/CBtU78+RFq8hbgpb+4hI5GKt+R s2/Oabhg+t5i9TZ4c3pG9y30A6Ih01bFgeX6FMA7HliGPGKr3PuWG0QO =AwFo -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
> On 9 Oct 2019, at 04:47, Philipp Klaus Krause wrote: > > It would be really nice, if Thunderbird could add an option to use the > gpg key storage instead of its own, but so far the developers want to > always keep the Thunderbird key storage separately (thoug they are > considering functionality to import keys from gpg to Thunderbird): Agreed. Such functionality is vital for those of us who use smartcards. A ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
While having OpenPGP support directly in Thunderbird is probably a good thing, I found it convenient to just use the gpg kerys for Email encryption and signing (and conversely, being able to just use keys imported via Enigmail to encrypt files using gpg). It would be really nice, if Thunderbird could add an option to use the gpg key storage instead of its own, but so far the developers want to always keep the Thunderbird key storage separately (thoug they are considering functionality to import keys from gpg to Thunderbird): https://wiki.mozilla.org/Thunderbird:OpenPGP:2020 Philipp signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Patrick Brunschwig wrote: > The Thunderbird developers have announced that they will implement > OpenPGP support in Thunderbird 78 [1]. Support for Thunderbird in > Enigmail will therefore be discontinued. [snip] > The Thunderbird developers and I have therefore agreed that it's much > better to implement OpenPGP support directly in Thunderbird. The set of > functionalities will be different than what Enigmail offers, and at > least initially likely be less feature-rich. But in my eyes, this is by > far outweighed by the fact that OpenPGP will be part of Thunderbird and > no add-on and no third-party tool will be required. Great news, Patrick. Thanks for sharing! Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users