Fix subfolders in encrypted folders - #17608
daniele-verducci wants to merge 5 commits into
Conversation
|
APK file: https://github.com/nextcloud/android/actions/runs/34505348733/artifacts/10163844801 |
|
master-IT test failed: https://www.kaminsky.me/nc-dev/android-integrationTests/17608-IT-master-17-26 |
5da4dab to
531efbc
Compare
📱 QA build
The QA build installs alongside a released Nextcloud app, so you can keep Downloading the file requires a GitHub account, so open this link on the |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
531efbc to
0f71ff1
Compare
alperozturk96
left a comment
There was a problem hiding this comment.
Could you please share the crash-log and explain your approach?
|
|
||
| return try { | ||
| EncryptionUtils.decryptStringAsymmetricV2(user.encryptedMetadataKey, privateKey) | ||
| EncryptionUtils.decryptStringAsymmetricV2(user.decryptedMetadataKey, privateKey) |
There was a problem hiding this comment.
Why we are trying to decrypt the decrypted metadata key here?
There was a problem hiding this comment.
I see, this doesn't make sense. The result is not used, so I believe this call in the previous code was used to throw an exception if the key isn't valid. Is it a correct interpretation?
In that case, maybe I can get directly the key with retrieveTopMostMetadataKey(). It should throw an exception as well.
But then should I verify the key in any way?
| val metadataFile = EncryptionUtils.deserializeJSON( | ||
| serializedMetadata, | ||
| object : TypeToken<EncryptedFolderMetadataFile>() {} | ||
| private fun decryptsMetadataV2(ocFile: OCFile, privateKey: String, client: OwnCloudClient): Boolean { |
There was a problem hiding this comment.
Previously GetMetadataRemoteOperation was already given the metadata why now we need to retrieveTopMostMetadata and also eventually call decryptFolderMetadataFile ?
There was a problem hiding this comment.
GetMetadataRemoteOperation retrieves the metadata for the current folder, but I saw with the debugger that the users array is present only if the folder is the root encrypted folder. If we are in a subfolder, it's not. I think this isn't a server bug because it's working in the web version (checked the calls and the answer is the same, just in XML instead of JSON, so they must be keeping the root encrypted folder's key and using it for the subfolders, I believe)
Hey Alper, here's the crashlog: This happens when opening a subfolder on an encrypted folder. The crash is caused by the users array being empty/null (the user is used to retrieve the key). I can say it works, but I'm not sure it's the correct fix. What do you think about it? |
0f71ff1 to
7bdb3c3
Compare
|
@alperozturk96 Can you check last commit? Could it be a solution? |
|
blue-Light-Screenshot test failed, but no output was generated. Maybe a preliminary stage failed. |
Signed-off-by: daniele-verducci <daniele.verducci@nextcloud.com>
…etrieval function) Signed-off-by: daniele-verducci <daniele.verducci@nextcloud.com> Signed-off-by: daniele-verducci <daniele.verducci@nextcloud.com>
Signed-off-by: daniele-verducci <daniele.verducci@nextcloud.com>
This reverts commit 7bdb3c3. Signed-off-by: daniele-verducci <daniele.verducci@nextcloud.com>
7bdb3c3 to
3d34758
Compare
| return try { | ||
| EncryptionUtils.decryptStringAsymmetricV2(user.encryptedMetadataKey, privateKey) | ||
| true | ||
| val metadataKey = EncryptionUtilsV2().retrieveTopMostMetadataKey( |
There was a problem hiding this comment.
I saw this comment in the master. @tobiasKaminsky I think using retrieveTopMostMetadataKey directly here is okay. What do you think?
// we are in a subfolder, decrypt information is in top most encrypted folder
How to repro:
How to repro 2:
🏁 Checklist
/backport to stable-xx.x🤖 AI (if applicable)