Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I would like to offer to become a co-maintainer of the Encrypt module.
I've been a web developer for 20 years and a Drupal developer for the last six years. I've been working with the Encrypt module for over a year and have contributed a number of bug fixes and functionality enhancements over that time. I helped create and am a co-maintainer of the Townsend Security Key Connection module.
My immediate goals for Encrypt are to get all release blockers fixed in order get a stable 2.x version released, preferably with the new configuration management functionality that I've created. Ultimately, I'd like to see Encrypt become the de facto standard for encrypting and decrypting data within Drupal, with a more standardized way for other modules to implement its functionality. I'm also thinking ahead to porting the module to Drupal 8. Maybe even get some form of encryption API into Drupal 9? One can dream.
I have a strong interest in seeing Encrypt make progress toward the above goals and can commit to being an active and responsive co-maintainer.
Comments
Comment #1
gregglesThanks for posting this, Rick.
Let's use this opportunity to agree on some standards for the module. We discussed in-person the need for tests on a module like this. What things do we think absolutely need tests. When is it optional? Anything else?
Comment #2
rlhawkBesides testing for encryption and decryption using the various included methods, I think it would also make sense to test the default providers, mainly to confirm that a key is returned. Testing data portability, as is currently done, is essential. For encryption configurations, there should be tests to confirm creation, modification, and deletion of a configuration, as well as the ability to make a configuration the default. Less important would be tests to make sure that the default cannot be deleted or disabled. Those are my thoughts about tests. I'll post ideas about standards next.
Comment #3
rlhawkHere are my thoughts about standards:
I think Encrypt should stay focused on being a pure API, just to provide encryption and decryption functionality. On top of that, though, I'd like to see some sort of method for modules that leverage the API to register that they are encrypting, similar to the way the Migrate module allows modules to register migrations. That would allow for an administrative page where admins could see and manage all of the data that's being encrypted—again, similar to Migrate.
There should also be a way for modules to use a standard method of storage, instead of each one having to create its own solution. Ideally, this would be plugin-based, allowing for different storage options, but that may be a bit ambitious.
Is it reasonable to expect Encrypt to manage bulk encryption and decryption (using the Batch API) or should that be the responsibility of the implementing module?
Comment #4
rlhawkHere's one standard I'd like to see addressed soon: Standardize the name of the module as "Encrypt." It's often referred to as Encryption; in fact, as far as Drupal.org is concerned, that's its official name. It's confusing and I think we should pick one name and use it always.
Comment #5
rlhawkGreg - Do you have any more questions for me about goals for the Encrypt module and/or my qualifications to join the project as a co-maintainer?
Comment #6
gregglesThe only thing we haven't covered so far is https://drupal.org/node/363367
I think I like all of those except for the ones that start with (optional). What do you think?
Comment #7
rlhawkYes, I agree about all of those guidelines. The only optional ones I saw were for release notes and maintaining version numbers between major versions of Drupal. I can go either way on those, but I think release notes are nice, so I'd lean toward implementing them.
Comment #8
gregglesThanks, rlhawk!
I've now added you as a co-maintainer with the ability to do most everything on the project. I'm looking forward to collaborating with you.
Comment #9
rlhawkThanks, Greg! I look forward to working with you, too.