setEndDate cannot have a date after year 2038

[T3N4K4]

I am using phpseclib 1.0(.7) (since it is LTS and provides the lifetime certificates) and currently I am trying to validate some dates in certificates with the "validateDate()" function.

The problem is that I can only use an end date which is before year 2038 for my certificates because of the "year 2038 problem".

A "lifetime" end date has a minor problem, too.
The rfc string 99991231235959Z is working for me only with 99981231235959Z since the date class otherwise does not accept the new value. It seems that date only accepts years until 9999 and not above.

[terrafrost]

I guess you're using a 32-bit system. This doesn't appear to be an issue on a 64-bit system. Or, more specifically, a build of PHP where PHP_INT_SIZE is 8.

That said, phpseclib is supposed to work on 32-bit builds. I'll see if I can't get this working with DateTime or nesbot/carbon or some such.

[terrafrost]

Sorry for the delay.

Anyway, I made a branch off of the 2.0 branch that utilizes DateTime instead of unix time:

https://github.com/terrafrost/phpseclib/tree/datetime-2.0

Doing it for 1.0 is do'able but will be trickier. phpseclib 1.0 is, syntactically, PHP4 compatible. It uses PHP5 functions that can be emulated by existant shims but if you do php -l filename.php on anything in phpseclib 1.0 it should pass (save for Net/SFTP/Stream.php).

DateTime was only introduced in PHP 5.2 (phpseclib 2.0, due to it's use of namespaces, requires PHP 5.3). What I figure I'll do for that is have phpseclib 1.0 use both. It'll do DateTime if it exists and if not it'll use unix time, despite it's flaws.

edit: surprisingly, DateTime::createFromFormat is syntactically valid PHP even in PHP4. PHP4 doesn't support static methods but it does support the scope resolution operator. So where PHP5 tries to call createFromFormat statically PHP4 tries to call it like it would parent::funcName().

Per that I'm not actually sure it'd be possible to create an OOP DateTime shim for PHP4. Maybe a procedural DateTime shim could be created (eg. date_create_from_format vs DateTime::createFromFormat) but it's all wasted effort anyway lol. If you're using PHP4 on a 32-bit system you can either live with the "year 2038 problem" or upgrade. Or pay me money to attempt to write a shim lol.

[T3N4K4]

@terrafrost yes we are using a 32-bit system but the php version is 5.6.11-1. Is it therefore possible to

It'll do DateTime if it exists and if not it'll use unix time, despite it's flaws.

do this ^?

[terrafrost]

Sorry for the delay.

Anyway, this should be fixed in the 1.0, 2.0 and master branches now:

09c17b1