Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
Guys, especially in the wake of Efail, *please* stop sending HTML mail to the list. ___ 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 = 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: 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: 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 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: 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: 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
Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
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. I wonder just how much complexity there is in my FiOS box to convert the fiber-optic to plain old telephone service that must still be compatible with my old rotary dial telephone that requires 90 volt 20 cycle power to ring the bell. And all my electronic telephones with electronic ringers that must be protected from that 90 volt ringing current. Can you imagine the redesign that would be required so I could start the gasoline engine in my Prius with a hand crank in the front? -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key:166D840A 0C610C8B Registered Machine 1935521. /( )\ Shrewsbury, New Jerseyhttp://linuxcounter.net ^^-^^ 23:05:01 up 4 days, 6:55, 1 user, load average: 4.04, 4.05, 4.07 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
