hey, On 08/10/2009 A.L.E.C wrote: > Jonas Meurer wrote: > > hello, > > > > i already wrote about developing a crypt/gpg plugin for roundcube to > > this list in the past. in my eyes several issues need to be adressed > > in roundcube core before it's possible to implement the plugin itself. > > 1. Not complete and not working get_raw_body_content()
can you elaborate on that? in my tests get_raw_body_content() indeed worked as expected. it results the whole body content, without any charset or mime parsing modifications applied. > 2. You're fetching text message body twice for checking if inline > message/part is signed/encrypted. This is of course not good for > performance, you should store fetched body in memory for further use > (e.g. by extending get_part_content function). It will be used probably > once again in plugin and again for message displaying. you mean that get_part_content should store the body content in part->body in case it's obligated to do so? On 08/10/2009 A.L.E.C wrote: > Maybe use SEARCH instead: > > s SEARCH UID XXX BODY "-----BEGIN PGP MESSAGE-----" > > but this is not the same as regular expression. One way or another we'll > need to fetch the body for display. Maybe we should handle message > bodies via (cache) files. i don't know nothing about cache files, but i guess they cannot easily be modifies. but the crypt plugin would need to replace encrypted parts with the decrypted ones. i guess the following would be best: at any time roundcube code should check for part->body being set before fetching the body from IMAP server. in case that part->body is set, this should be used instead. plugins then can easily manipulate the message part content and save the result to part->body. they'll have to reset header/mime structure accordingly though, otherwise the header/mime structure doesn't reflect the actual content of part->body anymore. therefore modifications to message, header and part structure are required once the body is modified, and new parts need to be integrated into the message and header structure smoothly. in other words the class rcube_message needs to be extended. > 3. What with application/pgp part? You've removed this code block. i simply don't understand the purpose of this code. the comment is misleading, it talks about "pgp signed messages" while the code actually checks discouraged and obsolete mime type "application/pgp". this has been withdrawn and replaced by "application/pgp-signature", "application/pgp-encryption" and "application/pgp-key". in fact "application/pgp" is not mentioned in any RFC. see introduction of RFC 3156 for example: http://www.faqs.org/rfcs/rfc3156.html greetings, jonas --- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/Yr/EwhUthfg/signature.asc Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
_______________________________________________ List info: http://lists.roundcube.net/dev/
