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. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: AW: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von > > On 22/05/18 10:44, Fiedler Roman wrote: > > Such a tool might then e.g. be used on a MitM message reencryption > > gateway: the old machines still send messages with old > > (deprecated/legacy options), they are transformed by "gpg-archive": > > The full data (old message, old decrypt report, reencrypted > > plaintext) go to the auditing storages, the reencrypted plaintext to > > the standard (before MitM) receiver (who does not need to support > > legacy/deprecated from now on anymore). > > I don't think we should be encouraging the automated or transparent use > of legacy crypto upgrades, particularly in an online setting such as a > mail gateway. All this does is launder the obviously-dangerous bad > ciphertext into an apparently-safe new ciphertext. Agreed, but I did not mean "e-mail" when writing "message". "Message" would more some encoded data block from a remote device, that has to be pushed to a central system from time to time, e.g. for auditing. Thus the gateway exactly knows the sender's key (usually it is only one for all systems with the same security level/in the same security zone) and re-encrypts it with a single key also known to the recipient. Usually the recipient has all the trusted keys hardcoded. For "e-mail" type messages, as you noted, a transparent re-encryption would be more risk than benefit in many cases. Still, it might be useful for semi-automated migration scenarios, e.g. * User clicks on a very old e-mail message * Gnupg fails decrypting it, referring to the migration tool and asking for confirmation * The migration tool migrates/replaces that single message if the user wants that. For e-mail, creating a mime-tree might come in handy, e.g. - plaintext message (reencrypted) - decryption/migration protocol (encrypted) - old message (full old mime structure, also encrypted but without decrypting it first - thus providing data at rest protection while still preserving all the old structures for traceability) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AW: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
On 22/05/18 10:44, Fiedler Roman wrote: > Such a tool might then e.g. be used on a MitM message reencryption > gateway: the old machines still send messages with old > (deprecated/legacy options), they are transformed by "gpg-archive": > The full data (old message, old decrypt report, reencrypted > plaintext) go to the auditing storages, the reencrypted plaintext to > the standard (before MitM) receiver (who does not need to support > legacy/deprecated from now on anymore). I don't think we should be encouraging the automated or transparent use of legacy crypto upgrades, particularly in an online setting such as a mail gateway. All this does is launder the obviously-dangerous bad ciphertext into an apparently-safe new ciphertext. -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
Hello list, I failed to decide, which message would be the best to reply to, so I took one with a title, rational humanists could be proud of. Ignoring the title, many of the messages had valid arguments for both sides. From my point of view the main difference seems to be, what is believed to be valid use cases and hence requirements for GnuPG. As I do not know of any requirements engineering documentation for GnuPG (also did not search for it yet), I just skimmed over the various use cases, that would be affected by fully dropping legacy support from GnuPG in the hardest way (both en/decrypt). Foreword: The arguments from below are ONLY from the mostly fully automated, non-mail, gnupg use-cases I currently have and their implications on backward compatibility. Those use cases might not be representative for automated use-cases or not worth to be considered in gnupg future. If they are not regarded important for gnupg , that would also be OK for me. It is all just about making the decision if gnupg will be the preferred encryption tool for the next 5-10yrs in our setups. To stick to logics, here are my assumptions for reasoning: * A:LegacyBad: Legacy support is more a security risk than a usability benefit, so it should be removed (or at least disabled) in the current version. * A:LateAdoptersPay: The burden on migrating legacy systems should be mostly on the side of those owning them - their lifecycle strategy decision was to minimize their costs, this should also have included a prediction, where software development/features/availability will move to. If done wrong, it is their fault. * A:MigrationPathes GnuPG on the other side has to provide simple and clear data/function migration pathes, so that long term users have trust in gnupg to be a solution for longer time. * A:NonStdBenefits: Non-standard use case support (e.g. non-mail) is a benefit for both parties: gnupg software gets also non-standard testing (thus security-relevant bugs might be discovered, that would not show up in standard use case) while other party can use software that is 80% fit to their purpose, so that system integration can be done much faster. * A:MachineTurnaround: Turn-around time of server software is about 5yrs, not all machines are migrated at once. So there will be a transition phase, where legacy and non-legacy systems will have to work together. * A:NoArchiveReencrypt: Full reading and reencryption of old tape archives (some that have to be stored/copied for 20yrs+) is not an option, both regarding efforts plus auditing support. * A:LateAdopterIsolate: As legacy software might not be able to tackle modern threats, that part of threat mitigation has to be dealt with by the operator, meaning: while gpg1.4 might have been suitable to decrypt in online (networked) setups back then, a backward compatibility setting might do that only in a state of the art 2018 64bit OS-release virtual machine with GnuPG running in an old i386, unprivileged, minimal, fully hardened LXC-container. * A:AttackSurface: While in desktop setups, more complex gnupg might not be the largest part of attack surface, the size of the gnupg-attack surface might be relevant in hardened, automated setups. If gnupg cannot be run in a simple, auditable, automatable minimal configuration, this will also affect trust in the future usability of gnupg. Considering all those assumptions, I would hope that following strategy would be somewhere in the direction of the optimal point for splitting costs between legacy operators and development (hopefully both for mail and automation): * Have 3 categories of features to ease long-term planning, both for dev and users (mail and automation): "recent": those just work "deprecated": not insecure, but something considered to be removed over the next 5-10 years. They can be enabled by "--deprecated" without any known, current security risks. "legacy": In an ideal world, they would not even be in the main code line. Having those levels would ease coordination of migration pathes between devs and users within timeline as required for [A:MachineTurnaround]. As soon as one of your tools requires "--deprecated", you should start prioritizing/handling that with your devops team. * While running a mixed setup [A:MachineTurnaround], [A:MigrationPathes] should be available, to reduce the amount of data produced with "deprecated" (or even "legacy" features) while obsolescence is already dawning. As the producing systems might not be changed without breaking warranty while [A:MachineTurnaround] is not over yet, but operators may already have increased costs according to [A:LateAdoptersPay], GnuPG tool support for migration of data in use therefore would be nice. This should be quite easy to use to tackle "deprected" features (also to motivate users to migrate in steps). For "legacy" the effort on integration might be much higher, which is OK. This could go even
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 Mon, May 21, 2018 at 9:04 PM, Mark Rousell wrote: > 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. > 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. > -- > Mark Rousell > > > ___ > 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: 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
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
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: 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
Break backwards compatibility already: it’s time. Ignore the haters. I trust you.
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! :) Cheers, Jeremy ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
