Though I haven't had time to develop this Jonas I will help you test it.

requested features:

• support passphrase on PGP
• store passphrase in session variable and not the database.

As a plugin would be preferable for me.

Hello, I'd be interested in helping out with this as well. I've done some high level mapping out of what all said plugin would need to do in terms of functionality and what database setup could be useful, loosely based off of the Thunderbird's Enigmail extension. I was also waiting for the plugin API to really start working on this, which if it's already available(in some form), is good to hear. Should we start a thread on the forum to map out how this could work?

-Braxton

On Mon, 27 Jul 2009 15:47:40 +0200, "Maximilien Cuony [The_Glu]" maximilien@theglu.org wrote:

Seem I can't post on the list oO ?

---

Hi,

I have, but too old to be used. Btw I'm still planing to implement the

pgp

suppoer on clientside ;)

We should use a commom base to do it btw. Wanna discuss this now ?

Regards,

On Monday 27 July 2009, Daniel Black daniel@cacert.org wrote :

...

Though I haven't had time to develop this Jonas I will help you test it.

requested features:

• support passphrase on PGP
• store passphrase in session variable and not the database.

As a plugin would be preferable for me.

-- Maximilien Cuony [The_Glu] http://theglu.org

--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/VL/cktHcvXF/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/

Hi Jonas

We would certainly appreciate a plugin-based solution for PGP support. Due lack of time we didn't start to code one ourselves but you'll get any support you need. I think some more plugin-hooks are required to make this work since encrypted message parts are currently just ignored.

One suggestion for the implementation: maybe add some abstraction layer to the backend in order to have alternatives to PECL gnupg (e.g. simple shell commands to gpg). See the password plugin for comparison.

Best regards, Thomas

Jonas wrote:

hello,

i'm new to roundcube, but i think it's a very promising project. but i really do miss a plugin which implements server-side support for gnupg/pgp encryption/decryption. searching in forum, wiki, trac, lists etc, I already found a lot of discussions regarding this issue.[1,2,3,4] many people even promised to work on this feature. some suggested to wait for the plugin api before implementing gpg/pgp support. if i got it right, the plugin api is available in the svn repository now.

everyone cc'ed in this mail stated somewhere that s/he either plans to or already did work on gpg/pgp support in roundcube.

maybe i find the time to work on this feature within the next months. but before i start, please tell me: do you have any code (maybe already using the plugin api from svn) that i could use?

my plan is to develop _serverside_ support, so both public and private key will need to be stored on the host that runs roundcube. but in the case that you're the admin of this host anyway this is not a problem at all. second,i don't want to take a usb-stick with me all the time, so serverside gpg encryption is the only option here.

and i plan to use the gnupg php library[5] instead of a gnupg library as i guess that more systems do have the gpgme library installed than the gnupg binary.

greetings, jonas

[1] http://trac.roundcube.net/ticket/1440396 [2] http://lists.roundcube.net/mail-archive/dev/2008-01/0000033.html [3] http://lists.roundcube.net/mail-archive/dev/2006-02/0000229.html [4] http://www.roundcubeforum.net/requests/491-gpg-pgp-support.html [5] http://www.php.net/manual/en/function.gnupg-sign.php _______________________________________________ List info: http://lists.roundcube.net/dev/

List info: http://lists.roundcube.net/dev/

Hello,

but i'm not sure yet whether an abstract encryption plugin with drivers for different encryption mechanisms (gpg, s/mime, ...) would be useful. i simply don't know s/mime enough, but i fear that key management etc differs to much from gnupg to create an abstract layer for both.

I want to implement gpg's features on the users side {With FireGPG}. (I personaly think it's better (storage of the private key, etc.)).

So an abstract layer whould be good as I could query the user with javascript and a specific protocol. That mean we should think about a abstract layer who can as the user (and not a server-only layer) :p

About the strucutre of this layer, we simply need (at last) 4 {6} functions: encrypt(text, keys), decrypt(text), sign (text, privatekey), verify(text). And optionnaly, {signandencrypt(text, keys, privatekey), import(text), export(key)}. For key management, if need (should we or not ?) listkey and listprivatekey too.

For the layer who manage mails, you will probably need need to:

• Decrypt an inline encrypted mail

• Decrypt an openpgp/mime encrypted mail

• Verify an inline signed mail <- this part is painfull. Realy. Every mail

