[wp-trac] [WordPress Trac] #47186: At least one function in /wp-includes/sodium_compat/src/Core32 times out on 32 bit servers

WordPress Trac noreply at wordpress.org
Thu May 9 18:23:02 UTC 2019


#47186: At least one function in /wp-includes/sodium_compat/src/Core32 times out on
32 bit servers
-------------------------------+-------------------------------------------
 Reporter:  lovingboth         |       Owner:  paragoninitiativeenterprises
     Type:  defect (bug)       |      Status:  reviewing
 Priority:  normal             |   Milestone:  5.2.1
Component:  Upgrade/Install    |     Version:  5.2
 Severity:  normal             |  Resolution:
 Keywords:  needs-testing      |     Focuses:
  has-patch                    |
-------------------------------+-------------------------------------------

Comment (by lovingboth):

 Apologies if this sounds somewhat pointed, but the number of hours I have
 had to spend over this in the last couple of days is not small.

 Replying to [comment:8 paragoninitiativeenterprises]:
 > This is a problem with 32-bit platforms. See:
 https://github.com/paragonie/sodium_compat#help-sodium_compat-is-slow-how-
 can-i-make-it-fast

 Ah, so it's a known problem with the library that was added to WordPress
 core without, as far as I can see, ever seeing how many WP users are
 running on 32-bit systems.

 > The `ParagonIE_Sodium_Compat::polyfill_is_fast()` method was created to
 detect when performance might be a problem. The typical workaround most
 people employed was: `pecl install sodium`.
 >
 > However, that's not a universal solution. Some people cannot install
 PECL extensions. So a lot of the changes between v1.6.0 and v1.9.1 (the
 latest) have been attempts to optimize the 32-bit implementation of these
 functions.

 Or you could use a faster, albeit theoretically slightly less secure,
 algorithm in the first place. Was using SHA512 hashes tested? That's
 native in PHP for all versions WordPress supports.

 > @lovingboth
 >
 > > I don't necessarily think it's relevant, but as the source of
 verify_file_signature in wp-admin/includes/files.php mentions that it
 doesn't work with PHP 7.2.0 to 7.2.2 if opcache is enabled...
 >
 > The verification is disabled on those versions because it generates
 incorrect results, not for performance reasons.

 Ah, thanks.

 > The fix here, if there is one, will land in sodium_compat. It's not a
 bug in WordPress. We do have a few optimization ideas that we haven't
 tried yet (which are nontrivial to implement).

 The bug would be including a library in core that was known - see
 https://core.trac.wordpress.org/ticket/45806, "If PHP_INT_SIZE === 4 its
 public-key cryptography implementations are much slower than PHP_INT_SIZE
 === 8, but there's no safe way to get around this limitation" - not to
 work effectively on an unknown number of systems.

 Fan as I am of verifying stuff, if **https**://api.wordpress.org is
 compromised, it's a) not unlikely that the signing key is too and b) there
 are worse security problems for WordPress than not having a signature on
 files downloaded from it.

 (See, for example, the way that in 2019 I think you can **still** make
 infinite failed attempts to login without core doing anything about it -
 even notifying the owner - and continue to have that bruteforce attempt
 amplified by the 'feature' of xmlrpc that allows hundreds of simultaneous
 attempts in a single call, something for which there are literally zero
 valid use cases.)

 > A short-term workaround would be to, if
 `ParagonIE_Sodium_Compat::polyfill_is_fast()` returns false and
 `ini_get('max_execution_time')` is greater than 1 but less than some
 reasonable value (30 is too small... maybe 40?), don't check signatures.

 30 seconds is, of course, the default for PHP installations and a large
 chunk of WP users will have no way to change that.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47186#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list