Custom Maps Auto-Download Plugins Client Side

or ore can use the forums credentials to provide one sitewide account.

3 Likes

Also possible. I believe that that was already talked about at some point, now that you bring it up.

This could be really nice. However as @FerusGrim pointed out it would need to go through some verification purposes. Perhaps some extra parameters? For example:

$ oreget wardenac [-v version] [-u username] [-p password]

Then have a log file which says it was downloaded by X person.
That way in a configuration file you can set, hey only accept plugins downloaded by “Y”. That way if they don’t log into person “Y”'s account, than the plugin won’t be downloaded?

3 Likes

Does not seem like a good idea. Totally eliminates the ability for any kind of third party sites or applications to be built upon Ore and eliminates legitimate uses (e.g. a plugin that grabs dependencies it needs).

Plus, it doesn’t do anything against people creating malicious plugins that download things against the owner’s will. Great, you can’t download plugins automatically from the Ore site, but stick your malicious plugins on any other file sharing site, and just download it from there.

This really doesn’t need to be an issue. Each plugin declares it’s dependencies with the @Plugin annotation. Ore could easily get the plugin’s dependencies and ask the server owner if they wish to download them.

This is not something that needs, nor should it be, handled by plugins.

You’re right, Ore can’t stop malicious plugins from utilizing sources that Ore can’t control. Not sure why you think it should, nor why it seems to be an argument I need to answer for.

Okay, fair enough. But it stands that requiring an account for download things from Ore removes the ability for developers to build upon Ore as a platform, and doesn’t do anything for security.

You presenting requiring an account to download from Ore would get “rid of the chances of malicious plugins just downloading things”. It doesn’t. It removes the ability for malicious plugins to download things from the Ore site, but in no way presents any kind of roadblock to someone who wanted to develop a malicious plugin, for the reasons I mentioned.

1 Like

Not to mention that requiring a server owner to give out credentials in order for certain plugins to function (if those plugins required the ability to download other plugins) bears a notable inherent security risk.

It’d be asking people to trust arbitrary plugins with their credentials rather than implicitly trusting plugins with the ability to use the Ore site… I don’t think that’s an even trade.

1 Like

The only thing the account would be used for is ensuring that people can’t download plugins from Ore without the server owner being aware that it’s happening. I hardly think that this stops developers from being able to build upon Ore.

For instance, when you’re using a package manager on Linux (which is, essentially, what Ore is attempting to function as), unless you’re the root user, you’re required to input a password. This is to stop malicious programs downloading and installing software you don’t want.

Granted, it doesn’t stop a malicious plugin from downloading from other sources, but why should Ore give malicious developers yet another alley for attack? It makes more sense to close off what would otherwise be a vulnerability created by Ore on a server.

I think you’re mistaking how I’m imaging Ore would work. Rather than a plugin doing all of the work itself, I’m more imagining that Ore would detect dependencies, and have the user supply them to the Ore plugin itself. I see no reason why any plugin should have to interface with Ore, besides possibly building upon the platform itself.

As far as I’m concerned with downloading from Ore, that should always - and only - be handled by Ore itself. Of course, these are just my opinions on the matter, but I don’t see why a plugin should be forcing a download from the Ore server, when they could just list the plugin as a dependency and be done with it.

According to a staff member (don’t remember the name) each plugin will be checked by humans, so the chances of malicious plugins getting through is very low.

2 Likes

This isn’t a foolproof system, and shouldn’t be treated as such.

That’s right, that’s good. But you are not required to register on sites that you’re downloading packages from - they’re public and freely accessible.

Say I happen to maintain a public modpack/plugin repository. Requiring account credentials in order to access Ore would discourage people from being able to host publicly accessible instances, as that would be analogous to allowing public access to (do things in the name of) your Ore account.

By that logic, every site on the internet which files can be posted is a vulnerability. You seem to be trying to make an argument that we have to lock down a curated site where user content is posted over the fact that it’s user content… even though there are literal millions of similar sites on the internet. Hosting malicious files on Ore would in fact be more difficult than using any random free service, since files must go through an approval process.

Basically I don’t see requiring credentials for Ore downloads as any kind of stumbling block to someone who wanted to download bad things on your server; I only see it as a cause of difficulty for legitimate developers and administrators.

2 Likes

Fair point.

How about this - my biggest concern is that plugins would be downloaded without the server owner’s knowledge. This causes problems, for more reasons than malicious intent.

