Plugin Trust System

The topic “Plugin Hosting” (Plugin Hosting - #15 by Cyclometh) led me think about this concept as a means of potentially addressing some of the issues with Bukkit’s plugin system and the lag time in getting files up for download.

Would it be feasible, since we’re still in the early stages of this project, to build a plugin trust framework, possibly using some kind of web of trust? Thinking about it, it’d be complex to build but could in theory make the plugin shipping pipeline a lot smoother and faster.

Thoughts?

1 Like

The web of trust is someone verifying a truth, that you are a particular person. I’m not willing to say any of you will never upload something malicious because that’s not a truth but a probability.

4 Likes

It’s definitely a good idea. Instead of having an old-school, complex type of system to sort out all the plugins, we should definitely have a framework based on feedback, downloads, popularity and rating.

2 Likes

All it would take is for one person to ruin it. People would upload safe files, gain ‘trust’, then upload a malicious one later.

3 Likes

We’d probably need human staff to review the plugins - that would be the safest way.

1 Like

That’s a fair point, and you’re correct (I probably should have avoided the crypto reference), but it’s possible to build a system that doesn’t make “trust” a binary condition, but rather a mechanism that relies on established reputation. If a plugin author(s) has a solid track record and established bona fides, it would make sense that their releases are more trustworthy. Conversely, a new or unknown person’s releases should be subjected to greater scrutiny. How that plays out in terms of design is an open question (or if it does at all).

In the end you’ll never eliminate the need for humans to review things. I’m just thinking about ways to work in ways to focus the limited review resources on the places where it will do the most good and at the same time eliminate the review bottlenecks bukkit had (and not expose end-users to more risk than is warranted).

3 Likes

I suggest a permission/access system similar to how Android Apps are managed. Plugin devs will define what permissions the plugin needs in order to be able to use it. It also would keep server owners/admins aware of what a plugin could do with the permissions it needs to run.

3 Likes

I think initially there should always be a human (preferably a moderator), like @AtomSponge already mentioned it, which reviews the first 1 or 2 versions of the plugins. After that the community may be another instance in reaching a good level of trust. The people from the community could review the code of the next versions and finally the last instance, which should avoid mistakes, the automated scanner (like it has been mentioned in the plugin hosting).

I like that idea a lot, but you’d be able to circumvent that easily through reflection in Java though.

That would take pressure off the moderators of course, but as @drtshock said, a developer could easily upload one or two “proper” versions of a plugin and add malicious code later.

2 Likes

But no dev would be considered experienced and trusted without many scanned and reviewed uploads. If the staff could fine tune it enough then it would become so much more efficient.

Waiting a long time for an update sucks. Once I waited a month for one of my updates to be accepted. This system could make it a lot better for devs. It just needs to be fine tuned correctly.

In regards to the Permissions thing for plugin:

We tried this in Spout (or we were planning to). This is very difficult to do, because we’d have to set up a SecurityManager and stuff like that. While it is a good idea, I doubt it’ll happen.

This is my opinion, other devs may have a different opinion.

1 Like

There’d always be a risk that a developer could get outrageously mad at anything or have a bad day and then abuse then. Staff who look through plugins may make the process take a while, but it is worth it. They should look for more people to look over the plugins if it starts to become a lot of work for them. Granted, this won’t be a problem for a little while now.

1 Like

Yes, having random checks could discourage someone from adding malicious code to their plugin.

I second that. Another concern is that a system like that will become a bro-sciety where “trust” is gained by popularity and personal favors.

For me, it’s either a system that handles all files, authors and users the same or no system at all. I wouldn’t care if there isn’t anything better than the forums for hosting of my project “sites”. At least for a while.

1 Like

A question about the review system, some licenses state that reverse engineering of software is not permitted, which would leave the SpongeProject liable for a civil lawsuit. Will this be taken into account when you write the terms of use or build the plugin submission system?

I imagine they could implement a terms and service that require them to reverse engineer any plugins that get added so that they can ensure that they are safe for the community and server admins. I think if there was a policy like that, SpongeProject would be safe. It probably is the same way as Bukkit was, as that would be something that impacted that.

1 Like

I just looked through http://wiki.bukkit.org/BukkitDev:Project_Submission_Guidelines and http://forums.bukkit.org/help/terms and it has nothing relating to it there. I think it should be something here as getting caught up on something as small as that would be annoying.

1 Like

Yeah, I agree. That would suck. @sk89q should add a small note to the submissions policy here about reversing the plugins only for security checks.