[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