On Tue, May 19, 2009 at 9:53 AM, Cor Bosman <[email protected]> wrote: >> No, I totally get your concern. We talked about that part and we do >> plan to evaluate plugins before we host them. We don't want to end up >> with 10000 plugins where only a handful works and 2/3 of them pose a >> risk to your system. > > I think you're taking on a huge responsibility. Not only do you have to > worry about the initial release of a plugin, but years and years of future > maintenance. Are you going to evaluate release 4.1.14 of a plugin that > fixes a few bugs? If not, why not? If I were a hacker, thats when id add > the 1 obscure line that'll give me remote access. RC will at most get a few > hundred plugins, but trying to police a few hundred plugins through all > their maintenance releases is a lot of work, especially if plugins are > trying to update their code for new RC releases.
Well, for general compatibility I plan to use a small XML script which can be updated and e.g. will say, this only works with RoundCube 0.2.2 to 0.3-beta. And no, we don't plan to do maintenance on plugins (for authors) but I'd like to force/encourage publishing source code so people can take over in case. That's why I like the idea of github -- "please fork". I realize that this is probably a steep curve for people who are not familiar with VCS but then again, it's a great opportunity to learn. I'm trying to check out a way to integrate this with our trac so people have single-sign-on and can open issues for plugins etc.. > I think it won't be so bad. I highly doubt you'll see lots of crappy plugins. > And if there are, people are smart enough to recognize useless plugins. > This is working just fine with squirrelmail, wordpress and many projects. > RC is really not a very smart infection vector for attackers (unlike firefox > which has like 1000 times more exposure). Your window of opportunity is so > small, that its barely worth the effort of creating a plugin just for this > purpose. Yeah, I don't know if that is the case. After all it's PHP. :) Everyone can do it, right? I'm not saying we end up with 10000 plugins like wordpress though. ;-) > One way to weed out abandoned plugins (you'll see plenty of those) is > to have plugin maintainers update a compatibility flag with their plugin > whenever a new RC release comes out. So if RC 0.3 comes out, plugin > maintainers have to update their compatibility flag after testing. Once a > plugin lags behind a few releases you'll know it's not well maintained. > > What I would do if I were RC is do a quick evaluation of a new plugin > before you host it, but look more at code style and quality than trying > to find all kinds of security bugs (unless they're obvious). Smart hackers > will hide it so well, you won't find it anyways. But after the initial check, > let it do all maintenance without evaluation. Yeah, there's a couple tools we can utilize. I'll plan to wrap the PEAR installer in the back so evaluating if a package was done right is dead easy. Then add in php lint and maybe additional checks with PHP_Depend or PHP_CompatInfo and we got it covered. > As a last point, I think if RC puts up too many barriers for plugin developers > you'll see a third party repository pop up before you know it. I think that > would be even more cause for concern. Well, people can virtually do whatever they want. The beauty of opensource! We are also not looking to do a vendor lock in and impose regulations on people. You can download and run whatever you want. Whatever *we* will host, will be subject to a stricter evaluation. Whatever they do, it comes with no warranty and guarantee. Till _______________________________________________ List info: http://lists.roundcube.net/dev/
