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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >> > >> > >>> <[EMAIL PROTECTED]> 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
