When using server-side encryption, we currently rely on the header starting strictly on the first byte. This isn't always the case when some sort of errors or configuration mistakes happen.
Possible cases can be:
- The file was marked as unencrypted in the database and an application adds a BOM to the file during their attempt to read them anyway, which is then being saved within Nextcloud
- Using S3 with some kind of DPI between Nextcloud and the object storage with a configuration being enabled that modifies the file content (which shouldn't happen, but is possible as we don't send over the files as
Content-Type: application/octet-stream, which would be the correct way)
Example header content for such a case (important: there are more BOMs that could occur!):
the first 20 bytes actually are:
hex: ef bb bf 48 42 45 47 49 4e 3a 6f 63 5f 65 6e 63 72 79 70 74
ascii: ...HBEGIN:oc_encrypt
In these cases, the file is being unrecoverable by any of our occ encryption commands, leading to the impression we corrupted the file during encryption and manual backups must be used.
We should harden the server-side encryption, so we ignore any BOMs in front of the header itself or at least make it self-recoverable in any way.
When using server-side encryption, we currently rely on the header starting strictly on the first byte. This isn't always the case when some sort of errors or configuration mistakes happen.
Possible cases can be:
Content-Type: application/octet-stream, which would be the correct way)Example header content for such a case (important: there are more BOMs that could occur!):
In these cases, the file is being unrecoverable by any of our
occ encryptioncommands, leading to the impression we corrupted the file during encryption and manual backups must be used.We should harden the server-side encryption, so we ignore any BOMs in front of the header itself or at least make it self-recoverable in any way.