Now that sponge plugins will be able to be used client-side, and we will have something like ore… Do you think that Sponge could possibly make it so that a mapmaker could include “ore ids” for plugins that the client could download (prompting the user first) so that the mapmaker could augment their maps with plugins, perhaps extend functionality quite a bit? I guess map makers could do it like they do resource packs now, just have a zip file and tell which folders / files go to which locations. Still, in an ideal world I think that a mapmaker should be able to distribute a map zip file that contains the resources and a plugin list and the client could handle the rest.
1 Like
This has been made clear numerous times over. Regardless of the kind of advantage, Sponge will NOT handle downloading plugins and/or mods to the client on its own. The reason remains the same: the security risks outweigh all benefits.
2 Likes
Even when requesting permission from the user themselves AND only downloading verified safe mods from sponge’s own repository? Seems counter-intutive to dismiss the idea entirely. Even if sponge does not officiate it in some way I think another mod could perhaps do this too. It would be nice to have in a client-side implementation of the official Sponge though, rather unlikely. If everyone would get out of the “we’ve been over this” mindset and actually think of ways to make something possible maybe we could do something cool. So chill out.
1 Like
Did you even read the whole post?
@Topic
I like this, just because of the sheer amount of things people could do. Minecraft revolves around creativity, so why obscure that idea?
2 Likes
“prompting the user” has been discussed before. its been stated that its not gonna be in sponge itself, but i never said we can’t do it ourselves. i actually said that in that post too; but no matter how trusted a person is, we still can’t just -assume- the file would be safe even with all the safechecks. of course, that problem is left up to whoever creates that system.
1 Like
No, a thousand times, for the million reasons that have been discussed about this beaten horse.
While this shouldn’t be directly built into Sponge, i’d like to see a plugins implementing this. This way every user can choose if he goes down the risky road (installing said plugin and get automated dl) or if he prefers staying safe (not using this plugin and dl all needed dependencies manually off ore).
This way everyone is happy and the security issues would be minor.
Sponge would have to provide a way to get the plugins off Ore and a way to get all needed plugins from the server ofc.
AFAIK they’re already working on that way - a package manager for Ore 
In case it’s not apparent what I mean, here’s a pseudocode example:
$ oreget wardenac [-v version?]
4 Likes
TBH, just the fact that Ore will be released means that plugins could do this - even against the server owner’s will. Just takes a minute to copy the code from Ore and, bam, you can download plugins from the server. This is just one of the cases where plugin developers will need to be trusted to go through the proper verification, and server owners will need to be wary of what they download.
Maybe, to use Ore, the server owner would need an account on the website to download things? This way they would HAVE to give their credentials, and get rid of the chances of malicious plugins just downloading things?
2 Likes
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