Closed dawehner closed 8 years ago
There is nothing that stands out to me as being problematic with this approach. We certainly need to have some good error correction in the event that someone passes a bogus encryption profile. I think "key_profile" should actually be "encryption_profile", which is a wrapper for the encryption algorithm and the selected key.
Like anything else, I say we give it a shot. We may find limitations but we can cross that bridge when we get to it.
Started with some initial implementation. What are your thoughts so far?
Feedback applied but overall this is a good start
Here is a more specific architecture for decrypting file content and making it flexible within Drupal.
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}
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 Drupalencrypt://{key_profile}/path/...
This calls out to the decrypt method itself: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?