refactor(encryption): Migrate appconfig keys to typed bool IAppConfig with repair step#60002
refactor(encryption): Migrate appconfig keys to typed bool IAppConfig with repair step#60002cuppett wants to merge 10 commits intonextcloud:masterfrom
Conversation
cuppett
left a comment
There was a problem hiding this comment.
I don't know the convention when trying to refactor the legacy values out. Happy to simplify to only the minimal set or wait until next version for another PR. Just LMK.
864ad6a to
f3679b4
Compare
f3679b4 to
39b6d31
Compare
a6fff8f to
e4f6ece
Compare
e5291af to
07461ee
Compare
|
The psalm things (DAV) seem to be coming from the master branch (not related to this PR). Do I need to fix that or can it be overridden to merge? |
artonge
left a comment
There was a problem hiding this comment.
Looks good, thanks for splitting :)
The psalm error is indeed unrelated.
6e52b67 to
c4baa76
Compare
c4baa76 to
ef7b789
Compare
ef7b789 to
9f0c402
Compare
9f0c402 to
1db5b05
Compare
provokateurin
left a comment
There was a problem hiding this comment.
Thanks for the PR. I think it's not complete yet and a little bit more work to do.
| $enabled = $this->config->getAppValue('core', 'encryption_enabled', 'no'); | ||
| return $enabled === 'yes'; | ||
| try { | ||
| return Server::get(\OCP\IAppConfig::class)->getValueBool('core', 'encryption_enabled', false); |
There was a problem hiding this comment.
It's better if you inject IAppConfig into this class.
There was a problem hiding this comment.
I did try that. Commit af2453ea1fb on a different PR branch investigated this: injecting IAppConfig into Encryption\Manager's constructor eagerly resolved IDBConnection during OC::init() on PHP < 8.4 (no lazy ghost objects). On a fresh
install that happens before maintenance:install writes dbname to config.php, so the connection latched onto the default 'owncloud' DB, all migrations ran against the wrong file, and enable_all.php then crashed
with no such table: oc_appconfig.
If we really want to bottom that out, should we create separate issue and PR?
1db5b05 to
692cef4
Compare
… with repair step Switch all encryption config reads/writes from deprecated string-typed IConfig to bool-typed IAppConfig (getValueBool/setValueBool). Adds RetypeEncryptionConfigKeys repair step to retype existing string values to bool on upgrade. Includes lazy IAppConfig resolution in Manager and AppConfigTypeConflictException fallbacks throughout for safety during the upgrade window. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Stephen Cuppett <steve@cuppett.com>
Signed-off-by: Stephen Cuppett <steve@cuppett.com>
Apply suggestion from @artonge Co-authored-by: Louis <louis@chmn.me> Signed-off-by: Stephen Cuppett <steve@cuppett.com>
Co-authored-by: Louis <louis@chmn.me> Signed-off-by: Stephen Cuppett <steve@cuppett.com>
The IAppConfig API converts stored values to bool on read (getValueBool) and re-stamps the type on write (setValueBool), so legacy string-typed encryption config keys migrate lazily without an explicit repair step. Per PR review feedback, drop the repair step, its test, and the related AppConfigTypeConflictException fallback in Encryption\Manager::isEnabled that only existed to bridge the now-unneeded migration window. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Stephen Cuppett <steve@cuppett.com>
… to match strict 'yes'-only validation The verifyConfigKey check on core.encryption_enabled was reverted to master's strict $value !== 'yes' in 626fadd per review feedback, but the test data providers still asserted the broader truthy set (1/true/YES/on). Drop those entries so the tests match the controller. This is validation, not storage — IAppConfig::setValueBool's broader input handling is unrelated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Stephen Cuppett <steve@cuppett.com>
692cef4 to
b12abbe
Compare
Update to annotation from docblock comment Co-authored-by: Kate <26026535+provokateurin@users.noreply.github.com> Signed-off-by: Stephen Cuppett <steve@cuppett.com>
c95e12d to
ced9bf8
Compare
Co-authored-by: Kate <26026535+provokateurin@users.noreply.github.com> Signed-off-by: Stephen Cuppett <steve@cuppett.com>
…AdminTest The production code already uses getValueBool for this key; the IConfig mock branch was unreachable. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Stephen Cuppett <steve@cuppett.com>
ced9bf8 to
ec6d206
Compare
…yped APIs
Replace IConfig::{get,set}UserValue for the per-user 'recoveryEnabled' key
with IUserConfig::{getValueBool,setValueBool}, and IConfig::getAppValue for
'useMasterKey' with IAppConfig::getValueBool. IConfig is removed from Util
and Recovery constructors entirely. Clears the DeprecatedMethod psalm-baseline
entries for apps/encryption/lib/Util.php and the string-typed recoveryAdminEnabled
calls that were still in Recovery.php.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Stephen Cuppett <steve@cuppett.com>
Summary
Switch all encryption config reads/writes from deprecated string-typed IConfig to bool-typed IAppConfig (getValueBool/setValueBool). Adds RetypeEncryptionConfigKeys repair step to retype existing string values to bool on upgrade. Includes lazy IAppConfig resolution in Manager and AppConfigTypeConflictException fallbacks throughout for safety during the upgrade window.
conflict between new type (mixed) and old type (boolean)#58778Checklist
3. to review, feature component)stable32)AI (if applicable)