On 31/12/17 16:44, Peter Moody wrote:> On Sat, Dec 30, 2017 at 9:47 PM, David Newall<openssh at davidnewall.com> wrote: >> Of course it's the client's fault. The client worked, was changed, and thus >> stopped working. > don't upgrade your client. problem solved. you're at fault for not > pinning your dependencies when you have hard dependencies.Really?? A fractured user-base: that's what you want?? And you want to blame the victims?? People who don't discover that newer versions of openssh don't work for equipment which they rarely need to access are at fault for believing that what was promised would never be taken away?? Just leave them a little time bomb. Nice.? Very nice.
I would prefer that: * commercial vendors patched the software they sold * people who purchased from these vendors to take responsibility for their actions and apply pressure on the commercial vendors rather than the free software developers who provide the client software, for free. and I'm not sure what your bugaboo is about a fractured user base; at any given time there are probably hundreds of different versions of openssh being distributed due to different os's, distros, etc. by the way, do you not see that every one of your arguments about the openssh client can be applied, almost verbatim, to the vendor supplied sshd? with the obvious exception that one is supplied by a commercial vendor. bye On Sun, Dec 31, 2017 at 8:04 PM, David Newall <openssh at davidnewall.com> wrote:> On 31/12/17 16:44, Peter Moody wrote: > > On Sat, Dec 30, 2017 at 9:47 PM, David Newall <openssh at davidnewall.com> > wrote: > > Of course it's the client's fault. The client worked, was changed, and thus > stopped working. > > don't upgrade your client. problem solved. you're at fault for not > pinning your dependencies when you have hard dependencies. > > Really? A fractured user-base: that's what you want? And you want to blame > the victims? People who don't discover that newer versions of openssh don't > work for equipment which they rarely need to access are at fault for > believing that what was promised would never be taken away? Just leave them > a little time bomb. Nice. Very nice.
Hi, On Mon, Jan 01, 2018 at 07:52:26AM -0800, Peter Moody wrote:> I would prefer that: > > * commercial vendors patched the software they sold > * people who purchased from these vendors to take responsibility for > their actions and apply pressure on the commercial vendors rather than > the free software developers who provide the client software, for > free.You *are* aware what people are talking about? Like, management cards for UPSes and such, where the important part is "will that UPS provide reliable power for a reasonable price", a secondary question is "can I monitor that thing in a reasonable way?", and a very very very minor influencing factor is "will the management card do SNMPv3, or SSH with o 2048 bit RSA key size"? Your extreme point of view is just unrealistic for such devices and vendors.> and I'm not sure what your bugaboo is about a fractured user base; at > any given time there are probably hundreds of different versions of > openssh being distributed due to different os's, distros, etc. > > by the way, do you not see that every one of your arguments about the > openssh client can be applied, almost verbatim, to the vendor supplied > sshd? with the obvious exception that one is supplied by a commercial > vendor.Like, "making updates, and all of a sudden, working setups stop working"? I *have* seen this, and usually because the vendor imported a newer version of OpenSSH, which broke existing functionality :-) (like, Fortigate, which all of a sudden did not authenticate users with DSA keys anymore, and no mentioning of it in the release notes...). gert -- now what should I write here... Gert Doering - Munich, Germany gert at greenie.muc.de
On 02/01/18 02:22, Peter Moody wrote:> I would prefer that: > > * commercial vendors patched the software they soldWe all would prefer that, but I think you know that in reality, very few customers have enough leverage to achieve that.? I have a number of IBM servers for which access to the remote console now requires old versions of Java and old browsers.? That's IBM.? If they're not going to update equipment, nobody is.? Let's not pretend the world works differently.> I'm not sure what your bugaboo is about a fractured user base; at > any given time there are probably hundreds of different versions of > openssh being distributed due to different os's, distros, etc.Every older version of openssh is on the path to the latest version, unless there's a reason why the latest version cannot be used.? When you create such a reason, you force them to choose between a real bug or find an alternative.? A lot of people choose to live with a real bug, and that truly does reduce security. But the worst thing about fracturing the user base, from the perspective of wanting to be the premiere implementation of ssh, is you create a real incentive for a fork.? As things stand, a fork would be superior software, because it will have 100% of the goodness of openssh without the badness.? The main distributions will eventually switch and then openssh will become irrelevant. Why go through that over some pig-headed and wrong principle?? (I realise that there are developers here who think that it's not pig-headed to aim for perfect security, but, when you make perfect be the enemy of good, you are being pig-headed.)? What is proposed has a strong argument in its favour, and really has no downside, unless you believe in fairy godmothers who can wave a wand and make manufacturers do things which they clearly are not going to.> by the way, do you not see that every one of your arguments about the > openssh client can be applied, almost verbatim, to the vendor supplied > sshd?I realise.? I also realise that the reason why open source software is so powerful a force in IT is because manufacturers want to their gear to become obsolete, they want it to exist in their own silos, they want to destroy the opposition.? If I said "embrace, extend, extinguish", everybody here would nod their head.? Our job is to provide a better alternative.? This recent change, which removed shorter keys, could have been done slightly differently and we would continue to be a better alternative. Now, sadly, people have to dig into yesteryear and find a better alternative.? That not only sucks, it creates space for a good alternative that will displace openssh. I think a very good question which needs to be asked is, what value does disallowing shorter keys bring over severely deprecating them (i.e. allowing them by use of command argument on a per-session basis)?? I cannot see a single benefit; it won't stop use of shorter keys, it will just stop use of the latest openssh.