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
