I noticed that support for GPG/PGP encryption was on the RoundCube roadmap as a planned feature. I, for one, think this would be an awesome feature to have in a webmail client. It does bring up some issues with storing private keys for signing purposes. I guess users would just have to trust their webmail provider with securing their private keys.
One possibility would be to implement the feature in two phases: message encryption first since it relies on public keys only and then message signing which relies on private keys. This project is abandoned http://freshmeat.net/projects/openpgpwebmail/ but might be able to be gutted and reused for the message encryption portion of the problem. It looks like it's under the GNU GPL just as RoundCube is so using code from it shouldn't be a problem.
If I get some time I may try and see if I can graft some GPG/PGP features in to RoundCube. My initial idea would be to make these features dependent on GnuPG. Thoughts?
-- Bradley Holt
Sorry, should have thought of this as well in my first e-mail: http://pecl.php.net/package/gnupg. Thoughts on relying on PECL packages?
-- Bradley Holt
On 2/15/06, Bradley Holt bradley.holt@gmail.com wrote:
I noticed that support for GPG/PGP encryption was on the RoundCube roadmap as a planned feature. I, for one, think this would be an awesome feature to have in a webmail client. It does bring up some issues with storing private keys for signing purposes. I guess users would just have to trust their webmail provider with securing their private keys.
One possibility would be to implement the feature in two phases: message encryption first since it relies on public keys only and then message signing which relies on private keys. This project is abandoned http://freshmeat.net/projects/openpgpwebmail/ but might be able to be gutted and reused for the message encryption portion of the problem. It looks like it's under the GNU GPL just as RoundCube is so using code from it shouldn't be a problem.
If I get some time I may try and see if I can graft some GPG/PGP features in to RoundCube. My initial idea would be to make these features dependent on GnuPG. Thoughts?
-- Bradley Holt
My suggestion would be to wait for the plugin architecture to be developed and then do encryption/decryption as a plugin. That way it leaves things more open for the user to decide what they want to use (example one could have a plugin that uses openssl instead of PGP). IMHO encryption is more of an extension then something that should be added to the core base of the webmail client.
Mark
Bradley Holt wrote:
Sorry, should have thought of this as well in my first e-mail: http://pecl.php.net/package/gnupg. Thoughts on relying on PECL packages?
-- Bradley Holt
On 2/15/06, Bradley Holt bradley.holt@gmail.com wrote:
I noticed that support for GPG/PGP encryption was on the RoundCube roadmap as a planned feature. I, for one, think this would be an awesome feature to have in a webmail client. It does bring up some issues with storing private keys for signing purposes. I guess users would just have to trust their webmail provider with securing their private keys.
One possibility would be to implement the feature in two phases: message encryption first since it relies on public keys only and then message signing which relies on private keys. This project is abandoned http://freshmeat.net/projects/openpgpwebmail/ but might be able to be gutted and reused for the message encryption portion of the problem. It looks like it's under the GNU GPL just as RoundCube is so using code from it shouldn't be a problem.
If I get some time I may try and see if I can graft some GPG/PGP features in to RoundCube. My initial idea would be to make these features dependent on GnuPG. Thoughts?
-- Bradley Holt
Since support for GPG/PGP encryption is listed on the roadmap under "additional features" I assumed it was planned as part of the core base of RoundCube. Someone please correct me if this assumption is wrong. I don't have a strong opinion either way. This is a feature that would almost certainly rely on outside software so it would be an optional feature even it were part of the core (hence perhaps strengthening the plugin argument).
If this were to be developed as a plugin is there any place I can see a preliminary specification for the plugin architecture? Is this something that has been started yet?
If this were to be part of the core base then your statement about OpenSSL brings up a good point. The GPG/PGP encryption feature should be designed in a flexible and extensible way that allows for multiple choices for encryption software (just as there are multiple choices of databases through Pear::DB). In other words, it would have to be designed to support GnuPG, OpenSSL and any future software that allows encryption/signing.
-- Bradley Holt
On 2/15/06, Mark Dehus dehus@csel.cs.colorado.edu wrote:
My suggestion would be to wait for the plugin architecture to be developed and then do encryption/decryption as a plugin. That way it leaves things more open for the user to decide what they want to use (example one could have a plugin that uses openssl instead of PGP). IMHO encryption is more of an extension then something that should be added to the core base of the webmail client.
Mark
Bradley Holt wrote: Sorry, should have thought of this as well in my first e-mail:
http://pecl.php.net/package/gnupg. Thoughts on
relying on PECL
packages?
-- Bradley Holt
On 2/15/06, Bradley Holt
bradley.holt@gmail.com wrote:
I noticed that support for GPG/PGP encryption was on the RoundCube
roadmap
as a planned feature. I, for one, think this would be an
awesome feature to
have in a webmail client. It does bring up some
issues with storing private
keys for signing purposes. I guess users
would just have to trust their
webmail provider with securing their
private keys.
One possibility would be
to implement the feature in two phases:
message encryption first since it
relies on public keys only and then
message signing which relies on private
keys. This project is
abandoned
http://freshmeat.net/projects/openpgpwebmail/ but might be
able to be gutted and reused for the message encryption portion of
the
problem. It looks like it's under the GNU GPL just as RoundCube is
so
using code from it shouldn't be a problem.
If I get some time I may try
and see if I can graft some GPG/PGP
features in to RoundCube. My initial
idea would be to make these
features dependent on GnuPG.
Thoughts?
-- Bradley Holt
hi bradley,
we are almost finished integrating smime and pgp into roundcube for a project at work.
we are implementing this using a combination of ldap (for x509) and a small C setuid wrapper (to write to user's home directories), which probably won't suit shared-hosting setups, as they will only be able to write files as the webserver user in a common directory.
deadlines are too tight to work up patches for roundcube at this point in time (and likely for the next 6-8 wks), but i'm planning to work on them after that.
cheers justin
Bradley Holt wrote:
Since support for GPG/PGP encryption is listed on the roadmap under "additional features" I assumed it was planned as part of the core base of RoundCube. Someone please correct me if this assumption is wrong. I don't have a strong opinion either way. This is a feature that would almost certainly rely on outside software so it would be an optional feature even it were part of the core (hence perhaps strengthening the plugin argument).
If this were to be developed as a plugin is there any place I can see a preliminary specification for the plugin architecture? Is this something that has been started yet?
If this were to be part of the core base then your statement about OpenSSL brings up a good point. The GPG/PGP encryption feature should be designed in a flexible and extensible way that allows for multiple choices for encryption software (just as there are multiple choices of databases through Pear::DB). In other words, it would have to be designed to support GnuPG, OpenSSL and any future software that allows encryption/signing.
-- Bradley Holt
On 2/15/06, Mark Dehus dehus@csel.cs.colorado.edu wrote:
My suggestion would be to wait for the plugin architecture to be developed and then do encryption/decryption as a plugin. That way it leaves things more open for the user to decide what they want to use (example one could have a plugin that uses openssl instead of PGP). IMHO encryption is more of an extension then something that should be added to the core base of the webmail client.
Mark
Bradley Holt wrote: Sorry, should have thought of this as well in my first e-mail:
http://pecl.php.net/package/gnupg. Thoughts on
relying on PECL
packages?
-- Bradley Holt
On 2/15/06, Bradley Holt
bradley.holt@gmail.com wrote:
I noticed that support for GPG/PGP encryption was on the RoundCube
roadmap
as a planned feature. I, for one, think this would be an
awesome feature to
have in a webmail client. It does bring up some
issues with storing private
keys for signing purposes. I guess users
would just have to trust their
webmail provider with securing their
private keys.
One possibility would be
to implement the feature in two phases:
message encryption first since it
relies on public keys only and then
message signing which relies on private
keys. This project is
abandoned
http://freshmeat.net/projects/openpgpwebmail/ but might be
able to be gutted and reused for the message encryption portion of
the
problem. It looks like it's under the GNU GPL just as RoundCube is
so
using code from it shouldn't be a problem.
If I get some time I may try
and see if I can graft some GPG/PGP
features in to RoundCube. My initial
idea would be to make these
features dependent on GnuPG.
Thoughts?
-- Bradley Holt
Not sure I understand the need ldap or for any c setuid wrapper in roundcube, can't we just store the private keys with the user prefs in mysql? I've only done simple encryption/decryption/signing/verification with openssl & php so maybe I am missing something. I would be willing to help do some coding on this (even though I would rather see it implemented as a plugin). I just want to make sure there is the option for using backends other then PGP.
Mark
justin randell wrote:
hi bradley,
we are almost finished integrating smime and pgp into roundcube for a project at work.
we are implementing this using a combination of ldap (for x509) and a small C setuid wrapper (to write to user's home directories), which probably won't suit shared-hosting setups, as they will only be able to write files as the webserver user in a common directory.
deadlines are too tight to work up patches for roundcube at this point in time (and likely for the next 6-8 wks), but i'm planning to work on them after that.
cheers justin
Bradley Holt wrote:
Since support for GPG/PGP encryption is listed on the roadmap under "additional features" I assumed it was planned as part of the core base of RoundCube. Someone please correct me if this assumption is wrong. I don't have a strong opinion either way. This is a feature that would almost certainly rely on outside software so it would be an optional feature even it were part of the core (hence perhaps strengthening the plugin argument).
If this were to be developed as a plugin is there any place I can see a preliminary specification for the plugin architecture? Is this something that has been started yet?
If this were to be part of the core base then your statement about OpenSSL brings up a good point. The GPG/PGP encryption feature should be designed in a flexible and extensible way that allows for multiple choices for encryption software (just as there are multiple choices of databases through Pear::DB). In other words, it would have to be designed to support GnuPG, OpenSSL and any future software that allows encryption/signing.
-- Bradley Holt
On 2/15/06, Mark Dehus dehus@csel.cs.colorado.edu wrote:
My suggestion would be to wait for the plugin architecture to be developed and then do encryption/decryption as a plugin. That way it leaves things more open for the user to decide what they want to use (example one could have a plugin that uses openssl instead of PGP). IMHO encryption is more of an extension then something that should be added to the core base of the webmail client.
Mark
Bradley Holt wrote: Sorry, should have thought of this as well in my first e-mail:
http://pecl.php.net/package/gnupg. Thoughts on
relying on PECL
packages?
-- Bradley Holt
On 2/15/06, Bradley Holt
bradley.holt@gmail.com wrote:
I noticed that support for GPG/PGP encryption was on the RoundCube
roadmap
as a planned feature. I, for one, think this would be an
awesome feature to
have in a webmail client. It does bring up some
issues with storing private
keys for signing purposes. I guess users
would just have to trust their
webmail provider with securing their
private keys.
One possibility would be
to implement the feature in two phases:
message encryption first since it
relies on public keys only and then
message signing which relies on private
keys. This project is
abandoned
http://freshmeat.net/projects/openpgpwebmail/ but might be
able to be gutted and reused for the message encryption portion of
the
problem. It looks like it's under the GNU GPL just as RoundCube is
so
using code from it shouldn't be a problem.
If I get some time I may try
and see if I can graft some GPG/PGP
features in to RoundCube. My initial
idea would be to make these
features dependent on GnuPG.
Thoughts?
-- Bradley Holt
I'm guessing he's using LDAP to retrieve public keys and the c setuid wrapper is to get access to the user's home directory where their private key is stored. RoundCube would probably want multiple methods of retrieving public keys and LDAP may be on of those methods. While storing private keys in a user's home directory is probably the most secure way of storing private keys it probably wouldn't work for RoundCube because of the inflexibility of the solution (e.g. what do you do on Windows computers?). Storing the private keys (and also perhaps a list of trusted public keys) in MySQL is probably the most flexible option for RoundCube but RC (or the plugin) better come with a big disclaimer warning about the risks of exposing that data. It would be interesting to see how Justin has integrated his PGP features as some of that integration maybe useful for RoundCube.
There are a lot of questions to work out for this feature: -Is it part of the core or is it a plugin? -What back end encryption technologies does it support? The main options look like GnuPG and OpenSSL. -Is it built in a way that is extensible to support other back end options other than those initially developed? -What signing/encryption methods does it support? The options I see are S/MIME, PGP/MIME and/or PGP/inline. The back end options will help dictate the signing/encryption methods and vice versa. I think S/MIME would go with OpenSSL and PGP/MIME and PGP/inline would go with GnuPG.
On 2/15/06, Mark Dehus dehus@csel.cs.colorado.edu wrote:
Not sure I understand the need ldap or for any c setuid wrapper in roundcube, can't we just store the private keys with the user prefs in mysql? I've only done simple encryption/decryption/signing/verification with openssl & php so maybe I am missing something. I would be willing to help do some coding on this (even though I would rather see it implemented as a plugin). I just want to make sure there is the option for using backends other then PGP.
Mark
justin randell wrote:
hi bradley,
we are almost finished integrating smime and pgp into roundcube for a project at work.
we are implementing this using a combination of ldap (for x509) and a small C setuid wrapper (to write to user's home directories), which probably won't suit shared-hosting setups, as they will only be able to write files as the webserver user in a common directory.
deadlines are too tight to work up patches for roundcube at this point in time (and likely for the next 6-8 wks), but i'm planning to work on them after that.
cheers justin
Bradley Holt wrote:
Since support for GPG/PGP encryption is listed on the roadmap under "additional features" I assumed it was planned as part of the core base of RoundCube. Someone please correct me if this assumption is wrong. I don't have a strong opinion either way. This is a feature that would almost certainly rely on outside software so it would be an optional feature even it were part of the core (hence perhaps strengthening the plugin argument).
If this were to be developed as a plugin is there any place I can see a preliminary specification for the plugin architecture? Is this something that has been started yet?
If this were to be part of the core base then your statement about OpenSSL brings up a good point. The GPG/PGP encryption feature should be designed in a flexible and extensible way that allows for multiple choices for encryption software (just as there are multiple choices of databases through Pear::DB). In other words, it would have to be designed to support GnuPG, OpenSSL and any future software that allows encryption/signing.
-- Bradley Holt
On 2/15/06, Mark Dehus dehus@csel.cs.colorado.edu wrote:
My suggestion would be to wait for the plugin architecture to be developed and then do encryption/decryption as a plugin. That way it leaves things more open for the user to decide what they want to use (example one could have a plugin that uses openssl instead of PGP). IMHO encryption is more of an extension then something that should be added to the core base of the webmail client.
Mark
Bradley Holt wrote: Sorry, should have thought of this as well in my first e-mail:
http://pecl.php.net/package/gnupg. Thoughts on
relying on PECL
packages?
-- Bradley Holt
On 2/15/06, Bradley Holt
bradley.holt@gmail.com wrote:
I noticed that support for GPG/PGP encryption was on the RoundCube
roadmap
as a planned feature. I, for one, think this would be an
awesome feature to
have in a webmail client. It does bring up some
issues with storing private
keys for signing purposes. I guess users
would just have to trust their
webmail provider with securing their
private keys.
One possibility would be
to implement the feature in two phases:
message encryption first since it
relies on public keys only and then
message signing which relies on private
keys. This project is
abandoned
http://freshmeat.net/projects/openpgpwebmail/ but might be
able to be gutted and reused for the message encryption portion of
the
problem. It looks like it's under the GNU GPL just as RoundCube is
so
using code from it shouldn't be a problem.
If I get some time I may try
and see if I can graft some GPG/PGP
features in to RoundCube. My initial
idea would be to make these
features dependent on GnuPG.
Thoughts?
-- Bradley Holt
-- Bradley Holt
I'm guessing he's using LDAP to retrieve public keys and the c setuid wrapper is to get access to the user's home directory where their private key is stored.
yep.
RoundCube would probably want multiple methods of retrieving public keys and LDAP may be on of those methods. While storing private keys in a user's home directory is probably the most secure way of storing private keys it probably wouldn't work for RoundCube because of the inflexibility of the solution (e.g. what do you do on Windows computers?). Storing the private keys (and also perhaps a list of trusted public keys) in MySQL is probably the most flexible option for RoundCube but RC (or the plugin) better come with a big disclaimer warning about the risks of exposing that data. It would be interesting to see how Justin has integrated his PGP features as some of that integration maybe useful for RoundCube.
i imagine that most smaller rcube installs wont have control over the server that they are running rcube on, so it would be good to offer a choice on how to deploy this.
the implementation we are developing will not be suitable for many setups, but hopefully some of the code will be useable.
There are a lot of questions to work out for this feature: -Is it part of the core or is it a plugin?
i'm not sure myself on this yet.
-What back end encryption technologies does it support? The main options look like GnuPG and OpenSSL.
yep, we are using openssl for s/mime and gnupg pgp/mime.
hi mark,
Mark Dehus wrote:
Not sure I understand the need ldap or for any c setuid wrapper in roundcube, can't we just store the private keys with the user prefs in mysql? I've only done simple encryption/decryption/signing/verification with openssl & php so maybe I am missing something. I would be willing to help do some coding on this (even though I would rather see it implemented as a plugin). I just want to make sure there is the option for using backends other then PGP.
yep, there's no need for this in roundcube - its just what we needed :-)
x509 and ldap go hand in hand.
a setuid wrapper for gpg is necessary for us to write to user's home directories, but is likely not going to be the most common way that roundcube users would deploy encryption/signing of messages.
it would be nice to offer different options as you say.
cheers justin
justin randell wrote:
hi mark,
Mark Dehus wrote:
Not sure I understand the need ldap or for any c setuid wrapper in roundcube, can't we just store the private keys with the user prefs in mysql? I've only done simple encryption/decryption/signing/verification with openssl & php so maybe I am missing something. I would be willing to help do some coding on this (even though I would rather see it implemented as a plugin). I just want to make sure there is the option for using backends other then PGP.
yep, there's no need for this in roundcube - its just what we needed :-)
x509 and ldap go hand in hand.
a setuid wrapper for gpg is necessary for us to write to user's home directories, but is likely not going to be the most common way that roundcube users would deploy encryption/signing of messages.
Gotcha.. thats what I figured.
it would be nice to offer different options as you say.
It would be very nice, that is why I think it may be best to do this as a plugin instead of integrating it into the core branch of roundcube. That way if someone does not like the encryption plugin that comes with roundcube, they can write their own replacement instead of having to hack at the core itself (or the encryption side of it).
Mark
cheers justin
-
Bradley Holt -
justin randell -
Mark Dehus