AW: Breaking changes

[Fiedler Roman]

> Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von
>
> Lessee...
> https://en.wikipedia.org/wiki/GNU_Privacy_Guard
> already give an end-of-life date for 2.0, but none for 1.4.
> And since Ubuntu 16.04 includes 1.4, there are likely
> to still be a few vocal 1.4 users out there.
>
> How about announcing an end-of-life date for 1.4 that
> is in the future (say, by 3 to 6 months)?
> ...

In my opinion, just "announcing" EOL (especially with such a short notice) is quite bad practice for products aiming to be used in production setups also. This quite negatively affects trust into the product as your costs may change quite rapidly. You might argue, that companies should be used to paying for things. They are, but they want to have some planning when they are expected to pay. Would you like your car manufacturer announce, that your car is not secure any more in 6 month and that you have to pay for non-standard maintenance, if you still want to operate it securely?

Apart from that: some companies using open source software are non-profit companies, like mine in research business. If our software strategy is bad - e.g. because upstream forces us suddenly to switch/pay, where we did not expect it - research funding money (mostly from the society) has to be used to keep the projects running.

So when talking about EOL, gpg community should consider writing down a consistent EOL strategy, similar to those of Ubuntu, Linux kernel or others or something like I tried to argue for in the middle of https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060539.html


As another poster already argued on boosting migration by pushing stronger for elliptic curve cryptography: This is very likely to motivate end users to migrate. For businesses it might be not so much: ECC within gpg is not yet approved for all kind of applications (no in-depth audit reports available yet), so RSA use will still be common for quite a time. Apart from that: due to the missing EOL strategy (see above) and the growing gpg complexity (and risks), for example we are currently experimenting using ECC without GPG for automation purposes (using the underlying crypto libraries more directly).

Maybe production use of gnupg might not be a priority for gnupg in future. This might free resources otherwise needed for thinking about a sensible EOL-strategy or migration pathes. On the other hand, you might also lose feedback from audit reports/pen-testing/bug reports, which is sometimes only available from production (how many end user can reliable capture a crash every 10k hours of continued operation and distinguish it (with acceptable probabilities) from a hardware-related, hosting/virtualization infrastructure or silent kernel data corruption issue).