@terrafrost Thanks for merging this. Any chance of a new 1.0 release? There hasn't been one for 6 months.

It's actually been over a year since the last 1.0 release lol. Anyway, I just released 1.0.20. I don't release 1.0 as often as 2.0 / 3.0 anymore just cause it's more of a PITA to release it. And some of the changes in the 2.0 / 3.0 releases have been semi experimental. Like when I bumped the SFTP packet size from 4KB to 32KB in an attempt to speed it up... I didn't know if that'd cause issues and I didn't want to be slowed down by trying to do 1.0 releases as often.

That said, it might not be a bad idea to consider updating the Wordpress plugin to use phpseclib 3.0. phpseclib 3.0 offers EC support, among other things, that 1.0 will never have. I have a shim for 3.0 to 2.0 here:

https://phpseclib.com/docs/why#phpseclib2_compat

2.0 and 1.0 are pretty much the same API but 2.0 is namespace'd whereas 1.0 isn't.

I discuss how to make it so phpseclib 3.0 can be installed without Composer here;

https://phpseclib.com/docs/install#without-composer

You can download a self contained zip file of phpseclib 3.0.12 (without using Composer) here:

https://github.com/phpseclib/phpseclib/releases/download/3.0.12/phpseclib3.0.12.zip

phpseclib 3.0 requires PHP 5.6 whereas phpseclib 1.0 in theory works on PHP 4.4+

This change caused a massive slowdown in my production systems on signing requests. In our php build, the phpinfo function does not exist. This caused \phpseclib\Math\BigInteger::__construct to not set define('MATH_BIGINTEGER_OPENSSL_ENABLED', true); starting from v2.0.36 adding 12+ seconds per signing request.

Not sure if this was intended. It can be circumvented by:

define('MATH_BIGINTEGER_OPENSSL_ENABLED', true);

before signing.

@wisskid Looking at the code, it was setting that constant via a work-around intended for PHP 5.2. But on the other hand, it would not just have been slow, but crashed, on PHP 8.0 (since unknown functions are a fatal error for 8.0+).
Setting the constant explicitly is the right thing to do, because there's no other method to detect the result reliably, though @terrafrost might have an opinion on whether accidentally changing the unexpected default for PHP 5.3 - 7.4 in the absence of phpinfo() is something desirable to reverse or not.

In reviewing the code phpseclib 2.0 and 1.0 deal with phpinfo somewhat differently. 2.0, prior to 2.0.36, tried to check if phpinfo existed by doing strpos(ini_get('disable_functions'), 'phpinfo') === false. If phpinfo couldn't be called and the OpenSSL extension was available then it would assume that OpenSSL could be used without issue - that the header and library version matched.

phpseclib 1.0 didn't do a strpos(ini_get('disable_functions'), 'phpinfo') === false check. So this PR added a check but the check that this PR added didn't behave like 2.0's check did and so 2.0's behavior was changed when 1.0 (with this PR merged into it) was merged into 2.0.

This should be working better now with the latest commit. I made how 1.0 works more consistent with how 2.0 works as well:

c22bf62

Thanks!

@terrafrost thanx!