IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



>> Peers that crash in response are broken and deserve to crash.
> That's not how it's reported though.  How it's reported is "Putty
> connects to our DAUSSH server without any problems, your client
> doesn't, fix your client".  Substitute "server" and "OpenSSH" if it's
> the other way round.

Sure.  But any such report deserves a response of "that's because your
[server|client] has a bug that [Putty|OpenSSH] doesn't tickle; fix your
[server|client] or switch to a non-broken one".  Or, depending on the
kind of customer relationship between supplier and user, "the bug's in
the other end, here's why/how, here are our rates for implementing bug
compatability".  That's why we _have_ specs for things like SSH, so
that there is an impartial authority to appeal to to answer the
question of which piece is broken when interoperation fails.  (Of
course, there is also the possibility that it's a detail the spec
doesn't cover.  That's not relevant to the kind of bug this thread has
been talking about.)

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.  Including, where applicable, being fired as a customer - I've
not seen customers fired often, but I've seen it.

Anything less (unless it's happening on only a small scale, I suppose)
leads to the sort of disaster SMTP has become - and, with things like
EXT_INFO, global-requests-ok, and that "database of client version
strings" someone mentioned upthread, I see SSH headed towards.

Not that I can't understand someone someone deciding to silently
implement a bug compatability mode.  I just believe that it's a greedy
and short-sighted choice, choosing short-term gain at the cost of
long-term ecosystem-wide technical debt.  (Of course, that's what I
would expect from the commercial world.  I would hope there are enough
noncommercial SSH implementations, at least a few of which have
significant clout in the ecosystem, to keep the short-sighted ones
marginal, though this discussion leads me to fear that hope may already
be in vain.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B



Home | Main Index | Thread Index | Old Index