Plugin Hosting

Sponge Sponge Development
147

Anyone was allowed to decompile plugins on BukkitDev to confirm that they were safe - there was always the added security of knowing that it had been approved by a moderator. Allowing the community to review plugins that have not been approved yet is essentially permitting the download of possibly malicious files. With the generally young age of the Minecraft community in mind, I can’t really see this as being as secure as it can be.

A system of “raising flags” may also add to the ‘burning out’ of the reviewers on the Sponge team. Instead of doing a ‘clean review’ it may come to a point where the reviewers will only rely on the flags from the community.

The problem with a diff-based review process is that you are assuming the previous moderator/author was infallible with their review. Mistakes happen, and backdoors may potentially pass more than one review in this sort of system. This may also accelerate the process of reviewers ‘burning out’ as I mentioned above.

1 Like
148

We definitely need some sort of package management!

I like the way bundler works in Ruby. Basically you have a file that specifies the repository (e.g. repo.spongepowered.org), the plugins you want to use, optionally with a fixed version (otherwise latest is assumed) and it even supports referring to git or GitHub repos for plugins.

Here’s an example Gemfile (ruby plugins are called gems):

source 'https://rubygems.org'

gem 'fancy-plugin' # latest version
gem 'coolmod', '~>2.0.1' # version 2.0.1
# this plugin will be downloaded from GitHub instead of rubygems.org
gem 'forked-plugin', github: 'myself/that-plugin', branch: 'my-patches'

To install these, you simply run bundle install, it download’s your plugins and their dependencies and you’re done.
bundle update updates all plugins to the latest version, simple as that.

I think this is a really awesome and simple way to manage plugins and we should use something similar for sponge.

3 Likes
149

I suggest that we have some repo filled with MD5’s or SHA’s of plugins to verify that a server admin is not installing a rat or something like that (obviously can be done since this is Java).

1 Like
150

please not MD5, it’s not really secure. SHA-2 or 3 are ok, I guess.

151

Of course MD5 isn’t a good one to use. There’s known hash collisions. I only suggested it since it’s faster to do an MD5 hash…

152

Had a look at how Maven/Ivy dependency management works?

153

I’m in favor of combining the efforts of the community and moderator screenings. Also a complete ‘no’ for any kind of money involved in the uploading - I think even more mature devs would be turned off by the thought of having to flip out their payment details just to upload a file.

154

I would agree with this, I feel like an unrevealed, or even somewhat randomly generated requirement (e.g. between 10 & 20 files must be reviewed), with the ability to flag users by reviewers for something like non-files being submitted, or the same file being resubmitted several times for the purpose of beating the review requirement. I feel like this would be reasonably annoying for newer submitters, while providing a decent buffer between the users and the common Malicious code trolls.

Also, Because I am not too familiar with the Plugin community… are plugins more vulnerable to malicious intent then mods, if so I would greatly appreciate a technical explanation ;~)

155

I don’t use Java, but from what I know it’s similar. Though, a Gemfile is kept really simple and nicely readable, so I’d prefer that.

156

On the other hand, Gemfile support would either require a custom parser or (at least) a JRuby implementation, and is hard to do securely. Maven/Ivy is already proven and used, is plain XML (so easy to parse securely), and is already both generated and consumed by Gradle (the build tools used by Sponge).

157

i vote for number 3.
on EVERY download page, there should be a link to jdgui (http://jd.benow.ca/) and a recomendation that people use jdgui to decompile ALL plugins that they download
EDIT:
sometimes the decompiled code is different to original code.

i suggest that you force developers to upload the source code, then the server compiles it.
server owners then get access to:

  1. an online source viewer (like github’s file preview)
  2. zip file download of the source
  3. compiled jar file

another thing:
devs get rep for good files,
Everyone gets rep for reliable reviews (flagging a file for review, then staff members agree with it)

@sk89q
if you use both flags and community reviews, some things that get past the flags might get caught by the community, then you can add a flag to prevent similar attacks, keep doing this, and eventually, almost all dangerous plugin will be eliminated.

of course, there will still be people who can get past everything, but i think currently, more damage is done by the people who write simple hacks, so if we get rid of them, we get rid of most of the problems.

also, i suggest that you get the downloads site finished and fully operational before you start letting people make mods / plugins,
if someone makes a plugin, but theres no official website to upload it to, they will find somewhere else to put it,
they usually wont bother reuploading it on the official website

ANOTHER IDEA @sk89q
(this idea was stolen from google :smile:)
you should add permissions groups for plugins,
before the server owner downloads the plugin they see something like this (but for plugins, not apps)

the server owner clicks accept, they download the plugin
for example, the server will NOT let the plugin use .setop(true) unless the developer has told the website that they will use it.

159

You have good points but I respectfully disagree. In my opinion the added work of a full review for every update or submission is more likely to burn people out, yes it’s riskier, but as a trade off for speed, and less work for the reviewers I believe its worth it.

Even if files were not released until reviewed, I still believe diffing with the option to fully review is the best method, and should also be viewable by the community.

Additionally external sites should still display warnings but should not be banned.

160

I don’t think that developers should get rep’d for plugins… This could turn into Hackforums where it’s harder to get people to try out your stuff if you’re low on rep (ie those who release plugins from the beginning get the most rep and people trust them).

edit: Also I disagree with supporting plugin decompilation. Not saying that I don’t decompile some plugins, but encouraging this can be bad especially if the developer does not wish to share the sauce yet (or at all).

2 Likes
161

I agree. It sucks if you made something new that is actually pretty good, but nobody uses it because your rep is low. Also, concerning decompiling, most users can’t even understand teh codes. (People setting up servers for friends etc…).

The only kind of “rep” I’d suggest is flagging (tag next to name) people if they actually did something bad. But I’d not bother as moderation and just straighout ban them for posting malicious code.

Also, some things (Grief prevention etc) would be compromised if everybody was encouraged to decompile them. (Not that hack developers didn’t do that anyway…)

1 Like
162

One thing that I think is very very very important is that the plugin hosting is accessible via an API. (REST?)

There are several types of systems that could profit from it.
Auto updaters, update checkers, local plugin managers, things like MCAdmin or comparable control panels.

163

Maybe instead of a Reputation system, how about a Karma System?

164

i didnt think about the rep thing.

the only reason a dev would not want the source to be seen is if they are hiding something bad

165

Or, you know, if they didn’t want someone to steal their code.

1 Like
166

Define: Stealing. If I look to someone code it is to learn from it. And with jd-gui you can see every plugin his source, so why hidding it?

167

Can protect someone’s intellectual property.