client has is own logics...

• Verify an openphp/mime signed mail

• Encrypt or sign a mail in openpgp/mime standards

• Modify data of the mail to encrypt or sign it with inline.

Regards,

On Thursday 30 July 2009, Jonas Meurer jonas@freesources.org wrote :

On 27/07/2009 Braxton Ehle wrote:

...

Hello, I'd be interested in helping out with this as well. I've done some high level mapping out of what all said plugin would need to do in terms of functionality and what database setup could be useful, loosely based off of the Thunderbird's Enigmail extension. I was also waiting for the plugin API to really start working on this, which if it's already available(in some form), is good to hear. Should we start a thread on the forum to map out how this could work?

hey braxton,

great to hear that you already made some thoughts about the plugin design. have you already written down these thouhgts?

i suggest to use a wiki page for discussion about the plugin. unfortunately I seem to have no rights to create new wiki pages in the roundcube trac wiki. maybe someone could create a page with a name like 'wiki:PluginRepository/Encryption' and then we discuss any further questions there.

now back to topic, i'll try to write my thoughts down:

so far i don't know yet how to best implement the user management of gnupg. i guess that a webserver-writable directory is required that keeps secring.gpg and pubring.gpg for every roundcube user. the gnupg plugin then will set $GNUPGHOME accordingly. maybe a mysql table with user id, key id, key type (sec or pub) and key fingerprint would be useful to double-check that nobody compromised the pupring.gpg and secring.gpg files. sha256sums of the files should be stored in the db and checked at every operation as well. best would be to not make keyrings writeable to the webserver, but I don't see how to do that.

another issue is that the gnupg pecl module needs to be installed by the server admin, just like the gnupg binary. my motivation to use a php library was to make the roundcube plugin work on webspace where you neither have root access nor can request binary/library installations at all. i fear that i'll have to

i also like the idea by thomas to create a gnupg encryption plugin with support for different drivers (i.e. gnupg binary, gnupg pecl module, ...).

but i'm not sure yet whether an abstract encryption plugin with drivers for different encryption mechanisms (gpg, s/mime, ...) would be useful. i simply don't know s/mime enough, but i fear that key management etc differs to much from gnupg to create an abstract layer for both.

greetings, jonas

--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/Mv/6uNnyJbn/signature.asc Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---

hey,

On 30/07/2009 Maximilien Cuony [The_Glu] wrote:

...

but i'm not sure yet whether an abstract encryption plugin with drivers for different encryption mechanisms (gpg, s/mime, ...) would be useful. i simply don't know s/mime enough, but i fear that key management etc differs to much from gnupg to create an abstract layer for both.

I want to implement gpg's features on the users side {With FireGPG}. (I personaly think it's better (storage of the private key, etc.)).

great. i agree with you that client side key storage is more secure in many cases, but sometimes it is not an option at all. for example if people don't want to connect storage devices to public computers for security reasons. it may be more secure to trust the remote webserver than to trust the public computer. any you can use encrypted connection (https) and virtual mouse keyboards for passphrases to prevent man-in- the-middle attacks as well as keyloggers.

So an abstract layer whould be good as I could query the user with javascript and a specific protocol. That mean we should think about a abstract layer who can as the user (and not a server-only layer) :p

About the strucutre of this layer, we simply need (at last) 4 {6} functions: encrypt(text, keys), decrypt(text), sign (text, privatekey), verify(text). And optionnaly, {signandencrypt(text, keys, privatekey), import(text), export(key)}. For key management, if need (should we or not ?) listkey and listprivatekey too.

For the layer who manage mails, you will probably need need to:

• Decrypt an inline encrypted mail

• Decrypt an openpgp/mime encrypted mail

• Verify an inline signed mail <- this part is painfull. Realy. Every mail

client has is own logics...

• Verify an openphp/mime signed mail

• Encrypt or sign a mail in openpgp/mime standards

• Modify data of the mail to encrypt or sign it with inline.

