As you might’ve already guessed, Pubkey Encrypt is a Google Summer of Code’2016 sponsored project. As a part of the GSoC program, I’ve spent the last 2.5 months building this module for Drupal 8. The journey so far has been amazing for me and now we’re approaching the end of the program. So I spent this week in finalizing the module. For those who don’t know, Pubkey Encrypt is a security-related module which provides a way for encrypting data with users’ login credentials. But the way the module is designed, it delegates the task of actual data encryption/decryption to some other module. Previously, we were using Encrypt Test for this purpose, which was just a test sub-module within the Encrypt module, and were waiting for Real AES module to get in a stable state. A few weeks ago, I posted a patch to fix the module but its maintainers haven’t responded yet, and its HEAD is still broken. Thus we decided to use the PHPSecLib Encryption module which in turn uses the external PHP Secure Communications Library and is hence expected to be pretty secure. The task seemed quite simple but the relevant changes simply broke all the tests for Pubkey Encrypt.
More specifically, Drupal\Core\Config\Testing\ConfigSchemaChecker started throwing Incomplete Schema errors. After much analysis, I discovered that there was a subtle, non-fatal bug in the Encrypt module. So I reported it along with a patch to get the issue fixed:
Until this issue gets closed, I’ve managed a way to fix the tests; I just added the statement $this->strictConfigSchema = FALSE; into my test classes. This ensures that when any of the tests run, a strict checking of any new configuration files does not take place.
While I was at the issues queue for Encrypt module, I also helped in a few other tickets:
- Remove AES Encryption key type plugin
- Shift reliance from “aes_encryption” key type to “encryption” key type
Interestingly, both Real AES & PHPSecLib Encryption modules rely on external PHP libraries and are the only ones a person can use with Drupal 8 for the task of data encryption/decryption. So my mentor Adam Bergstein (@nerdstein) suggested me to create an OpenSSL-based such module too, just for the sake of learning. I finished the task quickly as I had already spent quite some time exploring Key and Encrypt modules. Have a look at the work done here: Encrypt - OpenSSL Encryption for Drupal 8.
I should note that even though this module is for experimental-use only, I still added tests into it and accompanied the repo with Travis CI. My experience with Pubkey Encrypt so far has taught me that this is a great programming practice. Though I did not write any of the tests from scratch, but instead used the ones from PHPSecLib Encryption module. That’s because both these modules are supposed to provide encryption/decryption functions by integrating with the Encrypt module, thus their test assertions are bound to be similar. So why reinvent the wheel!!!
Then I tested Pubkey Encrypt with a clean Drupal 8.2.x installation and latest releases of all its dependencies. Even though the build was passing, I still manually checked for each and every module functionality. That’s because I just needed to ensure that everything was working absolutely fine before moving on. Fortunately, my results showed that it did.
In my weekly meeting with mentors Adam Bergstein (@nerdstein) and Colan Schwartz (@colan), we discussed the plan to release Pubkey Encrypt. All the code written so far has been pulled into the main repo and reviewed too. My mentors have also started smoke-testing the module. So far they’ve only found minor issues, as can be seen by these tickets:
- Overview page should be tab on settings page
- Add missing installation steps
- Provide user with message that one-time login links will fail
- Inform user that initializing module will log him/her (and others) out
So we’ve decided to formally close the GSoC project and release this module for public by the end of next week. We’ve also decided that I would use the remaining two weeks of GSoC to help in the issues queue for Field Encrypt and File Encrypt modules. That’s because Pubkey Encrypt just provides an API for encrypting data with users’ login credentials. For a user to employ our mechanism for encrypting field data, Field Encrypt module should be used alongside. Similarly, encrypting file data through our mechanism would require File Encrypt module. Hence the success of my module directly depends on the health of these two modules. So the idea of me helping in their issues queue seemed appropriate to us.
I ended the week by finishing review of Mehul’s project “Port Google Login Authenticator to Drupal 8”. I had already completed a code review last week so this week I just tested the working of his project. I found a few bugs here and there though most of the core functionality seemed to be working fine. Have a look at the issues I’ve created as a part of this review process:
- TFA setup link hardcoded to use same validation plugin
- Unable to remove a trusted browser
- The “require tfa” permission seems to be a bit confusing
- TFA setup not working properly
- Check for composer dependencies during module installation
I also provided patches for some of the issues which were simple and straightforward to fix. That’s because I did not want to overwhelm Mehul at this point in GSoC. But also because I think that in open-source world, criticism should always be accompanied with contribution.