search

C3S / redmine_openpgp

Redmine plugin for email encryption with the OpenPGP standard
GNU General Public License v3.0
19 stars 10 forks source link

Issues with passphrases on the key #3

Open ageis opened 9 years ago

ageis commented 9 years ago

After setting up the plugin, e-mails (both incoming and outgoing) were not working. I checked the log and found Email delivery error: Bad passphrase.

I'd used the same key and passphrase from the beginning, passing it in as the secret to the update_redmine_pgpkey task.

I manually edited the secret key in www-data's keyring and reset the passphrase (it was NOT actually changed) and exported. I ran the update task again, using the same value. Outgoing e-mail notifications started to work again.

Incoming e-mails still didn't work. I had seen the note earlier about the incompatibility with GnuPG 2.0.x, and learned that the hard way by manually running my redmine:email:receive_imap cron task and receiving a curses passphrase prompt. So gpg2 was symlinked to gpg. But the server still wasn't decrypting...

Removing the passphrase from the key entirely, and passing in an empty secret variable, resolved the issue.

I'm pretty confident about the entry and consistency of my passphrase being accurate, so this suggests there is some bugginess with gpgme and passphrases in the plugin. It doesn't make sense that encryption would work but not decryption.

In any event, having a passphrase on a key like this is only marginally useful - ex. if you're afraid of the key being copied and used elsewhere, and efforts should be focused on securing the server instead. It would be useful for your docs to include some discussion of the advantages and disadvantages of having a passphrase on the key, because I'm pretty sure the plugin seems to work better without one.

ageis commented 9 years ago

Also, hypothetically, would using a passphrase-less key make the plugin compatible with GnuPG 2.0.x?

fmgborg commented 9 years ago

The newer gpg2 is quite different from the legacy gpg, thus some effort to make it work may be expected. One setup is to remove gpg2 completely, e.g.:

aptitude remove ecryptfs-utils # libecryptfs0{u} libtspi1{u} aptitude remove mutt aptitude remove libgpgme11 aptitude remove gnupg2

If gpg2 is needed, you might encapsulate webserver/redmine inside a chroot environment or some virtualization (lxc, xen, kvm, not sure about docker).

timegrid commented 9 years ago

If you have imported the private key using one the provided ways (e.g. the rake tasks), there's also a check on the password. If the password is wrong, the key should not have been imported and you should get an error. So, the password should not be the problem here.

There's a good chance, that the Bad Passphrase error was caused by the gpg 2.0 problem. Especially, IF encryption works, but decryption not, it may be exactly the pinentry problem, as encryption does not need entering any passphrase.

Are you sure, that /usr/bin/gpg2 --version results in gpg (GnuPG) 1.4.XX?

There's an almost easy way, to check. I assume you have configured incoming emails for redmine. If you preserve copies of the incoming emails as textfiles, you may just pipe one of them into the rdm-mailhandler.rb script again. If there's still a problem with gpg, pinentry shows up.

Still I can't imagine, why outgoing mails were affected in the beginning. Maybe it had also to do with the wrong key ring in #1 ?

As far as I remember using an empty passphrase should be fine with gpg 2.0. This would also point towards the gpg 2.0 problem here. I'll add a note to the readme.

You are right concerning the usefulness of the passphrase, it is only marginal. If someone hacks into the server and has access to the private key, he needs at least the rights of the user owning the redmine process. Having this rights, he may also get the passphrase by accessing the database. But he needs to know, that he is able to. On the other side, there may be usecases, where the same private key may be used elsewhere and therefore needs password protection. Therefore I don't want to prevent users from using one.

There may even be a misconfiguration of the server listing the .gnupg folder, where password protection would be handy, but this is almost not a point - although, have you checked /var/www/.gnupg? :)

timegrid commented 9 years ago

@ageis Sorry for you having to learn it the hard way, by the way. I added a proper description of the problem and symptoms.

@fmgborg thanks for the commands, i added a reference to your comment in the readme