Timestamp overflow problem

[rlnsh]

The jsch library will get the modified time of the file will have a timestamp overflow problem, such as after January 19, 2038, will have a negative timestamp time rollback problem. Hope the author can fix the problem next time, tTime field is currently an int and needs to be adjusted to a long type.

[norrisjeremy]

Hi @rlnsh,

Can you please provide more specifics as to what sort of defect you believe is present in JSch?
Your problem report is extremely vague, and I'm not very certain how you would expect us to act upon it.

Thanks,
Jeremy

[rlnsh]

Hi @rlnsh,

Can you please provide more specifics as to what sort of defect you believe is present in JSch? Your problem report is extremely vague, and I'm not very certain how you would expect us to act upon it.

Thanks, Jeremy

In the SftpATTRS class, the mtime and atime fields are int type, and the maximum value is 2147483647. If the server time is changed to January 20, 2038, the obtained mtime and atime are negative values, and the time rollback occurs.

[norrisjeremy]

Hi @rlnsh,

You are aware that this fields are specified in the SFTP standard to which JSch adheres as uint32, and thus this isn't a JSch defect, but rather a defect in the SFTP protocol itself?
You may want to review the SFTP standard?

Thanks,
Jeremy

[rlnsh]

ok, i see, Thanks!

[rlnsh]

The uint32 in the c language in sftp has an unsigned bit and its maximum value is 4294967295. Therefore, java receives packets of the long type.

[norrisjeremy]

The uint32 in the c language in sftp has an unsigned bit and its maximum value is 4294967295. Therefore, java receives packets of the long type.

I'm not sure what point you are attempting to make?
JSch parses this field as 4-byte unsigned integer, per the SFTP standard.

[rlnsh]

If the file date is January 20, 2038, but the mtime obtained by SftpATTRS is incorrect, the timestamp returns a negative number.

[norrisjeremy]

If the file date is January 20, 2038, but the mtime obtained by SftpATTRS is incorrect, the timestamp returns a negative number.

It's the caller's responsibility to correctly interpret the int return value of the SftpATTRS.getMTime() method as being an unsigned integer.
I.e., the caller of the SftpATTRS.getMTime() method should use Integer.toUnsignedLong(), as can be seen in the SftpATTRS.getMtimeString() method.

[jogerj]

Since JSch uses a pure java SSH implementation, there's no reason why this can't be done. Even the original README cites a TODO to support SFTP v4. To my knowledge there has not been any mention of supporting SFTP v4 or later since the fork.

jsch/README

Lines 185 to 189 in e7c4d5c

	TODO
	====
	* re-implementation with java.nio.
	* replacing cipher, hash by JCE with pure Java code.
	* SSH File Transfer Protocol version 4.

However, given that most SSH servers use OpenSSH, which only supports SFTP up to v3 and whose developers have no intention to move on to later versions in the near future, implementing support for SFTP v4 in JSch would not solve your issue unless your SSH servers supports it (e.g. ProFTPD)

If you absolutely need SFTPv4 or above, you might want to look into Apache Mina. imo JSch will continue to cater more to developers maintaining legacy code

[norrisjeremy]

I personally have no plans to implement SFTPv4, since it isn't supported by OpenSSH.
If you have a strong desire for it, you are welcome to submit a PR to implement it.
However I would caution any contributors that we would want to take extreme care in how it was implemented & integrated in order to avoid introducing any regressions to the existing code: JSch is an old and fragile code base, so we tend to be conservative in how we implement and integrate features.