Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.

[Mark Rousell]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180522/8a3086e1/attachment.html>