search

cryptomator / cryptofs

Java Filesystem Provider with integrated encryption
GNU Affero General Public License v3.0
94 stars 35 forks source link

Feature/type check #109

Closed infeo closed 3 years ago

infeo commented 3 years ago

This PR adds a new health check to the health service: CiphertextFileTypeCheck.

The checks looks at all c9r and c9s directories and tries to determine their cleartext type by checking for existence of "signature" files, i.e. dir.c9r, symlink.c9r and contents.c9r.

It produces three results: KnownType, AmbiguousType and UnknownType.

The result resolution is as follows:

  1. Exists only one, valid signature file, a KnownType is returned
  2. Exist at least two valid signature files, an AmbiguousType is returned
  3. Is no valid signatre file present, an UnknownType is returned.

Valid sig files are for c9r dirs dir.c9r and symlink.c9r. For c9s its the same with additionally contents.c9r.

overheadhunter commented 3 years ago

I figured the containsDirFile(...), containsSymlinkFile(...) etc are only used for a single purpose, so I inlined them in c005cb5 and got rid of some code (+22 -46).

Before approving, I'd still like to discuss, if we really should skip checking for misplaced unshortened.c9r/contents.c9r files (in other words: get rid of checkForContentsC9r flag). In theory this case shouldn't exist. But we're doing a health check, after all...

For the record: We agreed offline to ignore a misplaced contents.c9r inside a unshortened dir for now. Should the need arise, we can still add a further result type.