As long as some sort of verification of the download (a simply “y” in chat, would suffice, I suppose) is done before a download, this would solve that issue nicely. Or, at least, not give server owners the excuse that they didn’t know what they were downloading.

EDIT: I didn’t ignore the rest of your post, btw. I just didn’t have any decent responses to your point, and responded to the one I could actual respond to.

On Ore, possibly. But the issue is generic download of malicious files. You’d need some kind of JVM-level sandboxing (sorry, I don’t claim to be much of a Java developer) in order to prevent generic network i/o. And that would, of course, cause issues with being able to connect to database services, read various other API, etc. Perhaps it’d be possible to do some detection for download of binary files… but that could be sidestepped with simple base encoding…

In short, I don’t really have an answer to that :stuck_out_tongue: A curation and review process would (as far as I can tell) seem the only semi-sure way of preventing malicious scripts.

That’s why I said very low chance (meaning it’s still possible).

The claim that plugins could be able to download potentially malicious plugins from Ore “without authorization” is true. In fact, a lot of security risks come from the fact that Sponge runs plugins without sandboxing, which means this point (and many others like it) is absolutely moot. It also means any “security features” in place to have some sort of authorization for plugins programmatically from Ore are absolutely pointless, for many reasons mentioned above. Plugins can literally do anything due to the power they are given. Why on earth would a malicious plugin download another one from Ore without the admin noticing? There are more interesting things to do in an unboxed environment.

The point has been brought up that package managers like apt-get require root (which “requires entering a password”, I put this in quotes because it’s not related to the fact that apt-get requires root), and this means that all package managers should require passwords. Does Maven require you to enter a password to download jars? NPM? NuGet? No repository of this type that I know of requires users to enter their passwords to download artifacts. This is because packages downloaded by apt-get decide where to install their source/software, and often times this install location needs root-level access to be written to.

I should assert that Ore isn’t that special. Ore is practically like any other repository (looking at Maven mostly, however), except that it hosts plugins that are reviewed. I have recently realized that this means that most package-manger-like problems have already been solved by Maven, and in turn means that Ore is really just a Maven repository with slightly more features. This has obvious implications over what Ore really is and its usefulness in terms of hosting plugins, as well as where developers on Ore should focus features.

This leads us to the plugin dependency issue. Yes, plugins can specify dependencies with @Plugin, but I am beginning to think that this non-standard dependency description format is not the best way to go about it. A rather good method for specifying dependencies already exists, and it’s called a Maven pom file. This is used by nearly every Java developer on the planet (who uses Maven), and is arguably more ubiquitous than package.json. The reason that no one seems to know about it is because Maven handles it so well; there’s commands to automatically generate this file and upload it to a Maven repository, and Maven silently scans it when determining transitive dependencies to download. To me this seems to be the perfect solution to “detecting dependencies”, and solves many of Ore’s previous problems.

The question here is what direction we should go. Should Ore require plugins to be uploaded by Maven, or be able to coerce artifacts uploaded manually into a Maven-readable format? Is there any point in having manual uploads?

I realize I am going rather off-topic here, but the Ore <-> Maven similarity has far-reaching applications, including this one. Loading mods on the client side resolves to being several smaller (but not necessarily easier) issues:

  1. Downloading mods. Solved by using Maven, Apache Wagon, and a maven repository exposed by Ore.
  2. Loading mods while a player is connecting to a server. This is different from the typical mod-loading lifecycle, which is done by FML before the game starts. I don’t even know if this problem can be solved, and I don’t have nearly enough knowledge about how FML loads mods as well as how the game works internally to make any statement on it.
  3. Unloading mods when a connection from a server is lost. Again, I don’t know if this is possible, but it is a requirement.

Perhaps these problems can be made easier with a very limited client Sponge API that allows for custom textures, blocks, sounds, and mobs instead of fully-fledged mod loading. Almost certainly a client-side plugin solution requires users to install Forge for the client, and install some sort of Sponge client mod.

6 Likes

Is sandboxing an option at all?

There are a few sandboxing programs out there that are both Java dedicated and OS-level. I don’t think I 100% trust any of them though.

Adobe and Sun/Oracle have been trying to sandbox their browser plugins for well over a decade. Exploits still get released frequently. I’ve yet to see a sandbox that’s entirely effective, even KVM has been broken out of :stuck_out_tongue:

Instead you should trust like 0% of them. Because they almost all have exploits released frequently as @connor_peet mentioned. :stuck_out_tongue:

Something is better then nothing, and suspicious looking / known exploits are easier to catch then unknown ones.