You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/* Check that the conversion was sound. SFTP v3 becomes unsound in 2038CE.
* If you're looking at this code then, I suggest using a later protocol
* version. If that's not acceptable, and you either don't care about
* bogus timestamps or have some other workaround, then delete the
* checks. */
if(m!=attrs->mtime.seconds)
sftp_fatal("sending out-of-range mtime");
if(a!=attrs->atime.seconds)
sftp_fatal("sending out-of-range mtime");
The comment here is a bit misleading when it says that V3 will become unsound in 2038, since V3 also can't represent timestamps before 1970 and indeed the condition here triggers in this case. It's easy to imagine legitimate uses for such old timestamps, and of course that's why V5 switched to signed values.
Also I've come across a few files from the far future, usually resulting from unpacking a corrupted archive.
At any rate, using sftp_fatal here is a little unfortunate. First, despite the name and its documentation, it doesn't actually terminate the process so the connection just hangs. But even if it did close the connection, this would be a pretty harsh treatment when all the client wanted to do was learn the attributes of a file. Would it be better to simply omit the timestamps from the output in this case? A white lie, so to speak?
The text was updated successfully, but these errors were encountered:
Agreed that the behaviour is harsh, and should substitute some other value.
However I'm confused by the statement that sftp_fatal does not terminate the process. It calls either exit or _exit both of which end the process, and when I tested with a far-future timestamp the process did terminate.
sftpserver/v3.c
Lines 115 to 123 in 62913a9
The comment here is a bit misleading when it says that V3 will become unsound in 2038, since V3 also can't represent timestamps before 1970 and indeed the condition here triggers in this case. It's easy to imagine legitimate uses for such old timestamps, and of course that's why V5 switched to signed values.
Also I've come across a few files from the far future, usually resulting from unpacking a corrupted archive.
At any rate, using
sftp_fatal
here is a little unfortunate. First, despite the name and its documentation, it doesn't actually terminate the process so the connection just hangs. But even if it did close the connection, this would be a pretty harsh treatment when all the client wanted to do was learn the attributes of a file. Would it be better to simply omit the timestamps from the output in this case? A white lie, so to speak?The text was updated successfully, but these errors were encountered: