d8-contrib-modules / file_encrypt Goto Github PK

Automated tests for...

1. Validating operations of the stream for fields and other use cases
2. Validating streaming
3. Use of field encrypt for metadata (maybe this goes into field_encrypt)

Currently, the encrypt stream supports block-level streaming (read file in, encrypt it, write it, close the stream). Some encryption algorithms have support for streaming, which will perform encryption incrementally as the file is read.

One approach is evaluating/copying the interface from halite.

Tasks:

• Ensure that the streaming requirement/suggestion is documented properly inside README.md + hook_requirements

Use case:

Given I'm a site builder
When I select encrypt:// in the file field settings
and I upload a file
Then file should be encrypted on disk

Let's investigate whether selecting the encrypt stream is already possible and works properly.

Also let's ensure to make it clear in the README how users can configure file fields for that.

I have successfully implemented file encryption (using real_aes) and have it working with most cases I have tested, but I cannot get it to work with PDF files. It saves and appears to encrypt the files, but when I attempt to download them the request always whitescreens. It doesn't cause any PHP errors or warnings, and it doesn't save any messages in the log. Following the request logic with Xdebug, I see that it gets all the way to sending a BinaryFileResponse with a file member that looks correct and terminating the kernel cycle. Firefox Developer Tools indicate that the browser is receiving an HTTP 200 response of HTML type a little smaller than the actual file (289K, whereas the original PDF is 292K).

I'm really not sure where to go from here. Has file_encrypt been tested with PDF files, specifically? Does anyone have any recommendations how I might proceed from here to isolate the problem? cc @dawehner

@dawehner: I'm encountering the following error trying to download a file encrypted with file_encrypt:

AH01071: Got error 'PHP message: Uncaught PHP Exception LogicException: "The controller must return a response (encrypt given)." at /var/www/vendor/symfony/http-kernel/HttpKernel.php line 162 '

The download URI is /encrypt/files/my_kms/subdir/file.pdf, which is what $request->getRequestUri() returns inside \Drupal\system\FileDownloadController::download().

I'm using real_aes for encryption. I'm also using workbench_moderation and doing multilingual with path-based language negotiation (e.g., /fr/node/1).

Here is a more specific architecture for decrypting file content and making it flexible within Drupal.

• Implement a route like encrypt.files which allows code to link to our encrypted file URL.
  In this URL we could encode the profile, so something like /encrypt/{key_profile_name}/{path}
• In the controller for that route, use encrypt://{key_profile_name}/{path} as URL, but keep mostly the existing implementation of \Drupal\system\FileDownloadController::download to keep everything in the scope of Drupal
• stream wrapper that looks like : encrypt://{key_profile}/path/...
  This calls out to the decrypt method itself:
• The decryption supports streaming: Stream in the file content via the decryption.
• Decryption doesn't support streaming, load the file and decrpyt it via ->decrypt directly, basically exactly how http://cgit.drupalcode.org/encrypted_files/tree/includes/EncryptedStreamWrapper.inc is dealing with it.

A streaming interface

In order to make streaming as easy as possible one could use basically https://github.com/paragonie/halite/blob/master/src/Contract/StreamInterface.php as interface for description streaming.

What do you think about this more low level details?

Let's talk about how / whether we want to support images and image styles.

Images should just work, as they aren't conceptually that different to private files.

Current challenge with image styles

When rendering an actual image style, styles prefix the URL like the following:
encryption://styles/$image_style/$schema/test/$destination/file.jpg
This leads to a couple of issues:

• Our way of extracting the encryption profile from the URL doesn't work anymore: https://github.com/d8-contrib-modules/file_encrypt/pull/14/files#diff-870784d9bd6931d12db6d9ebb6d6f230R16
• We need our own custom version of \Drupal\image\PathProcessor\PathProcessorImageStyles
• Maybe potential more

In order to not leak information out, we have to encrypt/randomize the filename.

Until we properly implement encryption of the filename itself, we should at least randomize it.

• Adapt readme
• Tests
• Implement the randomization

PHP does not necessarily call the stream_close() method on stream wrappers every time it calls stream_open(). For example, when copying a file (copy()) it calls both, but when moving a file (rename()) it does not. The result is that renaming a file using EncryptStreamWrapper decrypts the file but does not re-encrypt it, leaving it unencrypted on disk. And when core issue file_unmanaged_move() should issue rename() where possible instead of copy() & unlink() [#1377740] landed (8.1.4), this problem became acute. I discovered this by way of the dropzonejs entity browser widget, which uses file_unmanaged_move() to save new uploads. I played around with moving the encryption to a different method (i.e., stream_write()), but without success. It has been suggested to me that we shouldn't be using stream wrappers to solve this problem in the first place--that encryption is a job for PHP stream filters instead. (Perhaps switching to filters would help with #5, too.) @dawehner

@dawehner and I discussed leveraging field encrypt for encryption of metadata of files. It's absolutely capable of doing so.

Suggested outcome: document in the file_encrypt readme how to configure field_encrypt to encrypt metadata of files. This requires testing, capturing the steps, and/or potential patches to field_encrypt as needed.

• automatic tests
• add a description to the readme