yes, you're correct. that's the list of basic functions needed. if we support key management (it's needed for server-side keyring storage at least) we also would need edit(privatekey, ...), delete(key) and delete(privatekey).

and i'd like to have options to set default signing key as well as encryption/signing defaults for new mails and replies to encrypted/ signed messages.

but the real problem for me right now is rather how to manage the different roundcube users. we'd have to manage secring.gpg and pubring.gpg for every roundcube user seperately.

greetings, jonas

--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/Gy/qEXhG0Is/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,

apparently your mails to the roundcube development list don't reach the list. i don't know what's the problem. maybe you send from an address that's not subscribed to the list?

On 30/07/2009 Maximilien Cuony [The_Glu] wrote:

...

yes, you're correct. that's the list of basic functions needed. if we support key management (it's needed for server-side keyring storage at least) we also would need edit(privatekey, ...), delete(key) and delete(privatekey).

And generate() too, very important. Problem is that generate a key could be long => php's timeouts ? (Not a question but a potiental problem :P)

sure, generate() would be great, but it's not an essential feature for the plugin to be useful. for the beginning users could import secret keys.

About storing keyrings, I think files should be in the database, and only in the database, but of course that not possible for gnupg to works with that (or somebody has an idea ?). And write them on the disk just for gnupg operation won't change the problem, a deamon can watch files and read them just when gpg is executed.

from what i know, gnupg doesn't support any other backends that its own keyring files. see the thread at [1] for more information.

so only solution would be to add a mysql table with key id, mail addresses, fingerprint, etc. and check the values against the gnupg keyring data everytime gnupg is invoked. on the other hand the passphrase for roundcube mysql user is stored in a file that the webserver system user needs read access to. thus for local attackers at least, an additional mysql database is not more secure than gnupg keyring files.

remote attackers might get access to the mysql database using i.e. sql injection attacks, or they might be able to manipulate the gnupg keyring files with any kind of vulnerability in webserver applications. but for changes that the plugin doesn't recognize both attacks would be required. for the same reason i object against storing the whole keydata in a mysql database. that would just add one more place where attackers can steal sensible data from.

Btw, is a check of the database corruption usefull ? If someone has access to the files, first thing I will do is to steal private keys :P

i can think of two kinds of worst-case-attacks:

• steal private keys: i don't see a way to make this attack more difficult. apparently the webserver needs to have both write and read access to the key data. only way to weaken the impact is to urge users to use secure passwords

• manipulate key data: impossible to circumvent for the same reason. but here it's at least possible to detect attacks in some cases with the help of a database to verify key data.

greetings, jonas

[1] http://www.mail-archive.com/gnupg-users@gnupg.org/msg10169.html

--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/pm/bsjjVLFi/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 31/07/2009 till wrote:

here's the page: http://trac.roundcube.net/wiki/PluginRepository/Encryption

Does that work for you?

We had to lock down trac a bit because of the constant spam.

great, thanks a lot. i just started to fill the wiki page with thoughts that where raised in the discussion.

please add your thoughts and criticism regarding the plugin design to this wiki page.

greetings, jonas

--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/XN/MswVyDsf/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/

Hi,

apparently your mails to the roundcube development list don't reach the list. i don't know what's the problem. maybe you send from an address that's not subscribed to the list?

I seem them here : http://lists.roundcube.net/mail-archive/dev/2009-07/ . Maybe your mail client prevent to show 2 occurences of the same mail. Can someone confirm ? ;)

sure, generate() would be great, but it's not an essential feature for the plugin to be useful. for the beginning users could import secret keys.

*Arg*. You want to lets users send a _private key_, maybe with http (or with https-and-a-not-valid-certificate-as-usual-for-most-of-private-users), on the network, to a remote sever, maybe untrustable ? That again every principles of Gpg/pgp x].

• manipulate key data: impossible to circumvent for the same reason. but here it's at least possible to detect attacks in some cases with the help of a database to verify key data.

I don't agree. Is someone has access to gnupg files, he will probably have access to php files as wall, and can modify them, or at last read the mysql password and create a script to edit the database :p (as your said btw)

Regards,

On Friday 31 July 2009, Jonas Meurer jonas@freesources.org wrote :

hey,

apparently your mails to the roundcube development list don't reach the list. i don't know what's the problem. maybe you send from an address that's not subscribed to the list?

On 30/07/2009 Maximilien Cuony [The_Glu] wrote:

...

...

yes, you're correct. that's the list of basic functions needed. if we support key management (it's needed for server-side keyring storage at least) we also would need edit(privatekey, ...), delete(key) and delete(privatekey).

And generate() too, very important. Problem is that generate a key could be long => php's timeouts ? (Not a question but a potiental problem :P)

sure, generate() would be great, but it's not an essential feature for the plugin to be useful. for the beginning users could import secret keys.

...

About storing keyrings, I think files should be in the database, and only in the database, but of course that not possible for gnupg to works with that (or somebody has an idea ?). And write them on the disk just for gnupg operation won't change the problem, a deamon can watch files and read them just when gpg is executed.

from what i know, gnupg doesn't support any other backends that its own keyring files. see the thread at [1] for more information.

so only solution would be to add a mysql table with key id, mail addresses, fingerprint, etc. and check the values against the gnupg keyring data everytime gnupg is invoked. on the other hand the passphrase for roundcube mysql user is stored in a file that the webserver system user needs read access to. thus for local attackers at least, an additional mysql database is not more secure than gnupg keyring files.

remote attackers might get access to the mysql database using i.e. sql injection attacks, or they might be able to manipulate the gnupg keyring files with any kind of vulnerability in webserver applications. but for changes that the plugin doesn't recognize both attacks would be required. for the same reason i object against storing the whole keydata in a mysql database. that would just add one more place where attackers can steal sensible data from.

...

Btw, is a check of the database corruption usefull ? If someone has access to the files, first thing I will do is to steal private keys :P

i can think of two kinds of worst-case-attacks:

• steal private keys: i don't see a way to make this attack more difficult. apparently the webserver needs to have both write and read access to the key data. only way to weaken the impact is to urge users to use secure passwords

• manipulate key data: impossible to circumvent for the same reason. but here it's at least possible to detect attacks in some cases with the help of a database to verify key data.

greetings, jonas

[1] http://www.mail-archive.com/gnupg-users@gnupg.org/msg10169.html

--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/pm/bsjjVLFi/signature.asc Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---

hey,

On 31/07/2009 Daniel Black wrote:

to the wiki i've added:

• added a abstraction layer for storage to deal with future client side

storage in mind.

• s/mime should be possible with the same interface(s). just needs some

function to differentiate s/mime/pgp at the start and pass it through the right way.

that would be great, but i don't know much about s/mime. so if you know the interface, maybe you could help with writing a s/mime driver for the encryption plugin once the core work is done. best would be to support all encryption systems in parallel.

• also put in some basic key lookup interfaces.

that would be very useful as well. but it requires keyservers to be configured, and one could argue that users should be able to manage keyserver lists as well.

As far as the general roundcube plugin API goes perhaps plugins can register to handle mime types they want to process (the various gpg/pgp mime types for signing/encryption and keys). This may also simplify the current vcard_attachments plugin.

i didn't look into mime type handling at roundcube code yet, but that would simplify mail processing a lot, yes. on the other hand maximilian already mentioned that detecting inline signed gpg mails is a pain, so that one will be more complicated.

greetings, jonas

--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/Mw/VvfybjnX/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/

Hi,

i didn't look into mime type handling at roundcube code yet, but that would simplify mail processing a lot, yes. on the other hand maximilian already mentioned that detecting inline signed gpg mails is a pain, so that one will be more complicated.

No, detecting them are easy, the problem is to get the orginal text as signed. What a <br /> mean ? \r, \n, \n\r ? How should ww handle non-ascii characters ? Etc.

Btw, to work on the plugin we should have a svn repository or something like that, I think than more than one person want to works on it ;). How can we do that ?

Regards,

On Friday 31 July 2009, Jonas Meurer jonas@freesources.org wrote :

hey,

On 31/07/2009 Daniel Black wrote:

...

to the wiki i've added:

• added a abstraction layer for storage to deal with future client side

storage in mind.

• s/mime should be possible with the same interface(s). just needs some

function to differentiate s/mime/pgp at the start and pass it through the right way.

that would be great, but i don't know much about s/mime. so if you know the interface, maybe you could help with writing a s/mime driver for the encryption plugin once the core work is done. best would be to support all encryption systems in parallel.

...

• also put in some basic key lookup interfaces.

that would be very useful as well. but it requires keyservers to be configured, and one could argue that users should be able to manage keyserver lists as well.

...

As far as the general roundcube plugin API goes perhaps plugins can register to handle mime types they want to process (the various gpg/pgp mime types for signing/encryption and keys). This may also simplify the current vcard_attachments plugin.

i didn't look into mime type handling at roundcube code yet, but that would simplify mail processing a lot, yes. on the other hand maximilian already mentioned that detecting inline signed gpg mails is a pain, so that one will be more complicated.

greetings, jonas

--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/Mw/VvfybjnX/signature.asc Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---

On Fri, Jul 31, 2009 at 2:17 PM, Jonas Meurerjonas@freesources.org wrote:

On 31/07/2009 Maximilien Cuony [The_Glu] wrote:

...

Btw, to work on the plugin we should have a svn repository or something like that, I think than more than one person want to works on it ;). How can we do that ?

