Breaking changes

Mark Rousell markr at signal100.com
Tue May 22 03:39:27 CEST 2018


On 21/05/2018 06:20, Robert J. Hansen wrote:
> Here's my own set of suggestions for breaking changes to GnuPG:
>
> 1.  End-of-life 1.4 already.
>
> Yes, it's the only option for PGP 2.6.  Yes, it's the only option for
> old and out-of-date stuff.  Yes, there will be people who need to
> decrypt this stuff.  All of that is true, but *we* don't need to be the
> people who cater to their needs.

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. No, that's not a fair, it's not reasonable, it's not ethical, or
it's even professional.

> At this point if you need pre-Web
> crypto (which, I remind people, is pretty much what PGP 2.6 is), you
> have a specialized need and you need to talk to someone about a custom
> solution.

Err... the specialised solution surely is GnuPG 1.4.

> There are companies that specialize in this sort of thing
> (like, say, g10 Code).

So you are saying that long-time users should be deprived of an open
source ongoing-maintained solution to their entirely valid present day
use case to benefit a private company.

Isn't that effectively equivalent to commercial sponsors taking
previously open source code base private? It's hardly a popular move
when it happens.

Yes, I know that the scenario you are proposing is not /exactly/ the
same but people will, quite understandably, treat it as such.

> We should keep the 1.4 source code available, but wash our hands of it
> and say it will receive *no* future fixes, not even for security issues
> -- and we need to stand on that when people start screaming.

Surely if you can recognise that people will start screaming then you
must also understand that it is entirely the wrong thing to do.

> Rationale: as long as we keep GnuPG 1.4 around and even semi-supported,
> people will insist on not upgrading.

If you drop maintenance of code that can handle the data that some
people need to cope with then they will naturally have to stay with old,
unmaintained code anyway. So dropping maintenance of 1.x will only cause
a problem in this respect, not cure on.

If you are (understandably) concerned about people still use 1.4 for
encryption of new data then the sensible choice is surely to do what
people have suggested in this thread: That is to produce a
decryption-only maintained version that still allows users who need to
access archived legacy-encrypted data to do so.

Clearly you are concerned with preventing people using legacy encryption
for new data and I agree with this concern. But there is no need to
throw present day, long-time users who must handle legacy-encrypted data
under the bus to do so.


-- 
Mark Rousell

PGP public key: http://www.signal100.com/markr/pgp
Key ID: C9C5C162
 
 
 

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


More information about the Gnupg-users mailing list