Email attachments don't get encrypted about rc_openpgpjs

[niklasfemerstrand]

Yup, this has been left out intentionally due to some missing hooks in Roundcube which would allow this behavior on the client side. This is definitely intended to be implemented at a later stage. Thomas said the following here:

"* There's no encryption for attachments. I know, this is hard or almost
impossible to implement on the client but it's a serious lack of feature.
We might consider to implement hooks that'll let you read attachment
contents back to the client in order to encrypt them."

It might be possible to hijack the existing function that is used to upload to encrypt the contents before the attachment is posted, I haven't looked at it that much yet. Expect this feature to be available in the future though :-)

[quemquis]

Hi,

I just wanted to second sysmonk's point that nowadays email encryption is pretty useless without attachment encryption.
I know this is not so easy to implement but it has been done. Check out http://kerry-linux.ie/wee-mail/ for a working example of roundcube integration with attachment encryption.

I really hope this is a priority issue since it is so important for security conscious users.

Thanks and keep up the good work.

[niklasfemerstrand]

Impatient security conscious users can always encrypt their attachments using local GPG/similar installations instead, or submit a patch if my prio is somehow out of order. However Roundcube needs to be patched first, as explained in my first comment for this issue.

The WEE mail thing that you linked appears to be a PHP PGP implementation which is an instant no. rc_openpgpjs performs client sided crypto for security reasons, which WEE mail violates by performing crypto actions on the server. If I have missed or misunderstood it please point me in the correct direction and I'll have a look.

Basically: server sided crypto is broken by design. rc_openpgpjs will for security reasons never allow the server to touch private keys. rc_openpgpjs will have support for encrypted attachment at a later stage, at the current early beta there are more important things to be done first.

One way could be to send the pubkeys of recipients along with the attachment and let the server encrypt the attachment before sending it to the recipient. I don't like that solution since it would disrupt the clean plugin backend. And also it could cause problems where recipients are added after the attachment has been encrypted and so forth. It's a risky road with many potential bugs. I'm sure we can work out a better clean solution in JavaScript with the Roundcube developers once that stage is reached and that way retain client side consistency.

Either way I'm willing to apply patches for a working solution as long as it's secure enough to be considered temporary, unless the received patch is actually written the way that fits the project agenda. In that case there's no questions asked and of course the feature would be put in. I won't write an insecure solution or allow insecure solutions merged though. We need to keep to the standard.

[niklasfemerstrand]

Duplicate of #20