[wp-trac] [WordPress Trac] #39309: Secure WordPress Against Infrastructure Attacks

[WordPress Trac]

#39309: Secure WordPress Against Infrastructure Attacks
------------------------------------------+-----------------------------
 Reporter:  paragoninitiativeenterprises  |       Owner:
     Type:  enhancement                   |      Status:  new
 Priority:  normal                        |   Milestone:  Future Release
Component:  Upgrade/Install               |     Version:  trunk
 Severity:  normal                        |  Resolution:
 Keywords:  has-patch                     |     Focuses:
------------------------------------------+-----------------------------

Comment (by dd32):

 Replying to [comment:14 paragoninitiativeenterprises]:
 > > I don't think shipping a PHP-based SHA512 implementation is worth
 anyones time here.
 >
 > Given that `hash()` is supposed to be in PHP 5.1.2 and newer, anyone
 using something as old as 5.2.4 should still have it:
 http://php.net/manual/en/function.hash.php

 Put bluntly, `--disable-all` is standard in many linux distro's
 (annoyingly) and disables this sort of stuff if you don't also install the
 extra packages (and not all sysadmins do), later versions of PHP disable
 the ability to separate some of the core extensions such as `ext/hash` and
 `ext/spl`.

 > > It should also be expected that core would have a minimum of 2 valid
 signing keys authorised, to allow for secure revocation and replacement.
 >
 > This is similar to Airship's requirements, where everyone has at least
 two keys: One master key, and one signing key. The master key can revoke
 or mint new (master, signing) keys. The signing keys are the ones actually
 used for package signing. (This is true for Paragon as it is for anyone
 who builds an Airship extension.)

 Makes sense, thanks for confirming that to be a good method.

 > > 39309.2.patch​ doesn't actually use the libsodium extension, correct?
 due to it's reliance upon ParagonIE_Sodium_Compat::*()
 >
 > It uses sodium_compat. If ext/libsodium is installed, sodium_compat will
 just kick off to the extension. If it's not installed, then sodium_compat
 uses the pure-PHP implemenation. This is a reasonable trade-off:

 Right, gotcha, it's not a polyfill as such, rather a pass-through library,
 that makes sense. I hadn't reviewed the code other than the public
 interface.

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