This week marks the completion of my Google Summer of Code 2016 project Pubkey Encrypt. So I’ve spent the past 3 months building this module for Drupal 8 in the supervision of mentors Adam Bergstein (@nerdstein) and Colan Schwartz (@colan). You can download Pubkey Encrypt from its official Drupal.org project page. Accordingly, the module provides a way of encrypting data with users’ login-credentials. It is based on ownCloud’s Data Encryption Model and is an attempt of providing an easy-to-use security module for website maintainers.
The way we’ve designed Pubkey Encrypt, it actually provides an API for data encryption/decryption. To use the API for encrypting field data, we recommend the usage of Field Encrypt. But a recent issue fix in that module actually made it unstable. So I dedicated this week’s work in fixing Field Encrypt.
I started by analyzing the failing test assertions in the module. Then I looked at the changelog to see which commit(s) from past exactly broke those tests. I was able to track that in a certain commit in the module, this piece of code:
if ($entity->getEntityType()->hasKey('revision')) {
$revision_id = $entity->getRevisionId();
}
else {
$revision_id = $entity->id();
}
return $revision_id;
was replaced with this just for simplification purposes:
return $entity->getRevisionId() ?: $entity->id();
But on a closer analysis it can be seen that these two code pieces are NOT equivalent. More specifically, the former can return NULL but the latter will never return NULL. This change was causing several failures in testEncryptFieldRevision(), so I corrected it with this line of code:
return $entity->getEntityType()->hasKey('revision') ? $entity->getRevisionId() : $entity->id();
This change made the code pass a few more test assertions but the classes FieldEncryptTest and FieldEncryptValueManagerTest were still failing. I was able to successfully fix those too though their discussion is not in the scope of this post. For those interested, please have a look at the patch I submitted with all the changes for fixing the module.
My mentor Colan tested the patch and found it to be working as expected. So with Field Encrypt fixed, he moved on to smoke-testing Pubkey Encrypt. He was happy with the all the progress we had made. So we moved forward to releasing a beta-version of the module. Please check it out on the official Drupal.org project page for Pubkey Encrypt.
In my weekly meeting with mentors, we discussed the scenario when a role with encrypted data is deleted. Pubkey Encrypt currently doesn’t cater to this use-case since we don’t have an exact solution for the issue at the moment. That’s because we need to hear what others have to say on this issue before finalizing a solution. So for now, we’ve decided to simply keep an issue ticket open for this:
We also discussed the GSoC project submission guidelines; we’ve decided to create a separate branch in Pubkey Encrypt github repo with all the commits made during the 3-months of GSoC coding period. We think a link to that branch would meet the aforementioned guidelines and would make it easy for anyone to figure out the work I’ve done as a GSoC participant.
Last week, I also developed an experimental OpenSSL-based encryption module for Drupal 8. But for the module, I had written the encrypt()/decrypt() implementations myself. My work so far has taught me that this is a bad practice. So I refactored the module to use the implementations provided by PHP expert Enrico Zimuel in this excellent tutorial “Encryption, Authentication & Data Integrity”. See all the relevant changes I made in this commit.
I spent the last two days of the week helping in the issues queue for other security-related Drupal 8 modules:
- Consider using a php encryption library.
- Prevent key settings from being changed too easily.
- EntityStorageException: Missing bundle for entity type node.