Breaking changes

[Ben McGinnes]

On Wed, May 23, 2018 at 01:22:41AM +0200, Leo Gaspard via Gnupg-users wrote:
> On 05/22/2018 11:48 PM, Dennis Clarke wrote:
> > On 05/22/2018 05:38 PM, Dan Kegel wrote:
> >> 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)?
> > 
> > Too fast. Think 12 months as a minimum. There is prod code
> > out there running for years and a timeline that allows proper
> > project schedule/costing/testing would be better.
> 
> If the announced end-of-life is 12 months, then people will complain for
> 9 months, and maybe start working on migrating during the last 3 months.

Depends on the size of the organisation really, but yes there would be
complaints if the code retained explicitly for accessing pre PGP 5
keys and data as well as running on certain types of headless systems
(e.g. routers) were to be terminated in a short period of time.

Which is why I doubt 1.4 will be EOL'd, but the existing policy of not
updating it without a massively hugely justified reason and the
ongoing and strong encouragement of migrating to 2.2.

Anyway, even if this wish to expunge 1.4 were to be realised, it still
would remain available in some form no matter what.  This is because
the GnuPG Project uses git and the 1.4 code, the 2.0 code, the 2.1
code and the 2.2 code is all in the same repo with different branches
and tags and so on.  Anyone even vaguely worried about losing 1.4
(don't worry, we're not revisionists) only needs to clone the whole
repo somewhere and git being git, that's the entire job done.

> I mean, I'm still seeing people actively developing python2 code
> bases without even thinking of migrating to python3 *now*, and
> retirement was initially announced for 2015…

Yeah, the Py2 EOL extension was a bit excessive.  Frankly it should've
just been pegged to when Twisted was migrated and then paying them to
do it faster.

At least with GPGME's Python stuff when faced with a 2 versus 3
decision it was pretty simple: we're going with 3, albeit with a
degree of support for 2.7 (i.e. it works in 2.7, but all the examples
and instructions are written for 3).

> The longer you leave people with maintenance, the longer they will want
> maintenance past the deadline.

Well, I can't argue with that after seeing what Sun's customers did.

> I think 3-6 months is more than enough, and if people can't manage to
> update their production code in this time frame they can live with an
> un-maintained GnuPG until they finish migrating (unless they want to pay
> for paid support for continued 1.4 maintenance, that is).

I think you might be overestimating your familiarity with all
industries which might be running it and any cases where hardware
limitations or certification requirements are a factor expecially if
that includes organisations which aren't, strictly speaking, standard
commercial or non-profit organisations.  Plus I would be rather
unsurprised to learn that there were live systems utilising 1.4 in
some way which really needed to remain running no matter what and if
it didn't then the people in the relevant region might legitimately
complain about losing power or water supply or whatever.

Do I know that sort of thing is going to be a guaranteed case?  No.
Still, as you say, 1.4 has been active for a long time and has no
doubt spread to all sorts of interesting use cases by now.  In this
case setting a short EOL to try to force change may not produce the
result you wanted.

> I don't have a personal opinion, but dropping 1.4 appears to have two
> advantages to me: first, it reduces the voluntary maintenance
> burden,

Given how little that active burden currently is, it may not save that
much and appears to be mostly backports of certain major issues which
were first fixed in a more recent release.

> and second, it may help gather funding for work on 2.3, if people choose
> to contract with g10code for continued maintenance.

That sounds rather deceptive; charging someone for maintenance of a
specific product and instead of spending that on the thing they're
paying for then spending it on a totally different thing that they're
willing to pay to avoid having to migrate to.

> GunPG 1.4 has been out for way longer than necessary, and people are
> never going to migrate out of it unless they are forced to.

There's a far easier way to ensure that migration without
disadvantaging legitimate archival needs and it will be largely pushed
by the other end users: that being when the shift to elliptic curve
keys becomes standard and possibly even if it becomes a default
configuration (though I expect to see more hybrid keys such as RSA
primary keys and either curve subkeys or a mix of curves and
asymmetric subkeys first).


Regards,
Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180523/47c7f971/attachment.sig>