On Tue, Jul 06, 2021 at 10:18:44PM +0200, to...@tuxteam.de wrote:
On Tue, Jul 06, 2021 at 02:11:21PM -0400, Michael Stone wrote:
[...]
It's entirely too common for obsolete encryption options that are
kept for "compatibility" end up being a vector for compromise, and
entirely reasonable to remove such options in order to provide the
most secure and maintainable tool for the vast majority of users.
That's the attitude of authoritarian software: "my software is smarter
than you".
The authors are free to hold that position, but so am I to utterly
dislike it.
This is ridiculous. If you want something that the maintainers think is
unsafe to put in the mainstream distribution you're perfectly free to add
(and maintain it) yourself. That's what free software is all about. I
personally utterly dislike when people demand that other people provide
them with things. But hey, it's a free world--dislike whatever you want.
The only authoritarian thing here is people trying to tell other people
what they need to put in the software they maintain.
If you want ancient crypto options, just run an ancient binary.
They're very easy to find in archive.debian.org.
They're not as easy to run as soon as they start being outrun by
their dependencie's versions, and you perfectly know that.
So you want to run obsolete proprietary hardware with no upgrade path,
and also complain that the free software is too hard and/or that the
ability to make the free software do exactly what you want isn't "easy"
enough for you. Seems legit.
Just to be sure that I wasn't dreaming that this wasn't actually a big
deal, I just grabbed the openssh-client deb for etch from the archive,
along with the library dependencies that couldn't be installed from
bullseye (libssl, libkrb5) and it worked fine. If I copy the binary to
ssh-oldasdirt and reinstall the current openssh, I can use either the
current ssh or ssh-oldasdirt with no issues. If you want it easier than
that I'm sure you can hire someone to make a custom repository or even
rebuild the old package with a non-conflicting name like ssh-oldasdirt
or whatever.
Of course, the real answer is to not purchase products with "secure"
management that can't be upgraded when it becomes "insecure"
management.
See above. To me, this is a dangerous antipattern.
To me, leaving obsolete crypto in a security tool is an antipattern.
Experience has shown again and again that this results in security bugs,
sometimes really significant ones. Maintainers of such tools need to be
responsible in what they release, even if there's a vocal minority that
complains about it. The openssh team does a pretty good job of
publishing a deprecation schedule *and* sticking to it.
