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:
- Downloading mods. Solved by using Maven, Apache Wagon, and a maven repository exposed by Ore.
- 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.
- 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.
A curation and review process would (as far as I can tell) seem the only semi-sure way of preventing malicious scripts.