Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!
Mouse <[email protected]> Mon, 4 May 2020 21:06:25 -0400 (EDT)
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <[email protected]> |
>> 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 [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B