I agree that a key concern is how we can get custom info such as blocks entities and such to users, a system like server resource packs are setup now but will inform of outdated data/plug-ins etc. and perhaps point to the download page to update perhaps? Or grab the update from its respective repo.
I’m not sure if this is the right place for this, but I think if there was a way (when the Sponge dev area is created) if you have a plugin, there should be an Auto-updater class built into the Sponge api, where all we have to do is access the class, and use a method to check for an update, and it will compare the latest version on the download page, to the version that the end user is using, if it’s newer, it’ll either auto-download the new version OR ask if you want to update.
I also think that in the auto-updater and the dev page, we can mark what versions of Sponge our plugin is compatible with. That way, if you have an old version of Sponge, it wont want you to or force you to update a plugin to an incompatible version. That way all the Auto-Updating will be regulated, and for users that don’t know how to implement something like that, they will have the resource available.
1 Like
Of course we dont send files, but only packets with prepared blocks/items/entities and others.
“With executable code” It means that packets with block id, texture and some info about block is allowed
Every packet is allowed to be send.
To send a packet to a client mod there is already a way: Plugin Channel
Through this channel you can send customized packets to the client.
But as mentioned the security is threatened when automatic mod installation can be done.
Got it!
will be a difficult task
difficult
but why not? 
I’m going to make a few points here about the mod downloading.
Most mods that are required on the server usually have blocks or items that need to be registered and rendered. There is actually a way, and someone is working on it, to do this without the client needing to download any additional mods.
The way it will work is the server will require to download a resource pack. If they refuse, they can still join; they’ll just see a bunch of missing textures.
After joining, one of 2 things might happen. It’s to be decided which one. Either the blocks will be defined in the resource pack or the server will send some packets containing the info needed to register the blocks. The info includes the ID, material, and texture name. If it uses a resource pack, that info will probably go in a file called blocks.json (similar to sounds.json)
Another thing I’ve been thinking about is GUIs. This is already a thing with sounds (/playsound). With sounds, you can send someone a .ogg file in a resource pack, then have the client play that sound. The same could be said for guis. The simplest way would be to provide a simple resource, then have the server tell the client what do display, where to display it, and for how long.
Gui Screens are a bit more complex. We need to define the uv map, and what to do when the mouse is moved or clicked. It would also be possible to define some inventory slots.
Lots of stuff could be possible with this API.
It is already possible to send files to the client – ever since we could send Texture packs over, and now Resource packs.
Possibly files could be sent over into the client that shoot itself into the main client minecraft files to install them, and all it takes to play on the server is to restart the game?
What part of “security risk” did you not understand? There will be those servers that will install malicious software to clients. Key loggers, back doors, shell access, etc. In order to stop that from happening we have to stop everyone from being able to do it. No automatic mod installs. Simple.
1 Like
I agree with what you said, but there might be one way to eliminate the security threat and that is to have an approval system but that takes time, money and people.
As someone who tries to run a server for friends, I can say that getting the mods to them with all the right configurations and whatnot is the hardest part. Then, when anything updates, I have to go through it all again. I think it is a mistake to dismiss automatic mod installs.
There are lots of things people connect to on the internet that require security and trust, but the problem was figured out and solved. It would be a bummer to not do this, simply because someone would abuse it.
To me, the benefits out weigh the cost. I won’t log into strange servers that my client says needs to install stuff.
1 Like
Regarding auto installer ive been using http://dev.bukkit.org/bukkit-plugins/plugin-installer/ for a month and its amazing
I’m a little on edge about auto-mod installation. Could that lead to malware, I wonder?
Sounds like Garry’s Mod, only for Minecraft. The Auto Installation can be a little tricky, as the server needs to check for Malicious Plugins, which would require a Security System , which could take a lot of time and money. One way I could see this happening, is to implement an Online Repo that a single server can connect to, to gather SHA1 and CRC’s and see if the plugins or mods in that instance are registered with the site, and that they match. That could also have a lot of flaws, as you can always get A) False Positives, B) Accepting a plugin or mod that appears to not have been injected or compiled maliciously.
We won’t send code, only block structures (id, texture, hardness, maybe custom model), entity structures and item structures. No code, no chance for malware.
Doesn’t Soak make this client-side mod installation?
How about you treat minecraft servers like you treat the internet; don’t go to weird off the wall sites and you drastically lower your chances of getting a virus, etc.
The same with minecraft servers, I’m not going to go to any random server and let it download whatever the heck it wants to. That would be silly. I’m only going to go to minecraft servers I trust.
(Old topic but still relevant, OP brought it up on IRC #glowstone++ yesterday, so I’m replying here despite age)
The web browser security model is actually a powerful counterpoint. Could the web have taken off if you had to “trust” every website you visit? I’d argue its success largely stems from the lack of trust required to visit random websites.
This is possible because browsers are heavily sandboxed, running the website in its own environment isolated from the rest of the system, at least to some extent. Of course, browser security isn’t perfect, there have been bugs allowing malicious websites to “break out” of the sandbox, but those are security vulnerabilities intended to be fixed promptly, not an inherent part of the design. Websites can try to exploit bugs or pretend to be other websites (phishing), so it is still wise to cautiously avoid shady sites, but in general it is fairly safe to visit websites.
Since no prior trust is required, anyone can setup a website, and anyone can visit it, no need to negotiate trust beforehand. This is a huge boon for sharing information, since it doesn’t have to go through the bottleneck of a trusted third-party. If you do want to authenticate who you’re talking to, then layers like TLS are available which do make use of trusted third-parties, but in either case, websites by design cannot run code on your system without your permission except in their sandbox.
The current vanilla Minecraft client/server security model is mostly similar to this web security model, where you can (fairly) safely connect to untrusted servers. Some trust is required since you do give up your username (privacy), but Mojang username authentication is even designed to allow untrusted servers since your actual password is only sent to their centralized trusted Yggdrasil server, not the untrusted game server.
An interesting idea, sort of reminiscent of the web plugins security model: ActiveX, Flash/Shockwave, Java Applets, etc. Code could be “signed” by a trusted party to mark itself as trusted. Or a plugin could be acquired through a trusted source, then allowed to execute when loaded by various websites (object/embed tags).
Authenticating the source of the code can help, but still has the downsides you mention. Also, the code might not be malicious in itself, but have security bugs. It is very difficult to write safe code running with elevated privileges, as the web plugin security disaster as shown us (fortunately they are now mostly obsolete). The trusted Online Repo would have to vet the code carefully, and if it makes a mistake erroneously approving bad code, pull the malware and revoke the trust. It is a workable system, but requires a lot of effort and infrastructure and manpower. And trust.
This does seem to be the direction Minecraft is going, a more “data-driven” design. Where much of the content is merely data (usually JSON, example: block models in resource packs), so it can be safely shipped over the wire and rendered without executing custom code. It’s generally good practice and I’m all for it, will be interesting to see how this turns out.
But will data-driving be enough? It should be sufficient for some simple use cases, like adding new blocks with custom textures/models but without custom behavior, or new items with well-defined properties. I think it would cover some of what mods do today, but not at all.
(Sidenote: I can only speculate, but anyone remember when Mojang hired Tahg from the Bukkit team, then he departed a few months later, citing “Creative differences and frequent changes in developmental focus”? Then he started a modded Feed the Beast server, TahgCraft. Wonder what those “creative differences” were?)
Sill would be better than the status quo, but I bet you there are still significant use cases where you really do need to execute custom code on the client. My favorite example of this is the mod Thaumcraft: it doesn’t just add inert items/blocks, but tons of new special behavior, client-side walking modifications, rendering overlays, multi-block structures, and so on. The client cannot (yet?) express this functionality in terms of JSON data. Sure in principle it could, but modification developers are very creative, always pushing the limits, and going beyond the bounds of what is possible often requires client-side code execution.
Then the real question is, how to safely execute custom code on the client? Signed code is one answer (but see above for downsides), another possible solution is sandboxing.
Going back to the web platform security model, where websites run in their own isolated sandbox environment separate from the rest of the system, what if Minecraft did the same?
This is along the lines of what I’m going for with voxel-clientmc, a web-based Minecraft-compatible WebGL client. Of course the first step is getting a usable near-vanilla-parity client working well, but the long-term goal is opening up client-side modification enhancement. Since all of the code is downloaded from the website to your browser and runs in the sandbox, it is already safe (modulo browser security bugs obviously, but those would be a bigger problem than just this project). Untrusted servers can effectively send their own completely custom client. I already have client-side Forge support working (FML|HS plugin channel handshake packets) and Sponge (and Bukkit and standalone) plugin support, but not currently rendering any custom blocks or other content. It would be a large effort, but it in principle should be feasible and have many upsides.
Not that sandboxing doesn’t come with disadvantages. Sandboxed code might run slower, and it has more limitations than native code (no direct filesystem access, no network access except on the same origin or sites enabling CORS, and so on, depending on the sandboxing technique). Sandboxing the existing Java-based Minecraft modding ecosystem is probably infeasible at this point, though there are some technologies e.g. the Java Security Manager (but when I search for it to find more information, mostly the hits I get are about its security vulnerabilities). There is no free lunch…
1 Like