Plugin Hosting

Sponge Sponge Development
1

Right now we are trying to decide how we should manage a plugin repository system. Before we decide anything, we’d love to gather input from the community to see what they’d like! I look forward to reading all the constructive feedback you guys provide. Feel free to give suggestions to my proposals or make your own.

Proposal 1: Bukkitdev like system
We could handle things very similarly to how we did on BukkitDev. This includes:

  • Proactively review every file before they are
    available for download.
  • Auto scan files for red flags but still
    review by hand.
  • Allow CIs for dev builds.

This system is as secure as the moderators handling the reviews. It allows for catching complex backdoors before they are made public but it also sacrifices speed and burns out the moderators reviewing the plugins. Approval time fluxuates a ton based on how many developers are able and willing to review files. Times ranged from a few minutes to a few days.

We could look at changing specifics such as development build / CI policies.

Proposal 2: Community moderation
Another option is to handle reviews completely community moderated.

  • Rely on the community to decompile and review files for backdoors or
    anything else.
  • Have a team of staff that reviews files that throw up
    red flags.
  • All files immediately available for download.

This system is not very secure but it allows for instant download of any file. This is similar to how Spigot handles their resources except that they don’t scan files to flag them for moderators, they just review as reported (from what I’ve gathered).

Proposal 3: Combination of proactive and reactive reviews
This system is a compromise of security and speed.

  • Proactively review the first file of each author or project.
  • After the first file, all files are immediately available for download.
  • Scan additional files and flag for review. Certain flags would bump files to the top of the queue, otherwise files would be reviewed in the order they are submitted.
  • A system such as ‘semi-normal’ and ‘normal’ to denote if files have been reviewed.
  • Possibly have certain flags (such as .setOp and System.execute) force a file to be proactively reviewed before it is available for download.

Obvious cons to this system: people uploading a safe file to get passed the proactive review system and then upload malicious files after that, moderators become lackadaisical and don’t bother reviewing files that aren’t flagged.

26 Likes
2

I’m a fan of the second proposal.

I have confidence in the community to catch these possible malignancies.

Edit after some thought:

Why not have a combination of the first two? I mean an automated system is good, but automated systems don’t adapt to new things, they only do what they’re told. Users will always try to bypass such filters, exploiting the community with malicious files. I prefer to have both.

3 Likes
3

I think the first one will be good just like bukkit…

3 Likes
4

Proposal 3 but autoscan all files.

And if there are comming to many backdoors switch to Proposal 1.

1 Like
5

I’d rather not have a system like DBO, reviewing each and every file was too time consuming and did burn out the staff.

Towny doesn’t have an issue either way, we’ve hosted our own files since February 2013 and it’s been going very well.

1 Like
6

Proposal 3, however I would say have a reputation system, where you would need a certain amount of files approved manually before your files are immediately available for download.

23 Likes
7

@Tux2

Love this idea! But autoscan all files for sure.

1 Like
8

Maybe a combination of proposal 1 and 3. Be more strict with newer plugin devs but a little more lax for seasoned devs. (as for seasoned, say like if they’ve been around for more than 3-6 months or so.)

9

There was 3 ideas… which one did you like?

10

I think that the third proposal would be good, given some caveats. The first iteration of a new plugin should require code review by a moderator / expert to ensure that it’s up to par. After that point, subsequent versions would have to be passed through an automatic code analyzer to check for issues. We would need a specific format that all plugins must follow (similar to PR guidelines for Sponge) so that a program can scan for issues. It would have to build and test on a server without throwing any severe errors. There would also need to be some kind of security check for malicious code. It should be a little zealous (making some false positives) and marking each for more indepth review. If a person can look over the warning and there are no actual issues, the system can be adjusted to whitelist those errors to prevent catching it again in the future and the plugin will be cleared. Those are just some thoughts. I’m sure, since I’m not a professional Java developer, I am missing some key detail. But something like this would be good to think about for efficiency.

12 Likes
11

I tagged @Tux2 so I mean his idea.

1 Like
12

I vote for Proposal 3 - and I agree with @Tux2 's idea of a reputation system. I also think the community should be able to flag the files.

1 Like
13

You could set up a strawpoll for this. Anyways I’m definitely a fan of the second proposal. There are a lot of skilled developers out there that sure wouldn’t mind identifying some files.
Something extra that you could add though is once a file is fully reviewed by a staffmember you could have a little verified or checked symbol, indicating that the file you’re downloading is 100% safe. Something like the Facebook or Twitter verified symbol onto a file’s thumbnail? :slight_smile:

EDIT: Something like this:

18 Likes
14

@Ivan
I like the Verified symbol idea

But strawpoll is not handy because of custom ideas.

1 Like
15

I like the idea of a hybrid system, something like #3. Consider maybe something like:

  • Unreviewed: the plugin is not considered trusted and should only be used if the downloader agrees to the risk.
  • Community-reviewed: After (x) people have reviewed the code, it can be flagged as community-reviewed. This would have to be looked at carefully to prevent abuse by spinning up sockpuppet accounts- maybe by account age or a rep system.
  • Fully reviewed: While the project can never assert complete safety, a fully-reviewed plugin has been reviewed by staff who agree that it is likely to be safe.

Another option might be some kind of trust system built into the APIs?

9 Likes
16

I would personally like to see the third proposal go through. I have no additional comments on it, as others have already stated exactly I would like it.

1 Like
17

I prefer #1 but would settle for #3 with the verify symbol and/or rep system. I am torn between burnt out staff and having another InfiniteDispenser incident… Malicious updater for DDoS attacks…

3 Likes
18

Suggestion: No need to add a notice for Updater, Metrics or Mojang servers connections… :smiley: Only for things like silent auto-updaters.

1 Like
19

I like the third option. Also like the idea of putting reputation points for developers based on mod stability, creativeness, difficulty, downloads, etc;

1 Like
20

Possibly, but if we’re doing QA like that, it will be a lot of extra work and burn out staff members.