Bug 2977

Summary:

misc.c convtime() LONG_MAX is no longer allowed

Product:

Portable OpenSSH

Reporter:

Kirk Wolf <kirk>

Component:

sshd

Assignee:

Damien Miller <djm>

Status:

CLOSED FIXED

Severity:

minor

CC:

djm, dtucker, ywq119hy

Priority:

Version:

-current

Hardware:

All

OS:

All

Bug Depends on:

Bug Blocks:

2988

Attachments:

Description	Flags
unittest for LONG_MAX convtime conversions	dtucker: ok+

Description Kirk Wolf 2019-03-12 03:54:39 AEDT

Revisions 1.108 and 1.109 changed convtime() to fix an overflow issue, but it was also changed so that LONG_MAX is no longer a valid value.

1.109 seemed to explicitly "fix" this, but I do not believe that this is correct.

For example, there *should* be a unittest/conversion/test.c:

/* maximum value */
snprintf(buf, sizeof buf, "%lu", LONG_MAX);
ASSERT_LONG_EQ(convtime(buf), LONG_MAX);

-- this test currently fails.

PS>
We noticed this because we had some oddball user that was using 2147483647  (LONG_MAX) as ClientAliveInterval.  Even though this was not a useful setting, they now receive an error for this value.

Comment 1 Damien Miller 2019-06-07 14:51:07 AEST

Created attachment 3291 [details]
unittest for LONG_MAX convtime conversions

Comment 2 Damien Miller 2019-06-14 14:03:57 AEST

Committed - thanks

Comment 3 vicky_ye 2019-06-25 15:19:30 AEST

(In reply to Damien Miller from comment #1)
> Created attachment 3291 [details]
> unittest for LONG_MAX convtime conversions

The max value of some options (such as ClientAliveInterval, LoginGraceTime and so on) changed from 2147483647(max int:2^31 − 1) in perivious version(6.4) to 2147483646 now. 

Does this behaviors is work as design? 
Thanks a lot.

Comment 4 Damien Miller 2019-06-25 22:42:05 AEST

I don't think it matters - I can't imagine a SSH session lasting >68 years and needing that extra second to complete.

Comment 5 Damien Miller 2021-03-04 09:54:45 AEDT

close bugs that were resolved in OpenSSH 8.5 release cycle