|
I appreciate the acknowledgment. I will plan accordingly. Thank you!
My attitude does stink. I’m afraid this comes from frustration with your
work over the past 17 years.
This will seem unfair to you because you value your work on the basis of
what good it does.
Your work does a lot of good. It is a security-conscious project, with a
quality of implementation that exceeds at least half of commercial
implementations. It makes a difference in day to day lives for millions of
users. It improves the overall security of the internet. Its open source nature
is a valuable counterweight that helps keep in reign IP encroachment by
commercial implementations.
I could be cynical, and say that “one gets what one pays for”. This would
be partly true, in ways you might not be aware of. But it would also be
fundamentally unfair, because the value of your work is much more than anyone
pays.
I don’t know about your circumstance. I don’t know if you are adequately
compensated for the work you do by some benevolent benefactor. It is possible
that you are not, and if you’re not, I consider this a significant unfairness.
If this is the case, it’s an unfairness you have chosen, but it’s unfair
nevertheless.
All of this being said – although I can praise your project in all these
respects, and I can consider it better than a number of commercial
implementations;
and although the very fact that I can have this conversation with you is
meaningful, and valuable; it is more than is possible in many cases, and I do
not take it for granted;
all of these things being said...
I am another implementor who is not part of your project; and therefore
does not have influence.
So when you do things in your project that are short-sighted; or are poorly
planned; or do not consider the impact on others; in such cases, I am
impacted.
And because I do not have control; my reaction is not “OK, so this looks
like a mistake. Everyone makes mistakes. These guys are doing valuable work for
free. The world should be thankful for their efforts.” My reaction instead is:
“OMG, these open source developers again, and what passes their threshold for
quality work.”
This is partly unfair, because as I’ve said, your work is actually better
than 50% of commercial implementations. That is without counting those
implementations that are actually ripping off from your work. :)
But I hold you to a higher standard, and that’s not despite your work being
free, but because it is free, and therefore popular. I feel that with
the market position you have, comes great responsibility.
And the reason I’m peeved is because I feel that the problem is not
accidental, but systemic. If you participate in an open source project as long
as you do, you’re not just giving the world a freebie. You are writing the code
for a principle. If your aim is to serve a principle; and your software becomes
overwhelmingly popular because people see and recognize your commitment; then
you are also taking on responsibility.
And when you do that, I am then peeved if you simultaneously abrogate this
responsibility, by developing, planning, and designing sloppily.
If you’re going to uphold a principle, then uphold a great principle,
dammit. Do excellent work. Don’t be satisfied with adequate. :)
Again, I have no idea how this is experienced on your end. And yes – your
code is still better than many.
And it’s better, and more responsible, and your development process is more
responsive, than commercial companies have been in similar leading market
positions.
denis
From: Damien Miller
Sent: Tuesday, June 13, 2017 05:11
Subject: Re: OpenSSH bug in decoding EXT_INFO extension
values Yes,
this is a bug in OpenSSH. Yes, we'll fix it for 7.6. Yes, your attitude and approach stinks. On Mon, 12 Jun 2017, denis bider (Bitvise) wrote: > Bad news, everyone. > > Again - there’s a bug in OpenSSH that’s now widely deployed, and will require > workarounds to coexist with. > > OpenSSH implements EXT_INFO. Excellent. Very nice. I'm grateful. Thank you. > > But it does so incorrectly. > > Suppose that a server sends the "delay-compression" extension to an OpenSSH > client. > > The client disconnects, without attempting to authenticate, as soon as it sees > the extension's encoding. > > It disconnects due to this choice of function in kex_input_ext_info: > > > if ((r = sshpkt_get_cstring(ssh, &val, NULL)) != 0) { > free(name); > return r; > } > > > This is an incorrect function to use for the extension value, because it > contains the following logic: > > > /* Allow a \0 only at the end of the string */ > if (len > 0 && > (z = memchr(p , '\0', len)) != NULL && z < p + len - 1) { > SSHBUF_DBG(("SSH_ERR_INVALID_FORMAT")); > return SSH_ERR_INVALID_FORMAT; > } > > > THIS IS NOT CORRECT LOGIC TO USE WHEN PROCESSING AN UNKNOWN EXTENSION VALUE, > OF UNKNOWN FORMAT, WHERE THERE'S NO GUARANTEE IT WON'T CONTAIN ZEROS! > > The value for the “delay-compression” extension, in particular, contains > zeros. > > The whole extension is defined as follows: > > > string "delay-compression" > string: > name-list compression_algorithms_client_to_server > name-list compression_algorithms_server_to_client > > > Obviously, the lengths of both name-lists will have zeros, which will appear > right at the start of the value. > > So we implement an extension mechanism - and once again, it cannot be used > with OpenSSH, because it deploys a fundamentally botched implementation. > > Remember - the reason this "delay-compression" extension exists IN THE FIRST > PLACE is that OpenSSH botched its delayed compression; designing it with a > built-in, unescapable race condition. > > God dammit, guys. God dammit. > > What should I do with this? > > Not send "delay-compression" to OpenSSH versions up to 7.5? > > Or not send it to ANY OpenSSH version? > > denis > > > |