This week’s work started by the integration of Travis CI into the Github repo of Pubkey Encrypt. Initially, we thought that we’d move the project from Github to D.O after releasing a working prototype of the module. But now we have decided to keep both the repos as is the case for many D8 modules. Now Travis CI is free for all open-source projects hosted on Github. For those who don’t know, Travis is a Continuous Integration software which, in simple words, makes a build of a software project upon each commit or PR in the repo and then runs the user-defined tests on it. A passing build means that the new changes pass all the tests, and a broken build denotes the other case. This is used to ensure that any new functionality added to the project doesn’t end up accidentally breaking something else in it. And such a setup is very important in any agile software development methodology, where the product is developed incrementally.
Setting up Travis CI is generally easy for Drupal modules hosted on Github, thanks to the Drupal - Travis integration project by Fabian Franz. The project contains ready-to-use Travis CI configuration files for a Drupal environment, so to get Travis up and running within minutes. But my module Pubkey Encrypt has a temporary dependency on Encrypt Test module, which is just a test sub-module within the Encrypt module. So my build was getting failed to generate because of this missing dependency in the Travis CI environment. I fixed that by writing an additional bash script which downloads this module and moves it into the relevant directory so to ensure its presence before Pubkey Encrypt installation process starts in the Travis CI environment. It worked like a charm, and the results can be noticed here:
Checkout the Travis CI configuration files for Pubkey Encrypt here.
In my weekly meeting with mentors Adam Bergstein (@nerdstein) and Colan Schwartz (@colan), we:
- Reviewed the performance benchmarks for the module I generated last week. Though the module initialization takes way too long to proceed if a large key size is selected by the admin, Colan thought that it’s still ok as long as the admin is aware about the consequences of various options on module initialization page i.e. small keys get generated quickly but provide less security while large keys take quite some time in generation but provide enhanced security. Though Colan recommended the use of Batch API during module initialization, so to avoid any PHP timeout issues.
- Discussed the dependency of our module upon OpenSSL extension. Adam pointed out that we shouldn’t be relying on a PHP extension by default because we do not know how many of our users would have it installed. He suggested me to do some research on pure PHP-based cryptography libraries and see if we can eliminate this dependency.
- Discussed yet another performance optimization technique we could employ in the module. So the architecture we built earlier for Pubkey Encrypt involves the generation of Role keys for each role present in the website. But updation of any Role key upon the updation of a role is an expensive task. So now the idea is to update Role keys for only those roles that’d be relevant for Pubkey Encrypt. Relevancy in the sense that if a website has 3 roles but is using the Role key for only 1 role, then it makes sense to not update the Role keys for the other 2 roles. Thus we thought of adding a configuration option in Pubkey Encrypt via which admins would disable any roles irrelevant for their use-case, so to enhance their website’s performance.
So my research showed that Adam’s concern was indeed legit, as extensions require the PHP engine to be compiled with them. And enabling/disabling them is done via the PHP configuration file, but most website administrators are not allowed to modify it. Though extensions, since written in binary, outperform any PHP-based code by a significant factor. I also found out about phpseclib, which is a pure PHP-based library for cryptography. But it is not as reliable as OpenSSL because it is relatively new and has hence not passed the test of time. After much confusion, I stumbled upon the fact that Pubkey Encrypt is also going to depend upon the Real AES module (currently it depends upon Encrypt Test as Real AES is under development for D8). And OpenSSL is a dependency by Real AES. Hence problem solved, as using Real AES as a module dependency automatically implies that OpenSSL would be installed and enabled.
But my mentors suggested that for experience and exposure, I should still work on removing this dependency on OpenSSL extension via a dependency on phpseclib library. Since Pubkey Encrypt has a pluggable system for these type of things, I fixed the issue by simply developing an Asymmetric Keys Generator plugin which uses phpseclib. So now we’d ship two plugin implementations for Asymmetric Keys Generator plugin type; one based on OpenSSL and the other based on phpseclib. Both the implementations would be available in the form of submodules within the Pubkey Encrypt module. And the submodules would contain instructions on how to install and use them. Have a look here at the phpseclib-based submodule I developed.
For the “Disabled Roles” feature, I simply generated a config schema and added a module settings form where the roles to be disabled by Pubkey Encrypt could be selected from the checkboxes. Then I added just one line into the module to firstly check whether a role is disabled or not before proceeding to do any Role key updates for it. In this way, we avoid the execution of this expensive operation for cases where it is unnecessary. See the relevant changes in the repo here.
