Fix encrypted version to 0 when finding unencrypted file#28373
Fix encrypted version to 0 when finding unencrypted file#28373
Conversation
|
/backport to stable22 |
|
/backport to stable21 |
|
/backport to stable20 |
6dad182 to
532b01b
Compare
|
tests fail for me locally even if I comment out all my code changes, it's only if I delete the rows that they pass |
532b01b to
8c3392f
Compare
|
I've added unit tests now |
|
I've added steps to test in the original post |
|
Please keep CVE-2020-8150 in mind. Silently overwriting encrypted files should not be allowed. |
not sure if this applies. @LukasReschke can you check ? the command is only for admins to run on the CLI and it doesn't touch the files after that, the admin can still run "occ encrypt-all" to reencrypt those files. |
|
okay, so the CVE mentions the legacy encryption scheme |
|
Tests do not seem to be happy, though I cannot see why that change should cause such a failure |
|
and yet the tests pass locally for me... might be a cleanup issue revealed by different test order edit: wait, these tests are not even related. probably cleanup issue, yes |
|
even when running all tests on this branch locally I couldn't reproduce this issue :-( |
8c3392f to
75d5348
Compare
|
Nope, tests still fails :) |
|
switched back to WIP as I'm going to use CI for debugging this strange side effect (with a reduced drone config) |
|
oh... so even deleting my new test has the side effect 🤔 |
|
ohh, locally when I run all tests there are only 18 but here in CI there's way more, and it even runs "/drone/src/apps/files_versions/tests/VersioningTest.php:690" even though I deleted those a few commits ago... I wonder if it's a setup issue / Drone caching issue... |
|
let's see if a resend in a separate PR works: #28593 |
|
alright, I was looking at an old test results. now bringing back the tests for closer inspection... |
|
mega facepalm so it seems I forgot to enable the encryption app locally before running all the tests, I didn't know this was necessary and thought the test scripts would do that at some stage ?! now I'm able to see the failure locally |
|
FINALLY some results: it turns out that |
Whenever the command is run and a "legacy cipher" seems to be detected when the legacy option is disabled, it's highly likely that the file is actually unencrypted but the database contains a encrypted version higher than 0 for some reason. The command now detects this case and automatically sets the encrypted version to 0 so that the file can be read again. Signed-off-by: Vincent Petry <vincent@nextcloud.com>
87713f9 to
28dc915
Compare
This prevents side effects in tests by properly cleaning up even with expected exceptions. Signed-off-by: Vincent Petry <vincent@nextcloud.com>
28dc915 to
9c6bbfa
Compare
|
finally green! please review the last commit which fixes the test issue, then we can merge 😄 |

Whenever the command is run and a "legacy cipher" seems to be detected
when the legacy option is disabled, it's highly likely that the file is
actually unencrypted but the database contains a encrypted version
higher than 0 for some reason.
The command now detects this case and automatically sets the encrypted
⚠️ This assumes that there are no more legacy encrypted files because the admin has not set the legacy option.
version to 0 so that the file can be read again.
Steps to test
occ app:enable encryption && occ encryption:enableupdate oc_filecache set encrypted=2 where name like '%unencrypted%';occ encryption:fix-encrypted-version admin