Encryption must not rely on part file name

[PVince81]

When overwriting existing files, the encryption code relies on the part file name to find out what the final file name is, this in order to get the existing encryption key set.

lib/private/Encryption/File.php|65| $ownerPath = $this->util->stripPartialFileExtension($ownerPath);
lib/private/Encryption/Keys/Storage.php|91| $realFile = $this->util->stripPartialFileExtension($path);
lib/private/Encryption/Util.php|250| public function stripPartialFileExtension($path) {
lib/private/Files/Storage/Wrapper/Encryption.php|386| $realFile = $this->util->stripPartialFileExtension($path);
lib/private/Files/Storage/Wrapper/Encryption.php|863| $realFile = $this->util->stripPartialFileExtension($path);
lib/private/Files/Storage/Wrapper/Encryption.php|911| $realFile = $this->util->stripPartialFileExtension($path);

This is bad because it prevents us to change the format of the part files to solve issues like too long file names: #26978

This blocks #26978

[PVince81]

Read from here for a more detailed explanation: #26978 (comment)

[PVince81]

Sometimes I wonder if we should simply have a table to track upload transactions with transfer id, received chunks, final file name, etc. In this case we could use the transfer id as part file name which could be used to resolve the final file name from the tables.

I suppose such table could also have more benefits like finding out about aborted uploads and cleaning up like in #14646

@butonic @DeepDiver1975 @IljaN

[PVince81]

Another extremely dirty hack:

1. create part file where the file name is only the transfer id: "$transferid.data.part" (containing the uploaded data)
2. create a second file "transferid.metadata.part" containing the metadata like the target file name, etc
3. have the encryption code from stripPartialFileExtension read the part file name received from fopen() or other APIs, which is "$transferid.data.part", then extract the transferid and open the metadata file to read the final file name.

Yeah... I don't like it either.

[guruz]

(afaik The new chunking (chunkingNG) does not have a transfer id or information about the final file name anymore)

[PVince81]

@guruz hmm indeed, the transfer id is the upload id that is inside the virtual uploads folder.

[PVince81]

But that doesn't matter, because the final MOVE will still cause the part file logic to be triggered.

[PVince81]

Not fixable in a short time, needs a new concept to fit the encryption code's requirements into the architecture, possibly a rewrite of some of the encryption bits.

Estimate 5-10 md depending on research and also acquiring more knowledge of encryption code overall to make sure we're not breaking other things.

This is blocking any tasks related to renaming part files:

• .ocTransferIDXXXXX.part makes filename too long #25425 #26978 (to fix .ocTransferIDXXXXX.part makes filename too long #25425)

cc @pmaier1 FYI