For now, maybe those with plugins could make a page on trac.roundcube.net, along with a corresponding plugin list.

Adam

On Mon, May 18, 2009 at 11:03 AM, Naveen Gavini ngavini@jla.rutgers.edu wrote:

I would also like to see something like this, it's very difficult to see what has been already ported to a plugin or what still needs to be.

• Naveen

Cor Bosman wrote:

...

Hi all, there doesnt seem to be a repository yet for plugins using the API. Right now there are the example plugins in SVN, and i know of a few plugins made by others, but id like to see a central spot where one can find API plugins.  What ideas are floating around for this? The moment 0.2.2 comes out, I hope a lot of people will start making proper plugins..

Regards,

Cor _______________________________________________ List info: http://lists.roundcube.net/dev/

-- Naveen Gavini Student Systems Programmer OSS/CSS - OIT Rutgers ngavini@jla.rutgers.edu

---

List info: http://lists.roundcube.net/dev/

List info: http://lists.roundcube.net/dev/

On May 18, 2009, at 11:18 AM, till wrote:

I'm working on a plugin repository.

I think this is a great idea, but I see a concern. Maybe I am a suspicious, paranoid person, but would there be any
procedure or process to make sure plug-ins don't contain malicious
code ?

I'm not suggesting that any of the current plug-ins contain malware,
or that any developers on this list have nefarious purposes.

I haven't examined all of the code in RoundCube myself, so there is a
level of trust between users and developers.

For some reason I see a potential security hazard downloading random
plug-ins and sticking them into the guts of RoundCube.

Something to think about I guess, even if the end result is " That
dude is stupid crazy ! "

On May 18, 2009, at 3:02 PM, till wrote:

No, I totally get your concern.

OK, good, I'm not crazy.

We talked about that part and we do plan to evaluate plugins before we host them.

Peer review. Not that this is a procedure I recommend, by as an example Fedora
requires any package proposed for the repository to pass a review by
another developer. This review is not a code audit, but it is to make
sure the packaging part is consistent with other packages, and the
package doesn't step on the toes of another package, etc.

I keep thinking about how Firefox add-ons are handled. Each add-on has its code vetted, installation checked, and
functionality tested. Installing an add-on has checks built into
Firefox. I'm not saying these are specific procedures the RoundCube should
follow. I am simply pointing at a framework of how the issue was
handled elsewhere.

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.

Some plug-ins might be so specialized that it might be tough finding
one other person to test it.

Maybe some type of grading system.

Green : plug-in implemented by RC developers Blue : plug-in that has been completely vetted, including code audit,
installation, and functionality test Orange : plug-in known to work by community members, but otherwise
unknown quality Red : plug-in that is experimental and completely untested

I don't know yet how much we can do automatically, etc..

Yes, having humans look at stuff is a time bottleneck and those
humans can potentially make mistakes.

I haven't looked into it. And most 'scanners' I have tried provided mediocre results.

Things like rpmlint can provide spurious output, but at least
something like that can remove some of the mundane parts of checking
and reviewing.

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/

till wrote:

I'm working on a plugin repository.

Until our official plugin repository is ready I've set up a wiki page to give developers an overview of currently developed plugins: http://trac.roundcube.net/wiki/Plugin_Repository

If you're working on a plugin and plan to publish it later on, you're kindly requested to add it to the list on that page. Maybe you can even add a short description. This should mainly avoid duplicate work.

Now go on coding!

Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/