Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 22/05/2018 02:16, Mauricio Tavares wrote: Stupid question: what is wrong with a "encrypt/decrypt old format" flag/config option? If I have the need to use old stuff, I can turn that on. All I see here is a "do not open old stuff" as a default setting which should solve most issues. ... There would be nothing wrong with that whatsoever from the perspective of users who need to access old encrypted data (e.g. archival access purposes), which is the particular use case I have been pointing out. However, I don't think this would satisfy those who want to ensure that users cannot encrypt new data with legacy standards. In order to prevent users from doing this (which, to be clear, is something I agree with) there needs to be some way to make it difficult or impossible = There is a simple solution that would satisfy everybody ;-) Keep an 'old' edition of GnuPG 1.4x for anyone who needs to decrypt 'old data', (or encrypt new data the 'old' way ...). As one of the original die-hard pgp2.x users who still uses pgp (Disastry's 2.6.3 multi), I can comfortably say, that 2.x diehard users still use 2.x among themselves, and don't care about GnuPG. The real issue is, that it's not easy to compile 2.x on newer systems, and people who have migrated to GnuPG on some remailer groups, still want to use their v3 keys, and need encrypting capability, which again would be solved by letting them use an 'old' version of 1.4.x, and as long as these versions are still being archived (which is reasonable for the forseeable future), they should have no problems. So, to put in a vote for RJH, “Break backwards compatibility already: it’s time. Ignore the haters. I trust you.” vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 05/21/2018 03:38 PM, Mark Rousell wrote: > On 22/05/2018 02:16, Mauricio Tavares wrote: >> Stupid question: what is wrong with a "encrypt/decrypt old >> format" flag/config option? If I have the need to use old stuff, I can >> turn that on. All I see here is a "do not open old stuff" as a default >> setting which should solve most issues. > > There would be nothing wrong with that whatsoever from the perspective > of users who need to access old encrypted data (e.g. archival access > purposes), which is the particular use case I have been pointing out. As I read the manual for gpg v2.2, that seems possible. The hard part, of course, is knowing what options to set. Perhaps there could be a FAQ. > However, I don't think this would satisfy those who want to ensure that > users cannot encrypt /new/ data with legacy standards. In order to > prevent users from doing this (which, to be clear, is something I agree > with) there needs to be some way to make it difficult or impossible to > encrypt new data with legacy standards /whilst allowing decryption of > legacy-encrypted data so as not to cut off long-time users with a > legitimate present day use case/. Again, as I read the manual, one can set all sorts of horrible options for encryption. Some have been deprecated, though. What I don't know is whether ancient PGP default behavior can be forced in gpg v2.2. I hope not. But even if so, it'd take considerable understanding. > If it is ultimately considered to be absolutely necessary to prevent new > data being encrypted with old standards then personally I'd like to see > a decryption-only program that would allow use cases involving access to > legacy-encrypted data to continue unmolested with maintained software > whilst allowing new data to be encrypted only with software versions > that have dropped backward compatibility. I tend to agree. But who would create and maintain that? > In large part it seems to me that there is the usual (in discussions > like this) lack of recognition of the many and varied use cases that > software like GnuPG can be and is put to. Calls for *all* backwards > compatibility to be end-of-lifed do not take into account the fact that > backward compatibility in terms of decryption capability are still valid > use cases in the present day and should rightly and properly be > supported with maintained software. Again, I don't think that's part of the plan. But I'm no expert. > I agree that preventing new data encryption with legacy standards is > desirable. Just don't throw other users (who need to decrypt old > standards and old data with currently maintained software) under the bus > to get to that state. I totally agree. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 22/05/2018 02:16, Mauricio Tavares wrote: > Stupid question: what is wrong with a "encrypt/decrypt old > format" flag/config option? If I have the need to use old stuff, I can > turn that on. All I see here is a "do not open old stuff" as a default > setting which should solve most issues. There would be nothing wrong with that whatsoever from the perspective of users who need to access old encrypted data (e.g. archival access purposes), which is the particular use case I have been pointing out. However, I don't think this would satisfy those who want to ensure that users cannot encrypt /new/ data with legacy standards. In order to prevent users from doing this (which, to be clear, is something I agree with) there needs to be some way to make it difficult or impossible to encrypt new data with legacy standards /whilst allowing decryption of legacy-encrypted data so as not to cut off long-time users with a legitimate present day use case/. If it is ultimately considered to be absolutely necessary to prevent new data being encrypted with old standards then personally I'd like to see a decryption-only program that would allow use cases involving access to legacy-encrypted data to continue unmolested with maintained software whilst allowing new data to be encrypted only with software versions that have dropped backward compatibility. In large part it seems to me that there is the usual (in discussions like this) lack of recognition of the many and varied use cases that software like GnuPG can be and is put to. Calls for *all* backwards compatibility to be end-of-lifed do not take into account the fact that backward compatibility in terms of decryption capability are still valid use cases in the present day and should rightly and properly be supported with maintained software. I agree that preventing new data encryption with legacy standards is desirable. Just don't throw other users (who need to decrypt old standards and old data with currently maintained software) under the bus to get to that state. -- Mark Rousell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking changes
On 05/21/2018 02:57 PM, Mark Rousell wrote: > On 22/05/2018 02:39, Mark Rousell wrote: >> Get real. These people are long-time GnuPG users and now you want to >> throw them under the bus because... well, because you prefer it that >> way. No, that's not a fair, it's not reasonable, it's not ethical, or >> it's even professional. [etc etc] > > On re-reading the above message, I apologise if the language I used was > provocative. However, the points I made are nevertheless valid in my > opinion. Hey :) > Proposing cutting off maintenance of the only maintained route to > decrypt certain data is provocative, of course. ;-) As I observed, it is > not necessary to cut off maintained ability to decrypt historical data > (surely a valid real world use case) in order to prevent users from > encrypting new data with legacy standards. So is there anything that gpg v2.2 won't decrypt with the option "--ignore-mdc-error" specified? Or perhaps, with also other "Doing things one usually doesn't want to do." options? That is, are older versions really necessary? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking changes
On 22/05/2018 02:39, Mark Rousell wrote: > Get real. These people are long-time GnuPG users and now you want to > throw them under the bus because... well, because you prefer it that > way. No, that's not a fair, it's not reasonable, it's not ethical, or > it's even professional. [etc etc] On re-reading the above message, I apologise if the language I used was provocative. However, the points I made are nevertheless valid in my opinion. Proposing cutting off maintenance of the only maintained route to decrypt certain data is provocative, of course. ;-) As I observed, it is not necessary to cut off maintained ability to decrypt historical data (surely a valid real world use case) in order to prevent users from encrypting new data with legacy standards. -- Mark Rousell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 22/05/2018 02:47, Mirimir wrote: > > But OK. The point here is not to expect that you can open such archives > in an email client with Internet access, which is also receiving new > email. Because that makes it vulnerable to Efail and follow-ons. I agree. > So put > the archives in an air-gapped machine, with a suitably tweaked email > client to access them. Not all archived and encrypted data is emails. There can be all sorts of things. It doesn't really matter what and it's not up to us to tell people what their system architecture should be. As long as they have access to maintained software to access (i.e. decrypt only) this old data (and this project is definitely the best source of such maintained software) then that is enough to satisfy what I perceive as critical requirements for many types of user in this category. -- Mark Rousell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking changes
On 21/05/2018 10:46, Ralph Seichter wrote: > On 21.05.18 07:20, Robert J. Hansen wrote: > >> We should keep the 1.4 source code available, but wash our hands of it >> and say it will receive *no* future fixes, not even for security >> issues -- and we need to stand on that when people start screaming. > I agree. In my experience, this stance--publicly documented--will allow > people to say to their bosses "support has ended, and for security > reasons we now need a budget to finance a move away from this outdated > software". I have seen similar situations often enough; nobody would > spend money as long as the old software horse was still twitching. > > Discontinue version 1.4 right away, quoting Efail as a trigger if you > wish, and set an EOL for version 2.0 in a few months, as you suggested. It's not that simple. There are more use cases to take into account. Whilst what you say is true for people still encrypting new data with 1.4 (and I agree that they should be prevented from doing so), there are other people (perhaps even more people) who have a legitimate need to access historical/archival encrypted data. Preventing users from encrypting new data using legacy encryption does NOT need to mean that other users have to be prevented from (quite legitimately) accessing archived data using legacy encryption with maintained software. -- Mark Rousell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking changes
On 21/05/2018 06:20, Robert J. Hansen wrote: > Here's my own set of suggestions for breaking changes to GnuPG: > > 1. End-of-life 1.4 already. > > Yes, it's the only option for PGP 2.6. Yes, it's the only option for > old and out-of-date stuff. Yes, there will be people who need to > decrypt this stuff. All of that is true, but *we* don't need to be the > people who cater to their needs. Get real. These people are long-time GnuPG users and now you want to throw them under the bus because... well, because you prefer it that way. No, that's not a fair, it's not reasonable, it's not ethical, or it's even professional. > At this point if you need pre-Web > crypto (which, I remind people, is pretty much what PGP 2.6 is), you > have a specialized need and you need to talk to someone about a custom > solution. Err... the specialised solution surely is GnuPG 1.4. > There are companies that specialize in this sort of thing > (like, say, g10 Code). So you are saying that long-time users should be deprived of an open source ongoing-maintained solution to their entirely valid present day use case to benefit a private company. Isn't that effectively equivalent to commercial sponsors taking previously open source code base private? It's hardly a popular move when it happens. Yes, I know that the scenario you are proposing is not /exactly/ the same but people will, quite understandably, treat it as such. > We should keep the 1.4 source code available, but wash our hands of it > and say it will receive *no* future fixes, not even for security issues > -- and we need to stand on that when people start screaming. Surely if you can recognise that people will start screaming then you must also understand that it is entirely the wrong thing to do. > Rationale: as long as we keep GnuPG 1.4 around and even semi-supported, > people will insist on not upgrading. If you drop maintenance of code that can handle the data that some people need to cope with then they will naturally have to stay with old, unmaintained code anyway. So dropping maintenance of 1.x will only cause a problem in this respect, not cure on. If you are (understandably) concerned about people still use 1.4 for encryption of new data then the sensible choice is surely to do what people have suggested in this thread: That is to produce a decryption-only maintained version that still allows users who need to access archived legacy-encrypted data to do so. Clearly you are concerned with preventing people using legacy encryption for new data and I agree with this concern. But there is no need to throw present day, long-time users who must handle legacy-encrypted data under the bus to do so. -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 05/21/2018 02:41 PM, Mirimir wrote: > Yes, "accepting new emails with old crypto" is the problem. But Efail > relies on cyphertext embedded in URLs, which won't unauthenticate. Damn copypasta :( Please make that: > Yes, "accepting new emails with old crypto" is the problem. But Efail > relies on cyphertext embedded in URLs, which won't authenticate. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 05/21/2018 02:06 PM, Mark Rousell wrote: > On 21/05/2018 23:17, Mirimir wrote: >> On 05/21/2018 02:06 AM, Ed Kellett wrote: >> >> >> >>> Maybe they just want to be able to read emails that they received a long >>> time ago? >> So decrypt them all into a ramdisk, tar, and encrypt with GnuPG. Or put >> it on a backup box with LUKS. Or both. > > You are proposing to alter archival data. That's not an option. If you > change it then you've changed the archive then it is no longer an > accurate archive. Well, there are all sorts of archives, I guess. But OK. The point here is not to expect that you can open such archives in an email client with Internet access, which is also receiving new email. Because that makes it vulnerable to Efail and follow-ons. So put the archives in an air-gapped machine, with a suitably tweaked email client to access them. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility
On 21/05/2018 08:53, Michael Kesper wrote: > I think it might be best to put that functionality into a separate > GnuPG version called gpg-legacy. > Make it clear in all man pages of this tool, the --version and --help > options that this only exists to decrypt existing but now obsolete > encrypted material and that it can't be used to create such material > anymore. Seems reasonable to me, although does GnuPG 1.x already effectively fulfil that role? -- Mark Rousell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility
On 21/05/2018 04:56, Jochen Schüttler wrote: > Some people have the necessity to decrypt old data, so there should be a > separate tool for them to do exactly that. It's the only way to start > off fresh. Agreed. And I think that GnuPG 1.x provides this tool, doesn't it. -- Mark Rousell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 21/05/2018 04:14, Jean-David Beyer wrote: > On 05/20/2018 08:51 PM, Jeremy Davis wrote: >> I just read the awesome article "Efail: A Postmortem" by Robert Hansen. >> >> Thanks for this Robert. Great work! >> >> As suggested by Robert, I've signed up to say: >> >> Break backwards compatibility already: it’s time. Ignore the haters. I >> trust you! :) >> > One of the problems with Windows is that they preserved the backwards > compatibility for far too long, so they could never clean it up enough > to make it any good. I admit that Windows 7 is better than Windows XP > that was much better than Windows 95. Different mindsets. You call it a problem but from the perspective of a great many Windows users, backwards compatibility (i.e. stability) is a key feature, not a bug. However, GnuPG clearly can make backwards-incompatible progress without dropping all maintained support for legacy decryption. -- Mark Rousell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 05/21/2018 02:06 AM, Ed Kellett wrote: > On 2018-05-21 09:56, Andrew Skretvedt wrote: >> It seems to me that if the pearl-clutchers who would howl too loudly >> about breaking backwards compatibility were as concerned as they claim, >> they would realize that software evolves. But this evolution doesn't >> eradicate its past. GnuPG is open software. It's ganoo-pee-gee! >> >> If you're a pearl-clutcher with a legacy use-case, perhaps it's time to >> really analyze that case. Do you have a darn good reason to want to >> expose yourself to creeping insecurity? Because its history won't be >> eradicated, if you /do/ have good reasons, you can maintain for yourself >> a legacy fork. To do that you may need to have certain skills or be >> willing to hire-out for them. > > Maybe they just want to be able to read emails that they received a long > time ago? > > I don't. I didn't start using OpenPGP long enough ago. But I think it's > a bit unfair to call this "exposing yourself to creeping insecurity". It > shouldn't ever be dangerous to *read an email* with an up-to-date email > client, no matter what, because emails shouldn't be able to phone home. > And the emails we're sending and receiving now aren't going to become > more dangerous as time passes (though they could become less so, if a > current vulnerability is mitigated by future client software). The problem is that many users of up-to-date email clients seem to want HTML with remote content. That allows Efail, but only if OpenPGP does not hard fail for unauthenticated cyphertext. And that typically breaks decryption of cyphertext created by old software, which didn't require authentication by default. > I guess what I'm trying to say here is that it's not decrypting old > crypto that's wrong. It's accepting new emails with old crypto that is > wrong. Yes, "accepting new emails with old crypto" is the problem. But Efail relies on cyphertext embedded in URLs, which won't unauthenticate. Anyway, the solution is arguably making decryption of iffy cyphertext an option that must be explicitly selected. Not the default. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A postmortem on Efail
On 21/05/2018 13:34, Ben McGinnes wrote: > I agree with most of the article and largely with the need to break > compatibility to an ancient flawed design. Particularly since we > still have a means of accessing those ancient formats if we have to in > the form of the GPG 1.4 branch. The ancient archives are as safe as > they've ever been (for whatever definition of "safe" is being implied > by the user/archivist). Indeed, this satisfies my archive retrieval concerns. > There is, however, one aspect of this issue that you touched on > lightly, but didn't really delve into and which is at the centre of > my, mostly unvoiced (until this email), criticism of the Efail team. > That being the *incredibly* unhelpful and likely actively harmful > recommendation to remove encryption and decryption functionality from > vulnerable MUAs. > > To say, “we have this edge case scenario that really needs an active > targeted attack on a case by case basis, so everyone should just stop > integrating encryption” is the kind of thing that can get people > killed. This has been commented on by a few people on this list, myself included: [1] To my mind, it reeks of slanted propaganda for Signal, and there does seem to be a lot of it around at the moment. Signal has security benefits but it's not (yet?) a replacement for encrypted email, whereas a number of commentators seem to treat it as if all email, encrypted or not, should be deprecated in favour of Signal. This is not sensible or good advice without considering individual use cases (regardless of Efail). > I *do*, however, care that their > recommendations may have lasting and potential final consequences for > OpenPGP users living with and attempting to mitigate real threats to > their lives and/or liberty. > > Playing with that sort of thing with the recklessness with which the > Efail team have done is, in my not so humble opinion, an absolute > disgrace. > > You pointed out that the vast majority of OpenPGP use is no longer > email or other communications encryption. This is both true and a > valid point of discussion. Nevertheless, there are still a > considerable number of people who do use it that way and a number of > them have to deal with threat assessments with considerably higher > levels of personal risk than security researchers in academia or > cryptographic developers. > > We must not forget these people. Ever. Even if we never hear from > them. Their cases are also not a matter of being apathetic; it's that > their priorities are surviving the world they're in, so they need to > rely on the tools we provide (and I get the community apathy issue is > actually a more general thing, so this isn' having a go at that part). > > The Efail researchers did forget them and their conduct demonstrates > this. While they may have made some useful technical contributions > regarding S/MIME and highlighting certain poor implementations in > MUAs, that's no justification for reckless disregard of the lives of > end users. Well said. > So in my opinion it's not the merits or lack thereof in the > demonstrated attacks they released that have the gravest consequence > here, it's that the number one recommended mitigation technique is to > remove cryptographic functions from MUAs. Without wanting to sound like a conspiracy geek, removing encryption from email would, of course, benefit Signal and its takeup. [1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060450.html -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 21/05/2018 23:17, Mirimir wrote: > On 05/21/2018 02:06 AM, Ed Kellett wrote: > > > >> Maybe they just want to be able to read emails that they received a long >> time ago? > So decrypt them all into a ramdisk, tar, and encrypt with GnuPG. Or put > it on a backup box with LUKS. Or both. You are proposing to alter archival data. That's not an option. If you change it then you've changed the archive then it is no longer an accurate archive. -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 21/05/2018 09:56, Andrew Skretvedt wrote: > I think Efail has shown now that OpenPGP/GnuPG retains the flexibility > to continue to adapt and maintain a well used and trusted standard for > private and authenticated data and communications, but it won't > achieve this if its evolution is frozen. I agree. But remember that retaining the ability to decrypt legacy-encrypted data (i.e. continuing to support long-time users) does not require the GnuPG's evolution be frozen. > It seems to me that if the pearl-clutchers who would howl too loudly > about breaking backwards compatibility were as concerned as they > claim, they would realize that software evolves. But this evolution > doesn't eradicate its past. GnuPG is open software. It's ganoo-pee-gee! > > If you're a pearl-clutcher with a legacy use-case, perhaps it's time > to really analyze that case. Do you have a darn good reason to want to > expose yourself to creeping insecurity? Because its history won't be > eradicated, if you /do/ have good reasons, you can maintain for > yourself a legacy fork. To do that you may need to have certain skills > or be willing to hire-out for them. > > I think that's fair. It's free as in freedom, not beer, not support. > For my vote, I think persons so situated might have suddenly imposed > upon the larger community long enough, now that Efail has taught us > something we may not have fully appreciated about the present state of > OpenPGP and the way it's been pipelined with other tools. Your point is not helped by using patronising and condescending language like "pearl-clutcher". What you are attempting to belittle and dismiss here is surely a perfectly valid use case: That is accessing archived data. Sure, I can see that it is not a use case that you like or that matters to you but that doesn't make it any less of a valid use case right now, today, and in the future in the real world. This is not a "legacy use-case" as you chose to name it. The fact that the data is encrypted using legacy encryption doesn't make it a "legacy use-case". There is no "creeping insecurity" whatsoever in continuing to access archival data but there would be something of an eventual creeping insecurity if users in this position were required to use unmaintained software versions. So, no, it is not fair to throw these long-time users under the bus, as you propose. No, it is utterly unreasonable to propose that they maintain their own "legacy fork". Such users have not "imposed upon the larger community": They are _part_ of the larger community. As I have said in other messages, it is entirely reasonable to expect them to make some changes (although remember that re-encrypting the data is not an option) in terms of using new versions of maintained software to be able to continue decrypting the archived data but to just cut them off such that they have to use unmaintained software is not what one should have to expect. It would be reckless. And, as I say, continuing to support present day archival use cases does not mean that the main body of GnuPG cannot move on. It most certainly can continue to evolve and should do so. But those people who have to handle legacy-encrypted data are not legacy users. -- Mark Rousell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 21/05/2018 14:06, Ed Kellett wrote: > I think it's > a bit unfair to call this "exposing yourself to creeping insecurity". It > shouldn't ever be dangerous to *read an email* with an up-to-date email > client, no matter what, because emails shouldn't be able to phone home. > And the emails we're sending and receiving now aren't going to become > more dangerous as time passes (though they could become less so, if a > current vulnerability is mitigated by future client software). > > I guess what I'm trying to say here is that it's not decrypting old > crypto that's wrong. It's accepting new emails with old crypto that is > wrong. > Well said (both paragraphs). What Andrew Skretvedt suggested is a clear example of what I earlier described[1] as "throw your long-time users or their data under the bus". It's not a reasonable option. [1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060512.html -- Mark Rousell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A postmortem on Efail
On 21/05/2018 15:17, Mark H. Wood wrote: >> Break backwards compatibility already: it’s time. Ignore the haters. I >> trust you. > (I understand that that's a quote of a discussion-opener from the write-up.) > > I'd like to first see how many haters can be won over by selling the > necessary changes. > > By "selling" I mean addressing the concerns of those who aren't > convinced that they want something: > > o Why this is important *to you*, even though its importance was not >immediately obvious. To my mind it is at the outset counter-productive to refer to "haters". To use the term "haters" implies that anyone who does not share one's own view is somehow wrong and/or that their arguments can potentially be dismissed on the grounds or emotionalism rather than rationality. In practice, those like myself who recognise that the ability to decrypt legacy-encrypted data is a basic requirement for many users with archival needs do not "hate" anything. We just recognise that decryption of legacy-encrypted data is a real world requirement right now and will continue to be for many years, and so I think it is right and proper for this project to continue to support this activity with maintained software (albeit with a requirement for users to make some changes to support such activity). > o What we have done, and are doing, to keep *your* cost down. If the aim is to keep end-users' costs down then do not completely remove legacy features that are still needed in the real world. Decryption of legacy-encrypted data is one of those features, like it or not. > o What else would we need to do, to make this something *you* want? Go back in time and change history! What is now archived is archived and cannot be changed. Like it or not, it will need to be decrypted for a very long time to come. Ideally this should be achievable with maintained, current-version software. By all means, if that software needs to be a special-use, decrypt-only, program that is hardly ever updated except to patch code vulnerabilities then so be it. But do not throw your long-time users or their data under the bus for the sake of eliminating backwards compatibility. Stability and compatibility really do matter to many classes of users. -- Mark Rousell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A postmortem on Efail
On 21/05/2018 14:31, Ben McGinnes wrote: > I could have given them that benefit of the doubt on the initial > article too, but the FAQ they now have on the Surveillance > Self-Defense website does rather eviscerate any hope of that: > > https://ssd.eff.org/en/blog/pgp-and-efail-frequently-asked-questions > > “What if I keep getting PGP emails? > > You can decrypt these emails via the command line. If you prefer not > to, notify your contacts that PGP is, for the time being, no longer > safe to use in email clients and decide whether the conversation can > continue over another end-to-end encrypted platform, such as Signal.” > > Because that couldn't possibly create a Chinese Whispers style > situation of self-perpetuating FUD … 臘 Very foolish and very slanted indeed in a certain direction. -- Mark Rousell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A postmortem on Efail
On 21/05/2018 09:54, Damien Goutte-Gattat via Gnupg-users wrote: > On 05/21/2018 04:07 AM, Mark Rousell wrote: >> I think you mean that support for 2.0.y has been dropped, surely? > No, I do mean that support for all PGP 2-related stuff has been dropped > from the current stable branch. Modern GnuPG (≥ 2.1) can neither read > nor write anything that has been generated by PGP 2.x. Compatibility > starts with PGP 5, which dates back to 1997. Ah, gotcha. I was being careless over terminology. >> When I wrote "2.x.y" above I meant that users should be able >> to continue decrypting legacy-encrypted data (albeit with a change of >> commands/options compared to the present) with whatever the >> currently-supported version of 2.something is at any point in the >> future. > Well, that's already not the case. If you have pre-1997 data, you need > to use GnuPG 1.4, which again *is* still supported precisely for this > use case. (You could also, in theory, use GnuPG 2.0.x, but *that* branch > is explicitly no longer supported.) Thanks. This satisfies my preferences, that legacy-encrypted data can be decrypted with maintained code. -- Mark Rousell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Duplicate personal key in keyring
Hello Justin. Am Montag, den 21.05.2018, 11:25 -0500 schrieb Justin Hibbits: > Through some unknown series of events, I now have two copies of my > personal gpg key in my keyring. I double-checked to see if GPG is > seeing the same key in two keyrings (maybe reading a backup), but > both > keys are being read from the same keyring. > This leads me to two questions: > 1) How could this happen in the first place? I had a similar problem a while ago. In my case the key database was corrupted. > 2) How can I fix this, short of generating a new key and revoking the > existing key? In my case I exported the public and the private keys of my own keys, then exported the complete public key ring, both ascii armored. Then I simply deleted the key database file(s) and re-imported the exports. GPG imports keys only once, so the duplicates should vanish when re- importing. > I've tried backing up the keyring and deleting one copy, but it > deleted both copies. I searched online for anyone else who had a > similar issue, and came up empty, except for one person who was > seeing the same key from two files. Did you make an ascii armored export, or what kind of Backup do you mean? Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 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: A postmortem on Efail
On 05/21/2018 02:31 AM, Ben McGinnes wrote: > On Sun, May 20, 2018 at 01:43:07PM -1100, Mirimir wrote: >> On 05/19/2018 11:44 PM, Aleksandar Lazic wrote: >>> >>> I do not want to create a conspiracy theory but it's wiggy that >>> EFF favors *NO* security ,pgp or s/mime, instead to fix the current >>> possibilities and promote signal. >> >> I read the EFF warning as a temporary measure, to prevent >> adversaries from sending cyphertext, and getting plaintext >> back. Until these exploits were blocked. And if necessary, to use >> Signal in the interim. > > I could have given them that benefit of the doubt on the initial > article too, but the FAQ they now have on the Surveillance > Self-Defense website does rather eviscerate any hope of that: > > https://ssd.eff.org/en/blog/pgp-and-efail-frequently-asked-questions > > “What if I keep getting PGP emails? > > You can decrypt these emails via the command line. If you prefer not > to, notify your contacts that PGP is, for the time being, no longer > safe to use in email clients and decide whether the conversation can > continue over another end-to-end encrypted platform, such as Signal.” > > Because that couldn't possibly create a Chinese Whispers style > situation of self-perpetuating FUD … 臘 > > > Regards, > Ben I hadn't seen that. Pretty stupid :( ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 05/21/2018 02:06 AM, Ed Kellett wrote: > Maybe they just want to be able to read emails that they received a long > time ago? So decrypt them all into a ramdisk, tar, and encrypt with GnuPG. Or put it on a backup box with LUKS. Or both. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Duplicate personal key in keyring
Through some unknown series of events, I now have two copies of my personal gpg key in my keyring. I double-checked to see if GPG is seeing the same key in two keyrings (maybe reading a backup), but both keys are being read from the same keyring. This leads me to two questions: 1) How could this happen in the first place? 2) How can I fix this, short of generating a new key and revoking the existing key? I've tried backing up the keyring and deleting one copy, but it deleted both copies. I searched online for anyone else who had a similar issue, and came up empty, except for one person who was seeing the same key from two files. Any help is appreciated. As a last resort I could revoke the key and generate a new one, but I would like to avoid that if possible. Thanks, Justin Hibbits ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: efail is imho only a html rendering bug
(Only to point the finger at the real bug) Efail is not just an HTML rendering bug. It includes very real attacks against S/MIME as it's used by thousands of corporations. It's true that the cryptanalytic attack on OpenPGP is pretty much nothing. But even then, there's room to argue whether GnuPG has made it too easy for email clients to do the wrong thing. Efail is not just an HTML rendering bug. The hype around it is awful, but there are good things in the paper and we should be careful not to wash our hands of it and say "nope, not our problem..." ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A postmortem on Efail
On Mon, May 21, 2018 at 08:51:17AM -0400, Robert J. Hansen wrote: >> That being the *incredibly* unhelpful and likely actively harmful >> recommendation to remove encryption and decryption functionality from >> vulnerable MUAs. > > I blame the EFF for that more than I blame the Efail developers. I > expect the people who develop new attacks to overstate their > importance: it's not out of any intent to deceive, it's just that > they're too close to the problem to have a clear perspective on the > user impact. That is a good point and a fairly common situation; possibly the second most common form of engineering blindness (the first one being having a favourite tool and applying it to every problem regardless of relevance — when armed with one's favourite hammer, everything looks like a nail). > The EFF, though... Indeed … > But even then, I have some sympathy for their position. The EFF > works with many different activists in many different countries > running many different setups. They were in a difficult situation > of needing to put out a press release that had useful > recommendations for everyone, left no one out in the cold, while > still not raising a panic. Had their publications been limited to the articles on the 13th and 14th, I could buy that. Unfortunately the updates to the SSD website on the 15th really strain things, especially the FAQ. Not only is it potentially panic-inducing, but they recommend an approach of having end users campaign against using OpenPGP at all with all of their contacts with no regard for what additional circumstances those contacts have. They've literally created a FUD-virus as a meme which will self-replicate throughout the web-of-trust. I'm sure we'll be encountering people advising others not to use OpenPGP long after the last of those affected MUAs are patched and *that* is stretching the edges of the term reckless (as it is usually used in legislation, e.g. reckless endangerment of life as opposed to, say, wilful endangerment of life). I also don't believe they can actually fix this now that they've created it without a complete reversal of their current position; which they can't do because of the MUAs which are affected and some users could be targeted. By the time the conditions are such that they can consistently give the “all clear” on the matter, the FUD-virus will have spread too far and be too independent of them to stop (but will still gain credibility and traction by trading off their name and reputation). > Let me be clear: I think the EFF behaved irresponsibly. But I can > be sympathetic to their situation, too. It's not a one-or-the-other > thing. Sure; doing nothing and ignoring the affected MUAs does no one any good, but this response is likely to do more harm than the thing it's intended to stop and it didn't have to be that way. Not to mention the little matter that their sole recommendation of a viable alternative in all circumstances is a service which is entirely dependent on a centralised server (or network of servers). One which explicitly cannot be implemented in a federated manner and all attempts to fork it in order to do precisely that have been abandoned as a result of Moxie's opposition to them trying to connect to his network to communicate with Signal users. It's simply not a complete replacement in spite of EFF's wish that it is. It's a great addition to a suite of of services and tools, but relying on it as a replacement for OpenPGP is misguided (not to mention impossible for some people and/or networks and/or pseudonymity requirements). > And I'm going to remain quiet on this further until I have > time to see the EFF's postmortem. I won't going beyond the current statement describing it as reckless yet and I hope I don't have to. Perhaps they will be able to do some damage control in their own review. >> Indeed, this particular release may still succeed in producing a body >> count. I am not yet aware of any confirmed fatalities stemming from >> people panicking and stopping using crypto because they listened to >> Efail and/or the EFF, but there is one particular community I'm >> watching for just that issue right now. > > If I can help in any way, please let me know. Appreciated, but in this particular case it would probably be a crime for you to do so, at least directly to said group, whereas it's perfectly legal over here. It might depend a little on the interpretation of the First Amendment over there, though, and it is still possible that those laws are unconstitutional, but it's too early to know for sure yet and it doesn't look like there are too many organisations over there wanting to challenge it (yet). Regards, Ben signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
efail is imho only a html rendering bug
Internet works because we have standards. Rfc 3986 states that URLs have to be ecoded. Redering-Engies which send unencodes content including whitespaces and newlines to an external Server are seriously broken. (Only to point the finger at the real bug) Kind Regards, Klaus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A postmortem on Efail
On Sun, May 20, 2018 at 07:23:17AM +, Dmitry Gudkov wrote: > I want to get involved and give a damn! [applause] > Break backwards compatibility already: it’s time. Ignore the haters. I > trust you. (I understand that that's a quote of a discussion-opener from the write-up.) I'd like to first see how many haters can be won over by selling the necessary changes. By "selling" I mean addressing the concerns of those who aren't convinced that they want something: o Why this is important *to you*, even though its importance was not immediately obvious. o What we have done, and are doing, to keep *your* cost down. o What else would we need to do, to make this something *you* want? -- 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: A postmortem on Efail
On Sun, May 20, 2018 at 01:43:07PM -1100, Mirimir wrote: > On 05/19/2018 11:44 PM, Aleksandar Lazic wrote: >> >> I do not want to create a conspiracy theory but it's wiggy that >> EFF favors *NO* security ,pgp or s/mime, instead to fix the current >> possibilities and promote signal. > > I read the EFF warning as a temporary measure, to prevent > adversaries from sending cyphertext, and getting plaintext > back. Until these exploits were blocked. And if necessary, to use > Signal in the interim. I could have given them that benefit of the doubt on the initial article too, but the FAQ they now have on the Surveillance Self-Defense website does rather eviscerate any hope of that: https://ssd.eff.org/en/blog/pgp-and-efail-frequently-asked-questions “What if I keep getting PGP emails? You can decrypt these emails via the command line. If you prefer not to, notify your contacts that PGP is, for the time being, no longer safe to use in email clients and decide whether the conversation can continue over another end-to-end encrypted platform, such as Signal.” Because that couldn't possibly create a Chinese Whispers style situation of self-perpetuating FUD … 臘 Regards, Ben signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 2018-05-21 09:56, Andrew Skretvedt wrote: > It seems to me that if the pearl-clutchers who would howl too loudly > about breaking backwards compatibility were as concerned as they claim, > they would realize that software evolves. But this evolution doesn't > eradicate its past. GnuPG is open software. It's ganoo-pee-gee! > > If you're a pearl-clutcher with a legacy use-case, perhaps it's time to > really analyze that case. Do you have a darn good reason to want to > expose yourself to creeping insecurity? Because its history won't be > eradicated, if you /do/ have good reasons, you can maintain for yourself > a legacy fork. To do that you may need to have certain skills or be > willing to hire-out for them. Maybe they just want to be able to read emails that they received a long time ago? I don't. I didn't start using OpenPGP long enough ago. But I think it's a bit unfair to call this "exposing yourself to creeping insecurity". It shouldn't ever be dangerous to *read an email* with an up-to-date email client, no matter what, because emails shouldn't be able to phone home. And the emails we're sending and receiving now aren't going to become more dangerous as time passes (though they could become less so, if a current vulnerability is mitigated by future client software). I guess what I'm trying to say here is that it's not decrypting old crypto that's wrong. It's accepting new emails with old crypto that is wrong. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A postmortem on Efail
> That being the *incredibly* unhelpful and likely actively harmful > recommendation to remove encryption and decryption functionality from > vulnerable MUAs. I blame the EFF for that more than I blame the Efail developers. I expect the people who develop new attacks to overstate their importance: it's not out of any intent to deceive, it's just that they're too close to the problem to have a clear perspective on the user impact. The EFF, though... But even then, I have some sympathy for their position. The EFF works with many different activists in many different countries running many different setups. They were in a difficult situation of needing to put out a press release that had useful recommendations for everyone, left no one out in the cold, while still not raising a panic. Let me be clear: I think the EFF behaved irresponsibly. But I can be sympathetic to their situation, too. It's not a one-or-the-other thing. And I'm going to remain quiet on this further until I have time to see the EFF's postmortem. > Indeed, this particular release may still succeed in producing a body > count. I am not yet aware of any confirmed fatalities stemming from > people panicking and stopping using crypto because they listened to > Efail and/or the EFF, but there is one particular community I'm > watching for just that issue right now. If I can help in any way, please let me know. > We must not forget these people. Ever. I entirely agree. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A postmortem on Efail
On Sun, May 20, 2018 at 02:26:47AM -0400, Robert J. Hansen wrote: > Writing just for myself -- not for GnuPG and not for Enigmail and > definitely not for my employer -- I put together a postmortem on Efail. > You may find it worth reading. You may also not. Your mileage will > probably vary. :) > > https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08 Very nice article and it will be a useful one to forward to a number of people. I also liked ProtonMail's more technical one which addressed the specifics of their own setup and demonstrated that the allegations levelled their way were not well founded. On the other hand, they use OpenPGP.js very differently to most, if not all, of the other projects which have since adopted it and are acutely aware of the inherent weaknesses within JavaScript itself, so they don't drive their entire systems with it. I agree with most of the article and largely with the need to break compatibility to an ancient flawed design. Particularly since we still have a means of accessing those ancient formats if we have to in the form of the GPG 1.4 branch. The ancient archives are as safe as they've ever been (for whatever definition of "safe" is being implied by the user/archivist). There is, however, one aspect of this issue that you touched on lightly, but didn't really delve into and which is at the centre of my, mostly unvoiced (until this email), criticism of the Efail team. That being the *incredibly* unhelpful and likely actively harmful recommendation to remove encryption and decryption functionality from vulnerable MUAs. To say, “we have this edge case scenario that really needs an active targeted attack on a case by case basis, so everyone should just stop integrating encryption” is the kind of thing that can get people killed. Indeed, this particular release may still succeed in producing a body count. I am not yet aware of any confirmed fatalities stemming from people panicking and stopping using crypto because they listened to Efail and/or the EFF, but there is one particular community I'm watching for just that issue right now. By comparison to that I don't really care so much that Efail dropped the ball with disclosure to GnuPG or any of the other projects. It's a bit annoying, but we can all cope. I *do*, however, care that their recommendations may have lasting and potential final consequences for OpenPGP users living with and attempting to mitigate real threats to their lives and/or liberty. Playing with that sort of thing with the recklessness with which the Efail team have done is, in my not so humble opinion, an absolute disgrace. You pointed out that the vast majority of OpenPGP use is no longer email or other communications encryption. This is both true and a valid point of discussion. Nevertheless, there are still a considerable number of people who do use it that way and a number of them have to deal with threat assessments with considerably higher levels of personal risk than security researchers in academia or cryptographic developers. We must not forget these people. Ever. Even if we never hear from them. Their cases are also not a matter of being apathetic; it's that their priorities are surviving the world they're in, so they need to rely on the tools we provide (and I get the community apathy issue is actually a more general thing, so this isn' having a go at that part). The Efail researchers did forget them and their conduct demonstrates this. While they may have made some useful technical contributions regarding S/MIME and highlighting certain poor implementations in MUAs, that's no justification for reckless disregard of the lives of end users. So in my opinion it's not the merits or lack thereof in the demonstrated attacks they released that have the gravest consequence here, it's that the number one recommended mitigation technique is to remove cryptographic functions from MUAs. Even though they still said to basically perform those functions manually and independently, which does imply not opposing using cryptography itself. It's still a recommendation which is sure to create far more dangerous outcomes for end users. It's a bit like that scene in Erik the Viking where a woman is being raped and Erik kills the rapist, but his sword goes right through the rapist and kills the woman too. He did stop the rape, but that doesn't make his action a successful one. I think it's fair to say that most, if not all, of those of us working with this tech are reasonably intelligent. So surely we can operate at a level with a bit more forethought than a viking, fictional or otherwise. Regards, Ben signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
“Break backwards compatibility already: it’s time. Ignore the haters. I trust you.” +1 Efail caused me to run across the criticism that Moxie Marlinespike wrote about GnuPG/OpenPGP in early 2015. https://moxie.org/blog/gpg-and-me/ It felt to me that without naming it, he'd focused on the email use case to the exclusion of others, missing those other niches Robert Hansen mentioned in his "Efail Postmortem". Reading the Postmortem, I recalled another article about how being "mediocre" can actually be a good thing. https://www.ribbonfarm.com/2018/04/24/survival-of-the-mediocre-mediocre/ Poor things die for being ill-suited to purpose, cutting-edge things are often brittle and fail spectacularly when the problem varies too far from the design considerations. OpenPGP has maybe been so begrudgingly successful all this time because it's been /mediocre/ enough to remain flexible to adapt to changes in cryptography and best practices and discoveries about insecurities we weren't aware of in the past. I think Efail has shown now that OpenPGP/GnuPG retains the flexibility to continue to adapt and maintain a well used and trusted standard for private and authenticated data and communications, but it won't achieve this if its evolution is frozen. It seems to me that if the pearl-clutchers who would howl too loudly about breaking backwards compatibility were as concerned as they claim, they would realize that software evolves. But this evolution doesn't eradicate its past. GnuPG is open software. It's ganoo-pee-gee! If you're a pearl-clutcher with a legacy use-case, perhaps it's time to really analyze that case. Do you have a darn good reason to want to expose yourself to creeping insecurity? Because its history won't be eradicated, if you /do/ have good reasons, you can maintain for yourself a legacy fork. To do that you may need to have certain skills or be willing to hire-out for them. I think that's fair. It's free as in freedom, not beer, not support. For my vote, I think persons so situated might have suddenly imposed upon the larger community long enough, now that Efail has taught us something we may not have fully appreciated about the present state of OpenPGP and the way it's been pipelined with other tools. I cannot accept that "Pretty Good Privacy" is at risk, through apathy and underfunding and WG failures, of becoming "Passivity Guaranteed Peril". Robert signed off: Never forget that we’re on the same side, and the people on the other side include tyrants and murderers. Let’s stick together. Oh yes! From whatever corner you fear most a bogeyman might be lurking, one of the best ways to protect freedom and liberty is by ensuring that the general public always has a trustworthy cryptosystem at their disposal. Maybe it secures an oppressed group from a tyrant, maybe it authenticates a contract that existed after a dispute arises, maybe it's simply ensuring your new laptop isn't becoming co-opted to into making you an unwitting slave of cryptocoin pirates. These are all good reasons to register support. smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking changes
On 21.05.18 07:20, Robert J. Hansen wrote: > We should keep the 1.4 source code available, but wash our hands of it > and say it will receive *no* future fixes, not even for security > issues -- and we need to stand on that when people start screaming. I agree. In my experience, this stance--publicly documented--will allow people to say to their bosses "support has ended, and for security reasons we now need a budget to finance a move away from this outdated software". I have seen similar situations often enough; nobody would spend money as long as the old software horse was still twitching. Discontinue version 1.4 right away, quoting Efail as a trigger if you wish, and set an EOL for version 2.0 in a few months, as you suggested. > Let's get all the breaking pain over at once, and put GnuPG on track > for the future. People are going to be (temporarily) very annoyed anyway, so go all the way. Like Ferdinand von Schill said: "Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende." -Ralph ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Break backwards compatibility
Hi all, Am Montag, den 21.05.2018, 04:19 +0100 schrieb Mark Rousell: > On 21/05/2018 02:12, Jochen Schüttler wrote: > > I'm all for breaking backwards compatibility. > > > > What's the worst the haters can do? Turn their back on GnuPG? Shout > > out > > really loud once more? I think they should get a life! > > I rather suspect they do have a life supporting scenarios that they > cannot change that require legacy-decryption capability. > > If legacy-decryption was removed entirely from current versions of > GnuPG then they would simply have to continue using old, unsupported, > and potentially vulnerable versions. I do not think it is reasonable > to just cut them off entirely. I think it might be best to put that functionality into a separate GnuPG version called gpg-legacy. Make it clear in all man pages of this tool, the --version and --help options that this only exists to decrypt existing but now obsolete encrypted material and that it can't be used to create such material anymore. > As Philipp Klaus Krause [1] and Dirk Gottschalk [2] pointed out > above, breaking backward compatibility does not have to be (and > should not be in my opinion) absolute. The ability to decrypt old, > legacy-encrypted data is, like it or not, still present in the real > world and it is therefore surely proper for GnuPG to retain the > ability to decrypt such data in maintained code (albeit whilst > requiring users to take action to make changes to their configuration > to be able to continue decrypting such data using GnuPG). > > I agree with those who say that there is no need for mail clients to > be able to decrypt legacy-encrypted data. Dirk Gottschalk wrote in https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060474.html > I think the backwards compatiblity should be broken to improve > things. > It would be possible to implement something like --legacy to re- > enable > the old functionality. This could also be implemented in email > clients > and plug-ins like enigmail as a checkbox. No! Everybody will just turn on that checkbox then and be none the wiser. Regarding breaking changes: Please study carefully the Python2 -> Python3 transition. By keeping Python2 for 10 long years supported after deprecation, only the haters became louder and louder, "Success" stories of leaving the Python eco system exploded. Would they have integrated a non-GIL switch into that breaking change, the work for normal Python projects would not have been greater but the reason to switch would have been. Just 2 cents of a long-term GnuPG (and Python) user Michael -- Michael Kesper Supporter of FSFE https://fsfe.org/about GPG Fingerprint: F035 8BD9 D0C2 0E6A 85B5 6A60 4208 05C6 8907 4FAD 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
A postmortem on Efail
On 05/21/2018 04:07 AM, Mark Rousell wrote: > I think you mean that support for 2.0.y has been dropped, surely? No, I do mean that support for all PGP 2-related stuff has been dropped from the current stable branch. Modern GnuPG (≥ 2.1) can neither read nor write anything that has been generated by PGP 2.x. Compatibility starts with PGP 5, which dates back to 1997. > When I wrote "2.x.y" above I meant that users should be able > to continue decrypting legacy-encrypted data (albeit with a change of > commands/options compared to the present) with whatever the > currently-supported version of 2.something is at any point in the > future. Well, that's already not the case. If you have pre-1997 data, you need to use GnuPG 1.4, which again *is* still supported precisely for this use case. (You could also, in theory, use GnuPG 2.0.x, but *that* branch is explicitly no longer supported.) Damien signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Breaking changes
On 05/21/2018 06:20 AM, Robert J. Hansen wrote: > 2. End-of-life 2.0. That one at least is already done. The 2.0 branch reached EOL with the 2.0.31 release on December 29, 2017. I believe Werner stated clearly enough that there will be *no* further point release on that branch, not even for critical security fixes. If a distro is currently shipping a 2.0.x version, backporting any such security fix will be left to the packagers/maintainers for that distro. The last release of the 2.0.x branch is not even listed anymore on gnupg.org's download page. Damien signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
