dev/core#2258 Port new Encryption Services to 5.33 #19392
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…aintext Example: You have a basic site that has not enabled encrypted fields, but the integration with settings/APIs causes one to use CryptoToken::decrypt()
… being used This moves the factory function from `Container.php` (which is loaded on all page-views on all configurations) to `CryptoRegistry.php` (which is only loaded if the site actually used encrypted fields).
…CRM_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
This is pre-merge change to the notation in the token. Two things: * Use only one control character instead of multiple. * Use URL-style key-value notation. It should be easier to skim and to tweak.
This allows the plaintext entries to do have different prioritizations among different keys.
There are multiple installers distributed across different git repos, and it make take a bit before they're all updated. The convoluted ternary expression ensures that CIVICRM_CRED_KEYS is well-formed regardless of whether the particular installer knows how to set %%credKeys%%.
This updates the the civicrm-setup API to generate CIVICRM_CRED_KEYS (%%credKeys%%) on t new installations (based on web-installer or cv installer).
|
(Standard links)
|
|
Jenkins re test this please |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This ports the following PRs to 5.33 #19236 #19251 #19349
Before
Crypto Service only in 5.34
After
Crypto Service in 5.33
I left out porting the change to the SMTP password because I figure that is better done in 5.34 but can be ported for the ESR releases as needed
ping @eileenmcnaughton @totten