Breaking changes

[Ben McGinnes]

On Tue, May 22, 2018 at 05:47:43AM -0400, Robert J. Hansen wrote:
> > Get real. These people are long-time GnuPG users and now you want to
> > throw them under the bus because... well, because you prefer it that
> > way.
> 
> 1.4 was deprecated the instant 2.0 was released.  After much pushback it
> was agreed to continue supporting 1.4.

To be fair, 2.0 wasn't so happy on all platforms ... which is why I
completely skipped it (save for one attempt to use 2.0 somewhere in
the middle and one subsequent attempt to use 2.0's gpg-agent with 1.4;
the former failed and the latter worked for a bit and then imploded)
and only migrated once 2.1 was a thing.

> But after fourteen years it's time to end it so that Werner's
> limited time can be fully devoted to the 2.3 branch.

Yes, well that's fair.

> > Err... the specialised solution surely is GnuPG 1.4.
> 
> Yes.  And the code will still be around.  It will just no longer be
> maintained.  If it's that important to you, you should consider
> maintaining it yourself or paying someone to maintain it.

Well, if the use case is solely accessing archived data (my use case
for keeping it to hand or the code handy) then it's less a matter of
maintaining the code base and more a case of, "as long as it compiles
from now until whenever and behaves as it did, then it can access the
data I need it for" and anything beyond that is just a bonus.

> Well... no.  It doesn't work that way.  Werner gets to work on what he
> wants to work on, and I think the best bang for the buck,
> community-wise, is 2.3.

Yep.

> But if Werner were to say tomorrow, "I'm done, guys, I'm going to go
> sell ice cream on the beach," I'd just say thank you, wish him well, and
> wonder where the beaches were in Germany.

Well it depends on which river, I guess.  No one said beaches had to
be by the seaside; that's just a conceit which has been largely
supported by English literature.

> > Isn't that effectively equivalent to commercial sponsors taking
> > previously open source code base private? It's hardly a popular move
> > when it happens.
> 
> Nope.  1.4 will still be out there, just unsupported.

Not to mention the little fact that all this code has been released
under the current dual licenses for a *very* long time and those
licenses aren't going to be broken now.

> No.  I'm well past the point where I care about how vocal a fringe
> minority is.  It's unwise to make engineering decisions based on the
> volume made by a small number of people.

Plus while some of us may even still have certain archives which do
require the possibility of using old keys, we also generally knew
about it for quite a while and thus were already aware that 1.4 was
the solution and maintenance was infrequent with no guarantees.  The
solution was to use it on that basis and/or migrate data and if the
latter isn't possible (e.g. for legal or historical preservation
reasons) then make sure you know what you're doing in house with the
code that is available.

From my POV, as someone who still has a working copy of his original
v2 key; even EOL'ing 1.4 would change nothing.  I can think of some
reasons why it might do bad things, but the flip side to that is the
1.4 code is a lot simpler (and self-contained), so anyone with a
really scary need to maintain it should hire g10code or their own
dedicated in house specialists (or both).

I expect national archives and libraries will also keep copies handy
for the performance of their legally mandated tasks in preserving the
historical record (and if a public archive of a mailing list includes
messages with signatures from v2 keys, that's the ball game from their
POV and the law is the law).  Still, those types of organisations are
used to employing specialists in accessing legacy formats and properly
archiving data, so I doubt they'll complain.

It's hard to care about anything beyond that, though and I'm sure it
will be a very long time before we see 1.4 not compiling on
something at all.  Maybe double-check after January, 2038 just in
case, but otherwise — meh.


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/85b34d1d/attachment.sig>