On Tue, May 19, 2009 at 9:53 AM, Cor Bosman cor@xs4all.nl 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/