Re: Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!

(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 <[email protected]>
To: [email protected]

>> 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.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML [email protected]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B