Encryption header visible in newly created files

[jkhsjdhjs]

Describe the bug
When opening a new text document (.md), which was never written anything but empty text to, the encryption header will be shown instead of an empty document. The encryption header consists of HBEGIN:oc_encryption_module:OC_DEFAULT_MODULE:cipher:AES-256-CTR:signed:true:HEND followed by 8111 dashs (-). This issue only occurs when Nextcloud Office is installed and enabled and encryption with the default encryption module is active. A Collabora Online server doesn't need to be configured.

When removing the encryption header and closing the document, the encryption header will again be visible after reopening the document.
When instead replacing the encryption header by some arbitrary text (e.g. just the letter a), closing an reopening, just the letter a without any encryption header will be displayed. The file will still be encrypted on the disk, so this is not a security issue. Interestingly, after clearing the arbitrary text from the new document (such that the document is now empty again), and re-opening it, the document will be shown as empty, the encryption header will not be shown anymore.

So let's define two types of files:

1. Files that were newly created and new files that were saved as empty after removing the visible encryption header.
2. Files that were previously written arbitrary non-empty text to, but are now empty.

When creating a type 1 and a type 2 file, these files will have the same checksum on the disk. Thus there is probably something in the database that can differentiate between those file types, resulting in the encryption header being visible for type 1 files, but not for type 2 files.

When creating a new, non-markdown document it will by default be downloaded. When opening the downloaded file with an editor, the encryption header is also be contained in there.

I reproduced this issue on a fresh local Nextcloud 23.0.2 Docker install, with just the default apps (no recommended apps) and Nextcloud Office and Default Encryption Module installed.

To Reproduce
Steps to reproduce the behavior:

1. Make sure encryption is enabled and install the Nextcloud Office app.
2. Create a new empty text document, which will by default be opened afterwards

Screenshots
Video displaying the reproduction steps: https://screens.totally.rip/2022/03/623613089d8e0.mp4

Client details:

• OS: Arch Linux
• Browser: Firefox Nightly 100, Chromium 99
• Version: 23.0.2
• Device: Desktop

Server details

Operating system: Linux 5.16.15-arch1-1 x86_64 (don't know which distro the docker container uses), Linux 5.13.19-1-pve x86_64 (Arch Linux)

Web server: Apache 2.4.52, nginx 13.6

Database: sqlite3 3.34.1, PostgreSQL 13.6

PHP version: 8.0.16, 8.1

Nextcloud version: 23.0.2

Version of the richdocuments app: 5.0.3

Version of Collabora Online: None, Collabora Office 21.06.9.1 (git hash: e60ec9f)

Logs

Nextcloud log (data/nextcloud.log)

Nothing is logged.

Browser log

Irrelevant because it's a server-side issue.

[YoannPa]

I have the exact same issue for .md files and .txt files.

Server details

Operating system: Ubuntu 16.04

Database: sqlite3

PHP version: 7.0.33

Nextcloud version: 23.0.2

Version of Collabora Online: 21.11.306

[4tler]

Same here:

Operating system: Ubuntu 20.04

Database: MariaDB 10.6.8

PHP version: 8

Nextcloud version: 24.0.0

Nextcloud Office: 6.1

[cswertz]

Same here. Same config as before. Quite irritating for users. Unfortunately I could figure out how to suppress the output in the document. Any idea?

[santo74]

Same issue here.
Default encryption is enabled and Nextcloud Office is installed and enabled.

[mig5]

I reproduce this too, but notably it seems specific to markdown files. An .odt file did not exhibit this issue.

[moqmar]

Can confirm that this is still happening on NC 25.0.1 with NC Office 7.0.1.

Do you all use SAML by any chance? Because we didn't experience that before, but we also upgraded NC from a way older version at the same time. So, no idea if that's related.

[jkhsjdhjs]

I don't use SAML.

[moqmar]

Found a workaround:

• Add a text file with one empty line to custom_apps/richdocuments/emptyTemplates/, and call that file template.md. You can use echo > template.md to create such a file (touch won't work); hexdump template.md should show one 0x0a byte, which is the newline character.
• Add md to the array in https://github.com/nextcloud/richdocuments/blob/master/lib/TemplateManager.php#L516 (custom_apps/richdocuments/lib/TemplateManager.php)

If the template file is exactly 0 bytes in size, it doesn't work, and that seems to be the default specified in line 523. It seems like the difference is that NextCloud would normally only use touch(), which doesn't seem to actually create the file, while with the Office app it instead creates an empty file here:

richdocuments/lib/Listener/FileCreatedFromTemplateListener.php

Line 53 in 003fb16

$event->getTarget()->putContent($this->templateManager->getEmptyFileContent($event->getTarget()->getExtension()));

I confirmed this by changing that section in FileCreatedFromTemplateListener.php like this (instead of the workaround I suggested above), and think that this would actually be a viable long-term fix:

		if ($templateFile === null) {
                        $emptyFileContent = $this->templateManager->getEmptyFileContent($event->getTarget()->getExtension());
                        if ($emptyFileContent != '') $event->getTarget()->putContent($emptyFileContent);
			return;
		}

[mig5]

@moqmar Nice, your workaround works great. Thanks. I didn't test the latter PHP fix. Not using SAML here either.

[juliusknorr]

Just pushed a potential fix for this in nextcloud/server#35649

Testing is very welcome :)