From f702c7f5d4cd9ad43da1f747317f9bc004b2e989 Mon Sep 17 00:00:00 2001 From: Tim Otten Date: Wed, 16 Dec 2020 16:53:47 -0800 Subject: [PATCH] (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 --- Civi/Crypto/CryptoRegistry.php | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/Civi/Crypto/CryptoRegistry.php b/Civi/Crypto/CryptoRegistry.php index 7fc2150ad9..0cca04fe89 100644 --- 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']), -- 2.25.1