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