maybe we could get write access to svn.roundcube.net. otherwise i could add a repository for the plugin at svn.freesources.org.

greetings,  jonas

Maybe you guys can use SF, Github, Google Code or the like? All established, etc.. It would def. be easier/faster for you to get started. :-)

Till _______________________________________________ List info: http://lists.roundcube.net/dev/

hey again,

On 29/07/2009 Thomas Bruederli wrote:

We would certainly appreciate a plugin-based solution for PGP support. Due lack of time we didn't start to code one ourselves but you'll get any support you need. I think some more plugin-hooks are required to make this work since encrypted message parts are currently just ignored.

after reading parts of roundcube code (especially rcube_message.php) several times and thinking about the possibilities to implement a crypt plugin here are my current ideas:

i guess it will be very hard to implement a plugin that adds full support for encrypted and signed messages to roundcube. the reason is, that rcube_message.php already does a lot of message/mime parsing, and i doubt that there's _one_ best place in parse_structure() where potentially encrypted and/or signed message could be given to the plugin via hook. that's due to the reason that messages with encrypted and/or signed parts could have any possible structure, with or without mime parts, with or without attachments and so on.

so from what i see now, the plugin would have to parse messages the following way:

func parse_mime(mime_part): if (Content-Type == multipart/mixed): foreach($mime_parts as $part): parse_mime(mime_part) else if (Content-Type == multipart/encrypted): decrypt_mime(mime_part_2) else if (Content-Type == multipart/signed): verify_mime(mime_part_1, mime_part_2) else if (Content-Disposition contains 'attachment'): if (Content-Type contains 'pgp'): parse_mime_attachment(mime_part)

