Properly clean up configkey values from oc_appconfig table when disabling encryption

[pako81]

Follow-up of #35756 because of changes in the branching model.

Description

Currently, we have the problem that we do not correctly clean up the configkey values in the oc_appconfig table when disabling encryption.

Specifically the useMasterKey key for the encryption app, which stays set to 1. This seems to lead to the encryption_enabled key for core to remain set to no so when trying to reenable the encryption app and running encryption:select-encryption-type masterkey, this will fail.

The same has been observed for user-keys encryption. This PR fixes this behavior by properly cleaning up the configkey values and making re-enabling of encryption possible.

Related Issue

• Fixes https://github.com/owncloud/enterprise/issues/3410

How Has This Been Tested?

• Manually by first activating encryption by running: occ app:enable encryption, occ encryption:enable, occ encryption:select-encryption-type masterkey -y and encryption:encrypt-all

• Then disable it with occ app:disable encryption, occ encryption:disable

• Re-enabling encryption once again and check that when running occ encryption:select-encryption-type masterkey, no error is triggered.

Tested the same with user-keys encryption.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Database schema changes (next release will require increase of minor version instead of patch)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[codecov]

Codecov Report

Merging #35980 into master will increase coverage by 0.00%.
The diff coverage is 94.11%.

@@            Coverage Diff            @@
##             master   #35980   +/-   ##
=========================================
  Coverage     64.75%   64.75%           
- Complexity    19408    19409    +1     
=========================================
  Files          1285     1285           
  Lines         75830    75845   +15     
  Branches       1336     1336           
=========================================
+ Hits          49101    49116   +15     
  Misses        26335    26335           
  Partials        394      394           

Flag	Coverage Δ	Complexity Δ
#javascript	54.06% <ø> (ø)	0.00 <ø> (ø)
#phpunit	65.93% <94.11%> (+<0.01%)	19409.00 <1.00> (+1.00)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ	Complexity Δ
core/register_command.php	0.00% <0.00%> (ø)	0.00 <0.00> (ø)
core/Command/Encryption/Disable.php	100.00% <100.00%> (ø)	5.00 <1.00> (+1.00)
lib/private/Share/MailNotifications.php	95.69% <0.00%> (-0.05%)	32.00% <0.00%> (-1.00%)
lib/private/legacy/app.php	62.47% <0.00%> (+0.16%)	177.00% <0.00%> (+1.00%)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b962fb4...a59779e. Read the comment docs.

[jvillafanez]

I'm wondering if we should decrypt the files. What could happen if there are encrypted files and we disable the encryption? What happen to those files if we enable encryption (either master key or user key) afterwards?

I guess that we can't decrypt the files ouselves before disabling encryption, but if there is any risk we should at least warn the admin.

[sharidas]

Lets say if admin disables encryption before decrypting the file(s), the admin always have the chance to recover the files, if he/she knows what type of encryption was used.
For example:

• Admin enables user-key encryption
• Encrypts the fs with user-key encryption
• Disables encryption

At this point the files which are encrypted cannot be decrypted. Because the encryption is disabled. Now to recover the encrypted files, admin has to enable encryption and select the type of encryption which was used. In this example user-key encryption. And login to the respective user(s), the encrypted files will be decrypted if user tries to download them.

If the admin attemtps for masterkey then previously encrypted files will not be decrypted.

All I see is the admin should be aware of previously used encryption here.

[jvillafanez]

Maybe we should call to PM to decide what to do, mainly because the admin will reenable encryption with the wrong type (or we should assume so).

• Write a wall of text in blood (otherwise the admin won't read it) explaining the risks if there are still encrypted files in the system
• Ensure that it's possible to disable encryption only if there is no encrypted files.
• Store somewhere, the previous encryption type in order to ensure the wrong encryption type won't be enabled afterwards. Makes me wonder if we really want to delete the keys stored in the configuration.

[pako81]

My 2 cents: do not allow disabling encryption if we notice there are still encrypted files in FS. This way we are 100% on the safe side.

And this can easily be achieved by querying the filecache for files having the encrypted flag set to > 1.

If we do not want to consider this option, the alternative should be to allow disable but throw a warning when trying to disable encryption.

[micbar]

@pmaier1 @pako81 @cdamken Could we make a decision here?

[phil-davis]

@micbar there is no response here to your ping on Oct 21.
Is this something that will move forward? For 10.4 or?

[pako81]

@cdamken @pmaier1 may we have your thoughts on this, please? My idea on this at #35980 (comment)

[pako81]

This is not making any progress.

[mmattel]

do not allow disabling encryption if we notice there are still encrypted files in FS. This way we are 100% on the safe side

I would add that and finalize this PR. Then this can be reviewed and merged.

[phil-davis]

@pako81 what is the status of this PR? Moving anywhere?
CC: @micbar

[pako81]

@phil-davis this needs a PM decision and already pinged several times #35980 (comment)

[pmaier1]

@cdamken @pmaier1 may we have your thoughts on this, please? My idea on this at #35980 (comment)

I agree with @pako81, makes sense. First decrypt, then disable.

[micbar]

@pako81 can DEV take over? @VicDeo Can bring this to a mergeable state?

[VicDeo]

@pako81 does the current state match your proposal in #35980 (comment) ?

[pako81]

@VicDeo yes, looks fine from my POV - thx

[jvillafanez]

Just to double-check, did you test running the command without encryption? I think fetchColumn will return false if there are no more rows, so I think it's better to check against this, otherwise you'll likely be checking false > 0 which might work but feels strange.

[VicDeo]

you'll likely be checking false > 0 which might work but feels strange.

true. I explicitly casted the result to boolean. Is it better now?

[VicDeo]

No idea about the failures:

apiFederation1-10.4.1-mariadb10.2-php7.4: Error response from daemon: No such image: owncloudci/core:latest

https://hub.docker.com/r/owncloudci/core/tags
connectivity issue?

[phil-davis]

I restarted drone - it's having a bad day.