(dev/core#2258) CryptoRegistry - Remove fallback option based on CIVICRM_SITE_KEY.

This was included under the expectation it might make a nicer upgrade. But
I don't think it buys a whole lot:

1. You run the upgrader. The SMTP password is converted from
   rj256-ecb-sitekey to aes-cbc-sitekey.  All other credentials are left
   unencrypted.  Afterward, you set CIVICRM_CRED_KEY and run the rekey.

2. You run upgrader. The SMTP password is decrypted. All other credentials
   are left unencrypted. Afterward, you set CIVICRM_CRED_KEY and run the rekey.

Additionally, I think there's a question of risk-management when we get to
encrypting more things in the Setting and API layers.  If we go with path 2,
then we can ramp-up adoption progressively, e.g.

* Release 1: Add support as non-default option
* Release 2: Enable by default on new builds
* Release 3: Display alert to existing sites that don't have encryption keys

diff --git a/Civi/Crypto/CryptoRegistry.php b/Civi/Crypto/CryptoRegistry.php
index 7fc2150ad9da2a4ecd53774aae7f3d7e3beb9f12..0cca04fe8912f14c341edfab2ca2fe33cf13b333 100644 (file)
--- a/Civi/Crypto/CryptoRegistry.php
+++ b/Civi/Crypto/CryptoRegistry.php
@@ -74,15 +74,7 @@ class CryptoRegistry {
         ]);
       }
     }
-    if (defined('CIVICRM_SITE_KEY')) {
-      // Recent upgrades may not have CIVICRM_CRED_KEYS. Transitional support - the CIVICRM_SITE_KEY is last-priority option for credentials.
-      $registry->addSymmetricKey([
-        'key' => hash_hkdf('sha256', CIVICRM_SITE_KEY),
-        'suite' => 'aes-cbc',
-        'tags' => ['CRED'],
-        'weight' => 30000,
-      ]);
-    }
+
     //if (isset($_COOKIE['CIVICRM_FORM_KEY'])) {
     //  $crypto->addSymmetricKey([
     //    'key' => base64_decode($_COOKIE['CIVICRM_FORM_KEY']),