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.
i'll try to list all showstoppers that i discovered so far ...
the plugin needs access to the raw message body in order to verify signatures
inline pgp signed/encrypted messages have to be detected and handed over to a hook in function parse_structure() at rcube_messsage.php
verifying signed messages and decrypting encrypted messages needs to be done by seperate hooks: message_part_signed and message_part_encrypted
i tried to adress these with the attached patch. please review and comment on it. it would be awesome if it could be integrated upstream later.
unfortunately there s one big issue left which my patch doesn't adress yet. the reason is simply that i don't have a clue about what to do about it. i would highly appreciate help from roundcube core developers here :-)
read a text string (i.e. a decrypted message) into a mime parser and return mime structure and mime parts. mime parsing is closely combined with the IMAP code in roundcube. the mime parsing is done by the IMAP server and roundcube fetches structure and parts from it. so far there's no way to process a text string with mime parsing code. unfortunately that's required for processing encrypted messages, as the decrypted, possibly mime-formated message is only available as text string.
i don't know how it's done for composed/sent messages, but i guess that their structure needs to be parsed as well in order to upload them to a send/drafts/... folder.
greetings, jonas
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/YT/kce4cTdE/rcube_message.php.diff http://detached.gigo.com/rc/YT/kce4cTdE/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/
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.
Just my 2c about patch. It would be great if all detection of inline ---SIGNED--- and ---ENCRYPTED--- messages is moved to hooks. Thus we can implement both S/MIME and PGP support as pure plugins without RC core even knows about possible encryption mechs.
Vladislav _______________________________________________ List info: http://lists.roundcube.net/dev/
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.
- Not complete and not working get_raw_body_content()
- 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. 3. What with application/pgp part? You've removed this code block.
- 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.
Mmmm... But what about memory usage? Encrypted/signed message could be rather big. And we could hit PHP memory limit easily. I'd prefer some kind of stream-operating parser/detector therefore.
Vladislav
List info: http://lists.roundcube.net/dev/
Vladislav Bogdanov wrote:
- 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.
Mmmm... But what about memory usage? Encrypted/signed message could be rather big. And we could hit PHP memory limit easily. I'd prefer some kind of stream-operating parser/detector therefore.
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.
On 08/10/2009 Vladislav Bogdanov 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.
Just my 2c about patch. It would be great if all detection of inline ---SIGNED--- and ---ENCRYPTED--- messages is moved to hooks. Thus we can implement both S/MIME and PGP support as pure plugins without RC core even knows about possible encryption mechs.
in other words, the message is given to the crypt hook at beginning of parse_structure(), and the plugin does all parsing for encryption and/or signing?
i understand your argument, but the drawback is that mime parsing needs to be reimplemented in the plugin. for example openpgp/mime encoded mails may contain encrypted and unencrypted parts, and possibly encrypted parts then again may contain random new (mime) parts.
the plugin code would need to parse all mime parts of the message for encryption and/or signatures, decrypt and/or verify accordingly and fill $part->body with the result. pase_structure() then should check for set $part->body everytime before fetching the message body content from the IMAP server.
i'm happy to implement it that way in parse_structure() in case we agree on this implementation.
greetings, jonas
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/Af/SfxFaKl4/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/
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.
- 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.
- 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.
- 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/
Just my 2c about patch. It would be great if all detection of inline ---SIGNED--- and ---ENCRYPTED--- messages is moved to hooks. Thus we can implement both S/MIME and PGP support as pure plugins without RC core even knows about possible encryption mechs.
in other words, the message is given to the crypt hook at beginning of parse_structure(), and the plugin does all parsing for encryption and/or signing?
No, I meant that plugin should somehow (with that regext f.e.) detect that message is encrypted/signed with appropriate mech and inform core that it should be processed in a specific way.
i understand your argument, but the drawback is that mime parsing needs to be reimplemented in the plugin. for example openpgp/mime encoded mails may contain encrypted and unencrypted parts, and possibly encrypted parts then again may contain random new (mime) parts.
the plugin code would need to parse all mime parts of the message for encryption and/or signatures, decrypt and/or verify accordingly and fill $part->body with the result. pase_structure() then should check for set $part->body everytime before fetching the message body content from the IMAP server.
i'm happy to implement it that way in parse_structure() in case we agree on this implementation.
List info: http://lists.roundcube.net/dev/
On Thursday 08 October 2009 15:43:49 Vladislav Bogdanov 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.
Just my 2c about patch. It would be great if all detection of inline ---SIGNED--- and ---ENCRYPTED--- messages is moved to hooks. Thus we can implement both S/MIME and PGP support as pure plugins without RC core even knows about possible encryption mechs.
S/MIME signatures as encryption don't work on --SIGNED--/--ENCRYPTED-- as they are pure mime parts of the message.
As below other PGP siging/encryption are also mime parts. I was thinking a generic mime type handling API could work.
An plugin registers and says I handle content type P with fields X=Z. This could allow image display, vcal and other attachments.
pgp sign: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp- signature";
pgp encrypt: Content-Type: multipart/encrypted; protocol="application/pgp-encrypted";
s/mime sign: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1;
s/mime encrypt: Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data;
I'm sure the IANA has a better source of information than this.
I even thought inline-pgp was getting to be far less common and maybe not worth dealing with.
Jonas Meurer wrote:
- 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.
Let's see:
public function get_raw_body_content() { return $this->imap->get_message_part($this->uid, $mime_id, 'TEXT', NULL, $fp); }
Ok, maybe it's working, but you should call get_message_part in this way:
$this->imap->get_message_part($this->uid);
Now, for performance, maybe it's possible to use 3rd argument of this function? Also if we call it with only one argument, do we need this get_raw_body_content wrapper?
- 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?
Something like that. Or create rcube_message::cache array and store fetched part bodies by uid and mime_id in it. This will probably require checking for allowed memory size.
As someone said, do we need to deal with inline signed/encrypted messages? Maybe it would be simpler to start with only MIME messages handling?
As someone said, do we need to deal with inline signed/encrypted messages? Maybe it would be simpler to start with only MIME messages handling?
Some people are using it because they can't send mail in the right format and just clearsign they messages, I think Roundube should support everyone ;)
Regards,
On Friday 09 October 2009, "A.L.E.C" alec@alec.pl wrote :
Jonas Meurer wrote:
- 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.
Let's see:
public function get_raw_body_content() { return $this->imap->get_message_part($this->uid, $mime_id, 'TEXT', NULL, $fp); }
Ok, maybe it's working, but you should call get_message_part in this way:
$this->imap->get_message_part($this->uid);
Now, for performance, maybe it's possible to use 3rd argument of this function? Also if we call it with only one argument, do we need this get_raw_body_content wrapper?
- 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?
Something like that. Or create rcube_message::cache array and store fetched part bodies by uid and mime_id in it. This will probably require checking for allowed memory size.
As someone said, do we need to deal with inline signed/encrypted messages? Maybe it would be simpler to start with only MIME messages handling?
On Friday 09 October 2009 20:04:24 Maximilien Cuony [The_Glu] wrote:
As someone said, do we need to deal with inline signed/encrypted messages? Maybe it would be simpler to start with only MIME messages handling?
Some people are using it because they can't send mail in the right format and just clearsign they messages, I think Roundube should support everyone ;)
How about treat inline pgp messages as a fake mime types for the purposes of plugins as one special case in the RC core?
-
A.L.E.C -
Daniel Black -
Jonas Meurer -
Maximilien Cuony [The_Glu] -
Vladislav Bogdanov