func parse_attachment(mime_part): if (Content-Transfer-Encoding == 'base64'): attachment = convert_from_base64(mime_part) else if (Content-Transfer-Encoding == 'quoted-printable'): attachment= convert_from_QP(mime_part) decrypt(attachment)

func parse_inline(msg): if (msg contains 'BEGIN PGP MESSAGE'): crypt_msg = grep_inline_crypt_msg(msg) decrypt_inline(crypt_msg) if (msg contains 'BEGIN PGP SIGNED MESSAGE'): signed_msg = grep_inline_signed_msg(msg) verify_inline(signed_msg)

if (mime_message): parse_mime(msg) else: parse_inline(msg)

as you can see a lot of this parsing is already implemented in roundcube [rcube_message.php / parse_structure()]. thus we either would have to reinvent the wheel in the crypt plugin, or add lots of additional hooks.

as both are not clean solutions, i see two solutions:

(1) redesign the whole message parsing code from roundcube or (2) implement the missing parsing code to detect and isolate encrypted and/or signed messages/attachments, regardless whether they're inline or mime, and only give the pure encrypted/signed text/attachment/whatever to the plugin.

i would highly appreciate comments on that thoughts :-)

greetings, jonas

--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/q9/h3g6iWvS/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/

On 07/08/2009 Maximilien Cuony [The_Glu] wrote:

I'm for the second solution. As roundcube already handle encrypted mail (to display an error), why not patch the core who, if an encryption plugin is available, use it ?

ok, but i suggest to implement it the following way:

at the very start of parse_structure(), parse the message/mime_part for encrypted/signed content (both mime and inline), if appropriative verify signature or decrypt encrypted data, and send the result back to a new instance of parse_structure() recursively. afterwards stop the functions.

i.e.

