(Removing [Curdle] from the subject because not posted there. Not sending to Mouse directly because his MX rejects Gmail.)
A brief comment on this. For now, it hope it's the last one.
If Mouse wants to carry the burden of telling people their implementations are broken, he is welcome to do so and I personally applaud him from the bench.
The more implementations that do so, the better. It would be especially great if MAJOR implementations did this.
I see two kinds of developers who are in a position to be purists, and to tell others to fix their brokenness. These are:
(a) Major implementations who can afford this due to their dominance.
(b) Minor implementations whose author does not give a f...
But the following type of developer cannot afford to be a purist:
(c) Minor implementations who need to answer support cases and depend on income from their users to feed their families.
As someone in category (c), I need to be compatible with ALL of the broken stuff. If some janky implementation has a problem, but it works with OpenSSH, then I have the problem, not the janky implementation, and not OpenSSH.
However, I highly encourage developers in categories (a) and (b) to be purists and reject brokenness, so that I, in category (c), need to implement fewer workarounds.
denis
-------- Original Message --------
Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!
Date: Mon, 4 May 2020 22:42:40 -0400 (EDT)
From: Mouse <mouse%Rodents-Montreal.ORG@localhost>
To: ietf-ssh%NetBSD.org@localhost
>> Anyone who can't/won't understand that there is a spec, and it isn't
>> "it interoperates with PuTTY and OpenSSH", deserves, IMO, to be
>> ignored.
> That's fine if you have no responsibility towards your clients/users.
> It doesn't work if you do, [...]
I disagree. Strongly.
I didn't say that anyone who files a bug report such as you sketch deserves to be ignored. It's only the ones who are unable or unwilling to understand that their "the new piece is the buggy one" (or, perhaps, "it works with $OTHER implementation, so it's not broken") stance might actually be wrong - and that there actually is an impartial right and wrong to it - _those_ are the ones who deserve to be ignored.
And that much only after education efforts have demonstrated exceptional resistance to acquisition of clue.
As for responsibility? As an ssh implementor, I hold myself to have a responsibility to all my users to call brokenness brokenness, rather than hiding it. (Yes, moussh has bug and misfeature workarounds implemented. None of them are turned on by default, and all of them are documented as workarounds.)
That responsibility is to the whole ssh ecosystem, actually.
Maybe that's part of why moussh is so unpopular. So be it; I do _not_ feel I have a responsibility to be popular at the cost of making the situation even worse.