Repost from WordPresss.org
Protection Against Supply-Chain Attacks from WP 5.2
Starting with WordPress 5.2, your website will remain secure even if the wordpress.org servers get hacked.
WordPress servers now cryptographically signing WordPress updates with a key that is held offline, and your website will verify these signatures before applying updates.
Signature Verification in WordPress 5.2
When your WordPress site installs an automatic update, from version 5.2 onwards it will first check for the existence of an
x-content-signature header. If one isn’t provided by original WordPress ORG update server, your WordPress site will instead query for a
filenamehere.sig file and parse it.
The signatures were calculated using Ed25519 of the SHA384 hash of the file’s contents. The signature is then base64-encoded for safe transport, no matter how it’s delivered.
The signing keys used to release updates are managed by the WordPress.org core development team. The verification key for the initial release of WordPress 5.2 is
fRPyrxb/MvVLbdsYi+OOEv4xc+Eqpsj+kkAS6gNOkI0= (expires April 1, 2021).
(For the sake of specificity: Signing key here means Ed25519 secret key, while verification key means Ed25519 public key.)
To verify an update file, your WordPress site will calculate the SHA384 hash of the update file and then verify the Ed25519 signature of this hash. If you’re running PHP 7.1 or older and have not installed the Sodium extension, the signature verification code is provided by sodium compat.
WordPress original signature verification is implemented in the new
verify_file_signature() function, inside
Modern Cryptography for WordPress Plugins
The inclusion of sodium_compat on WordPress 5.2 means that plugin developers can start to migrate their custom cryptography code away from mcrypt (which was deprecated in PHP 7.1, and removed in PHP 7.2) and towards libsodium.
How to Seamlessly and Securely Upgrade your Plugins to Use the New Cryptography APIs
If your plugin uses encryption provided by the abandoned mcrypt extension, there are two strategies for securely migrating your code to use libsodium.
Strategy 1: All Data Decryptable at Run-Time
If you can encrypt/decrypt arbitrary records, the most straightforward thing to do is to use
mcrypt_decrypt() to obtain the plaintext, then re-encrypt your code using libsodium in one sitting.
Then remove the runtime code for handling mcrypt-encrypted messages.
Strategy 2: Only Some Data Decryptable at Run-Time
If you can’t decrypt all records at once, the best thing to do is to immediately re-encrypt everything using
sodium_crypto_secretbox() and then, at a later time, apply the mcrypt-flavored decryption routine (if it’s still encrypted).
Avoid Opportunistic Upgrades
A common mistake some developers make is to try to do an “opportunistic” upgrade: Only perform the decrypt-then-re-encrypt routine on an as-needed basis. This is a disaster waiting to happen, and there is a lot of historical precedence to this.
Of particular note, Yahoo made this mistake, and as a result, had lots of MD5 password hashing lying around their database when they were breached, even though their active users had long since upgraded to bcrypt.
Detailed technical information about this new security feature, written by Paragon Initiative Enterprises (the cryptography team that developed it) are available here.