[Bug 2627] Documentation update: semantic of ClientAliveCountMax 0 unclear

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2627

--- Comment #8 from Christopher Maynard <christopher.maynard at igt.com> ---
(In reply to Damien Miller from comment #7)
> If you were relying on an accidental, unreliable and undocumented
> behaviour for security then you always destined to have a bad time. 

The behavior was tested with the options we specified and it worked
exactly as desired.  You chose to make a change that broke that
behavior, seemingly without any regard to its implications, judging by
the lack of any discussions surrounding the change.  Yes, users are
going to have a bad time when developers behave in such ways.

> ClientAliveCountMax=0 *never* worked as a reliable inactivity
> timeout - ServerAliveInterval or a number of other things that
> caused non-session traffic could keep a connection alive
> indefinitely. A security control that appears to work but silently
> fails under common conditions is worse than useless.

You do realize that users control all their own options, don't you? 
And that users generally do test those options to ensure they work as
desired?  I would say a break in functionality that 100% ensures
failure is worse than useless, and borderline malicious.

> We've since added explicit, documented and supported inactivity
> timeout mechanisms (ChannelTimeout and UnusedConnectionTimeout), so
> the previous accidental behaviour of ClientAliveCountMax won't be
> coming back.

And when were those options added?  According to
https://www.openssh.com/releasenotes.html, they were added in OpenSSH
9.2.  So what about those of us using older versions such as OpenSSH
8.2 
 The fact that ClientAliveCountMax=0 behavior changed in OpenSSH 8.2
without regard to backward-compatibility and without those 2 new
options being added in conjunction with that behavioral change in order
to provide a mechanism by which the same behavior could be realized as
before just goes to show how poorly and sloppily the change was made
with barely a thought to its implication.  I sincerely hope that
considerably more thought is given to future changes that break
backward-compatibility than what has been demonstrated here.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.