After installing, I checked my database and none of the email addresses in the users-table was encrypted. The dbee_init and dbee_mail columns were also empty. The database column descriptions are altered correctly: "User’s encrypted e-mail address.". The configuration form on admin/config/system/dbee however tells me that "All email addresses are encrypted now", but they obviously aren't.

The install hook does mention "Encrypt all exisiting email adresses of the user table." but I can't find anything that will do that.

AES was already fully configures as we're using encrypted_files too.

CommentFileSizeAuthor
#8 dbee-drush-check-2393517-8.patch851 bytesmrharolda
#8 dbee-no-access-check-2393517-8.patch2.91 KBmrharolda

Comments

mrharolda’s picture

mrharolda commented

I fixed it by altering the AES settings, and then setting it back as it was, but that's not how this module should behave ...

thedut’s picture

thedut commented
Assigned: Unassigned » thedut
Status: Active » Closed (cannot reproduce)

Hello MrHaroldA,

Thank you for reporting this issue.
I'm glab you finally succeed in using the Database Email Encryption (dbee) module. And you are right, that's not how this module should behave : emails should be encrypted on installing the module.

I can't reproduce this issue.
I tried with :

  • Drupal 7.34
  • Aes module 7.x-1.8
  • dbee module 7.x-2.0
  • with aes not enabled (installing aes and dbee together)
  • with aes enabled, set to database encryption key, then installing dbee
  • with aes enabled, set to file encryption key, then installing dbee (the situation you met)

Test units succeed to.

About debuging :

The install hook does mention "Encrypt all exisiting email adresses of the user table." but I can't find anything that will do that.

On the 'admin/config/system/dbee' page : This sentence is always displayed : there is no check about email encryption.
If you want to make sure about email encryption, look into the database (as you did) or go to the user/1 (or any user) page with the 'Administer database email encryption' permission : look for the 'Contact email' section : it will display if the email is encrypted or not.

Regarding what you describe, it seems that the hook_enable() function was not called on install (but it should be called).

Anyway, when enabling the dbee module or making changes on the AES admin setting page (as you did), all users are encrypted again. That why you finally succeed in encrypting all users.

I close this issue but feel free to re open it if you or someone meet this issue again.

mrharolda’s picture

mrharolda commented

I've used drush to enable the modules. I'll try to reproduce it tomorrow, and test enabling it with features too, as I have to deploy this anyway...

thedut’s picture

thedut commented

Hello,

I did not try to reproduce this issue enabling the module using drush.
I may find the cause of this issue thanks to the Drupal API documentation for the hook_enable() function :
The dbee_enable() function is stored into the dbee.module file, but I should be stored into the dbee.install file instead.
Could you test if it solves your issue ?

thedut’s picture

thedut commented
Status: Closed (cannot reproduce) » Active
mrharolda’s picture

mrharolda commented

Well, I think it's actually an other problem. Drush runs as user 0, aka 'anonymous'. In dbee_update_crypt_all() there's this access check:

if (user_access('administer database email encryption') || user_access('administer aes') || user_access('administer modules')) {

That check seems out-of-place, as the only way to trigger a full en/decrypt is by enabling/disabling the module, or changing AES settings. All these actions call for administration permissions, server access, or the dreadful php-filter enabled (which is the biggest security hole of 'em all!).

You could argue that this is a 'security feature', but is someone has server access, you're fully hacked anyway as they will also have access to the decryption key, php, database, etc.

To enable Drush support, this check has to go, or has to be extended with something like this:

$user_access = user_access('administer database email encryption') || user_access('administer aes') || user_access('administer modules');
$drush = drupal_is_cli() && function_exists('drush_log');

if ($user_access || $drush) {
mrharolda’s picture

mrharolda commented
Status: Active » Needs work

Needless to say, our deploy failed too as the module can't be enabled by a feature that is reverted from Drush/CLI/Jenkins/etc.

mrharolda’s picture

mrharolda commented
Status: Needs work » Needs review
StatusFileSize
new dbee-no-access-check-2393517-8.patch2.91 KB
new dbee-drush-check-2393517-8.patch851 bytes

Here are 2 patches: one that removes the access check, and one that adds the Drush check.

I prefer to remove the access check.

thedut’s picture

thedut commented
Title: Email addresses not encrypted after install » Email addresses not encrypted after install with Drush

  • thedut committed 620353b on 7.x-2.x authored by MrHaroldA 
    Issue #2393517 by MrHaroldA: Email addresses not encrypted after install...
thedut’s picture

thedut commented
Status: Needs review » Fixed

I agree with you : I have removed the access check (I have used this patch : dbee-no-access-check-2393517-8.patch).
Thank you MrHaroldA for your contribution on the DaBase Email Encryption module.

thedut’s picture

thedut commented

Fixed into the dbee 7.x-2.1 version.

thedut’s picture

thedut commented
Status: Fixed » Closed (fixed)