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/[email protected]/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/
