Copy encryption keys first and then rename the files #40433
Conversation
|
Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes. |
|
💥 Acceptance tests pipeline webUIRestrictSharing-chrome-mariadb10.2-php7.4 failed. The build has been cancelled. |
|
Copying the keys will change the fileid of the keys in the filecache. This shouldn't be a problem though. It should work regardless of the actual storage. In fact, it's questionable to have the data in the filecache; it's seems a side effect of the tools used, and it seems to work even if the data is removed from the filecache table. |
jvillafanez
force-pushed
the
encryption_copy_keys_first
branch
from
260a216 to
83f3a3c
Compare
|
@jvillafanez grab some reviewers? |
There was a problem hiding this comment.
LGTM 👍 @DeepDiver1975 Could you also please have a look as you were recently working with key stuff.
|
Please add changelog |
|
Kudos, SonarCloud Quality Gate passed! |
Description
Instead of renaming the file and then move the keys, we'll copy the keys first so we have a chance of reverting the changes if the file fails to be renamed. We either remove the original keys if rename succeeds or the copied keys if it fails.
Worst case, if exception happens and cleanup can't be performed, the file should still be accessible because there are valid keys still in place
Related Issue
https://github.com/owncloud/enterprise/issues/5344
Motivation and Context
This will harden the code and prevent the file from becoming inaccessible if something goes wrong.
How Has This Been Tested?
Manually tested with the steps provided in the related issue.
Screenshots (if appropriate):
Types of changes
Checklist: