Attachment encryption and decryption

[niklasfemerstrand]

Quoting Thomas Bruederli:

Decryption of encrypted messages is only possible on messages sent with
text/plain but not with multipart/encrypted. This is mainly because
Roundcube doesn't even send the encrypted body parts to the client.
Solution: there are plugin hooks in PHP available [2] to grab encrypted
parts from the message structure and make sure they're sent to the client.
Attachment decryption is also consider here.

[2] http://trac.roundcube.net/wiki/Plugin_Hooks#message_part_structure

[krautsource]

Hey,
I gave the decryption of attachments some thought, hacked a few lines of code together and ran a couple of tests with not-so-bad results.
This is what I came up with so far (maybe there's a better way, but this is how I addressed this)...
My code currently only works on messages with all attachments encrypted one by one as separate message parts, i.e. all encrypted file attachments show up in the attachment list as .pgp files.
In message view, my JS code checks this list for attachments with a ".pgp" file extension and overwrites their onclick handlers with a custom handler. Upon a mouse click on a PGP attachment link, this custom handler retrieves the attachment in the background, feeds it into openpgp's decryption method, builds a data URI containing the decrypted data and directs the browser to that URI so the user can open/save it as a file.
However, due to restrictions of the data URI scheme, it's not possible to specify a filename for the browser's "save as" dialogue. Also, in the data URI we should specify a proper mime type for the decrypted data, which probably must be deducted from the original file's file extension. This means we have to keep a hardcoded list of extension -> mimetype mappings somewhere. (I browsed the Roundcube code for a more elegant mechanism we could employ, but Roundcube's mime detection mainly relies on sniffing the file's contents which is probably not what we want.)

One problem I encountered and how I evaded it was this (just so you might propose a better / more elegant solution):
Retrieving binary content (such as a .pgp file) using AJAX seems to be trickier than I thought. Depending on the page's charset, the browser tends to mess things up before the server response is available to the Javascript code. There are workarounds like forcing the browser to use "text/plain; charset=x-user-defined" as a mime type, but that didn't completely do the trick for me and seems to be browser dependent.
So I wrote a server-side hook in PHP for the "message_part_get" action which is called every time the user downloads an attachment. The hook handler checks if the requested attachment happens to be a .pgp file and if so, base64-encodes it prior to returning it to the browser. That way, the JS code can issue a standard jQuery.ajax call to Roundcube's standard attachment download URL, base64-decode the response and decrypt it using openpgp.js.

One more thing I'd have to look into is a better way to inject the decryption handler in the attachment onclick event, like creating a hook instead of just overwriting the <a> element's onlick attribute. I already had a look at that, but this needs some more experimenting.

If there's interest, I'd spend some more time on all this and provide a patch...

Discuss :-)

[jseidl]

I'm interested on following with that. Attachment support is a great thing. Can you send me your updates so I can take a look? Thanks!

[krautsource]

Can you send me your updates so I can take a look?

I'll have to search the modifications specific to this issue, it's been some time... probably won't get around to doing this until the end of the week, sorry. Remind me if I don't get back to you until Sunday :-)

[tkk-3636]

have any progress been made reagarding attachments encryption? kindly update regarding this