I was hoping to begin the discussion for a port to Drupal 8.
The following is on my mind.
1. Should we deprecate this module and move to the "file_encrypt" namespace to remain consistent with "field_encrypt" and "encrypt"?
2. I want to build this with the Encrypt D8 port, which serves as an API
3. I would love to hear about lessons learned. I initially thought an Encrypted File Stream Wrapper but this likely would not support a swappable file storage mechanism. Ideally it would work with any file stream wrapper, add additional settings to select the Encryption Profile created from Encrypt, and a yes/no on whether or not to encrypt it. This would be through a form alter and operations sponsored through file-based hooks.
4. Most use cases I have evaluated have been encrypting file content only. I am wondering if we can/should consider encrypting file names? Does this create a huge usability issue? Would that be solved by maintaining the original filename in the database as metadata?
5. Field encrypt can handle encryption of file-based metadata stored in the database. We should draw distinctions on the readme
Comments
Comment #2
colanI've included this issue in the list of goals for the GSOC project I posted, Add password-based public-key encryption to Drupal 8. Feel free to edit there if anything was missed, needs correction or will get done before then.
Comment #3
nerdsteinD8 project has been created over here: https://www.drupal.org/project/file_encrypt. Can we please note this in this project's readme?
There was an intentional renaming to "file_encrypt" to be in line with "field_encrypt" and the other *_encrypt modules built on top of Encrypt.
Happy to add other co-maintainers from this project as the interest arises.
Comment #4
rlhawkI updated the project's main page to include a link to File Encrypt.