function parse_structure($structure, $recursive = false) { $message_ctype_primary = strtolower($structure->ctype_primary); $message_ctype_secondary = strtolower($structure->ctype_secondary); if (is_signed($structure)) { $structure_new = verify($structure); parse_structure($structure_new, true); return; else if (is_encrypted($structure)) { $structure_new = decrypt($structure); parse_structure($structure_new, true); return; }

[ rest of parse_structure() ]

[ handle encrypted attachments later ]

}

in my eyes that is the most elegant way to support wrapped mime parts/signatures etc. inside encrypted messages. i.e. one could receive an encrypted message with the following structure:

Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary="foobar" Content-Disposition: inline

--foobar Content-Type: application/pgp-encrypted Content-Disposition: attachment

Version: 1

--foobar Content-Type: application/octet-stream Content-Disposition: inline; filename="msg.asc"

-----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.9 (GNU/Linux)

[...] -----END PGP MESSAGE-----

--foobar--

and the encrypted msg.asc then contains the following structure:

Content-Type: multipart/mixed; boundary="barfoo"

--barfoo Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit

[some text message]

--barfoo Content-Type: message/rfc822 MIME-Version: 1.0

[lot's of headers] Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

[some html message]

--barfoo Content-Type: message/rfc822 MIME-Version: 1.0

[lot's of headers] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit

[some second text message] --barfoo--

greetings, jonas

--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/r3/jkxEhCoZ/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/

On 07/08/2009 A.L.E.C wrote:

Jonas Meurer wrote:

...

at the very start of parse_structure(), parse the message/mime_part for encrypted/signed content (both mime and inline), if appropriative verify signature or decrypt encrypted data, and send the result back to a new instance of parse_structure() recursively. afterwards stop the functions.

Just a thought. Attach a few samples of simple messages, crypted (with decrypted version) and signed, to the Wiki page, please. This would be simpler to understand without reading RFCs and installing encryption software.

sure, just did that. please note that i always uploaded the same messages twice: one version signed and one encrypted. that way I didn't have to upload the decrypted message as well, as it's exactly the same content as the same message.

particularly interesting are the wrapped multipart messages, with attachments and with several mails wrapped inside:

http://trac.roundcube.net/attachment/wiki/PluginRepository/Encryption/plain_... http://trac.roundcube.net/attachment/wiki/PluginRepository/Encryption/multip...

if nobody objects, i'll start to implement the code in parse_structure() in rcube_message.php:

function parse_structure(): if is_encrypted(msg_part): dec_msg_part = exec_hook(decrypt, ...) parse_structure(msg_part) return if is_signed(msg_part): verify = exec_hook(verify, ...) parse_structure(msg_part_part2) return ...

greetings, jonas

--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/t3/6mjjkaOE/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/

Hi!

On Sat, 29 Aug 2009 04:57:17 +0200, Jonas Meurer jonas@freesources.org wrote:

hey again,

last but not least: the reason why i didn't commit the code i wrote to a svn repository so far is merely that i don't consider the code useful yet. it contains thousands of (mostly commented out) console() calls which help me to visualize the dataflow. appart from that the only thing that's working already is verification of signatures for pgp inline mails :-/

Didn't you consider using a remote debugger? Personally I prefer Zend's one to xdebug. It could be a bit tricky to setup it, but it dramatically simplifies development. You can contact me personally if you have problems with it, I'd help.

PGP / S/MIME support is a must have, so please don't stop :)

Best, Vladislav

List info: http://lists.roundcube.net/dev/

Jonas Meurer wrote:

On 29/08/2009 Jonas Meurer wrote:

...

the PGP plugin needs access to the raw content of mime parts. verify_mime() requires the _exact_ raw content, not a stripped down, parsed or otherwise modified version. this is not possible yet. $this->get_part_content($mime_id) from rcube_message.php, and even iil_C_HandlePartBody($this->conn, $this->mailbox, $uid, true, $part) from rcube_imap.php give back stripped down versions of the content. i wonder whether it's possible to access the raw content at all.

looked into that issue today and finally discovered that the way roundcube mime parsing code doesn't support to fetch raw content of mime parts.

Sure it does. There's also a step that displays the raw message code in the browser. You can use $RCMAIL->imap->get_raw_body($uid) to fetch the message source.

For decoding the message structure without the support of the IMAP server we do not have a solution yet but there are some other problems that would require such a feature. After the 0.3 release I'll have a look into that.

~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/

On 10.08.2009 02:55, Jonas Meurer wrote:

...

Just a thought. Attach a few samples of simple messages, crypted (with decrypted version) and signed, to the Wiki page, please.

sure, just did that.

It was long time ago, but maybe there's a chance to get also the public key for these messages?

if nobody objects, i'll start to implement the code in parse_structure() in rcube_message.php:

Anyone is working on this plugin?