Sanitizer: How to Use

Michael · August 5, 2020, 4:37am

That’s correct.
There are plans to integrate similar functions into the desktop app.

github.com/cryptomator/cryptomator

Built-in Diagnostic Tool (formerly known as Sanitizer)

opened 10:22AM - 27 May 20 UTC

closed 04:09PM - 01 Jun 21 UTC

tobihagemann

type:feature-request

### Summary With a diagnostic tool, Cryptomator will be able to check the "heal…th" of a vault. This works similarly to the [Sanitizer](https://github.com/cryptomator/sanitizer) project but will be built-in for more convenience. ### Motivation The location of a Cryptomator vault is not a controlled environment. Basically, "anything" could happen to the encrypted files. Files and/or folders could be renamed due to sync conflicts. Even file contents could be malformed without Cryptomator's control that make encrypted contents unreadable. Of course, if users deliberately changes these files, they will expect that the decryption is erroneous. But in most cases, changes happen without the users' awareness. A diagnostic tool should be able to guide users to detect or even solve problems with the vault. If users are unable to solve these problems on their own, they at least would have a diagnostic report at hand so that others could have a look at it. ### Proposal To keep things easy as a first step, the diagnostic tool should only be able to perform a check on the vault without solving any problems or other specific commands. Therefore, the feature set is smaller than Sanitizer in the initial implementation. #### Check Vault This command should detect problems in Cryptomator vaults that are related to the directory structure and filenames. 1. Check the existence of `masterkey.cryptomator` and confirm the password before proceeding. 2. Make a directory listing of the vault root and list all names that do not match `d` and `masterkey.cryptomator(.*)`. Check the existence of `d` before proceeding. * Reasoning is to find directories like `d (1)` that could exist due to sync conflicts. 3. Recursively traverse through `d` from a cleartext perspective. Begin with cleartext root `/`. 1. Resolve ciphertext path from cleartext path. 2. Check the existence of the ciphertext path. 3. Make a directory listing of the ciphertext path and check each item name against the expected pattern. * If it matches the expected pattern: * Try to decrypt ciphertext name. If it's a shortened filename, resolve it first. * If it's a `.c9r` directory, make a directory listing, log any unexpected items, and check if it's only a directory or only a symlink. * If it's a `.c9s` directory, check its consistency as well. * If it doesn't match the expected pattern: * Log ciphertext filenames because these files would be ignored by Cryptomator. (Do not consider the ciphertext filenames that would potentially be resolved by Cryptomator via the conflict resolver. Or maybe do if it's feasible.) 4. Collect the ciphertext path in a list for step 4. 5. Repeat from step 3.i for all cleartext directories that have been found. 4. Recursively traverse through `d` from a ciphertext perspective. Log the folders that have not been checked in step 3. * It's debatable if it would make sense to check these files even further. It's probably enough to log the folder names that they are unreachable from a cleartext perspective. The purpose of step 3 is to check if everything is consistent based on what Cryptomator would actually "see". The purpose of step 4 is to check if there are any other items inside the vault that would be ignored by Cryptomator but may still contain encrypted data that a user would like to access. #### Check Vault (Deep) This command should extend the previous command in step 3.3 by also checking the file contents' integrity.