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< ---