Safeguarding Against Unchecked and Potentially Damaging Plugins

As Mojang continue to work towards the Minecraft Plugin API (cleaning up and rewriting the code), the code within Minecraft and CraftBukkit will undoubtedly shift. Fortunately, as the majority of the plugins available have been developed using only the Bukkit API (which was designed to be resilient and mostly update proof), this code shifting should not affect most of your servers.

If, however, you happen to be running a plugin that uses code outside of the Bukkit API (like Minecraft or CraftBukkit code), those plugins are highly likely to break and bring down your servers with them - often without any advanced warning - whenever a Minecraft update is released. In response to this very real problem, we've had to make the difficult decision of forcing plugin developers that use Minecraft and/or CraftBukkit code within their plugins to re-evaluate their work with the release of every Minecraft update to ensure they are still functioning as intended.

It is important to note that even if a plugin you have been using has been working fine across Minecraft updates until now, there is simply no way to guarantee that this will always be the case. Making the assumption that it will work with every update is like playing Russian roulette with your server.

The problem:
With the extensive work being done to Minecraft to accommodate the Minecraft Plugin API, the Minecraft code is now more unpredictable and volatile than ever before. These changes have made it clear that allowing plugins to run unchecked across Minecraft updates is a big mistake that puts your servers at significant risk of being silently damaged. Neither Bukkit nor plugin developers have any control over the Minecraft (and, as it is built upon Minecraft itself, CraftBukkit) code. Therefore, if a plugin uses code outside of the Bukkit API and it has not been verified to work on the Minecraft version your server is running, using it can only lead to unpredictable problems.

What makes matters worse and more confusing is that there is no easy way for you, as a server admin, to tell if the plugins you are using utilise only the Bukkit API or unsupported code within Minecraft and/or CraftBukkit itself. As plugin developers have no incentive to do so, they have not been putting up a notice informing server admins that their plugins use more than just the Bukkit API and thus server admins are left in the dark. Without this important knowledge, server admins have been blindly running plugins that are not ensured to function as intended across Minecraft versions, potentially and unknowingly putting their servers at risk.

Up until this safeguard was introduced, plugin developers were not required to verify that their plugins continued to function as they intended whenever a Minecraft update came out. As a result, potentially unstable plugins have been running unchecked on your server with no indication that they could damage your server at any time without any advanced warning. The fact of the matter is: plugins that depend on Minecraft or CraftBukkit code need to have their code verified whenever a Minecraft update is released before it can be said with absolute certainty that a plugin is safe to run on your server.

In summary:
- Mojang is cleaning up and rewriting the Minecraft code in anticipation for the Minecraft Plugin API.
- Plugins that use Minecraft or CraftBukkit code will break in unpredictable ways.
- You aren't told that a plugin is using unsupported and volatile code, so you likely aren't aware that plugins you are using could be silently breaking your servers.

The solution:
To address this problem, we've made the difficult decision of including a safeguard directly into CraftBukkit. This safeguard serves many purposes but the major ones are: it will help protect your server against unchecked plugins, it will make determining which plugins are breaking with every Minecraft updates and it will force plugin developers to take responsibility for what their plugins do to your server.

With this safeguard in place, a potentially damaging plugin will not be able to run until it has been updated with a version that has been checked by the plugin developer. Granted, plugin developers have the option of completely bypassing this safeguard and putting your server at risk. However, if they choose to do this it will be very clear who was responsible for any damage done to your server and you'll know to avoid that developer's work in the future.

Note: this safeguard is not intended to stop the use of code outside of the Bukkit API, but rather to promote more responsible use of it if a plugin developer decides to do so.

So what does this safeguard mean for you?
Server Admins:
If you are a server admin that only uses plugins developed against the Bukkit API, this safeguard doesn't affect you at all. If you are a server admin that uses plugins which use Minecraft or CraftBukkit code (which we do not support or recommend using) then this safeguard means that those plugins will need to be updated with every Minecraft update.

It is important to note that while this safeguard does force plugin developers to take some sort of action to get their plugins built against Minecraft or CraftBukkit working on a new Minecraft version, plugin developers have the option of bypassing it. They can blindly update a few lines in their code to mark it as working with a new Minecraft update or utilise a bypass to trick the safeguard into letting the plugin run. As such, we recommend that server admins be wary of plugin developers who decide to work around this, as they are willingly putting your server at risk.

Plugin Developers:
If you are a plugin developer that purely uses the Bukkit API this safeguard does not affect you in any way.

If, however, you depend on the extremely volatile and unsupported CraftBukkit OR Minecraft code, you will now have to re-evaluate your plugins with every Minecraft update release. As this is what you should have been doing anyway as a responsible developer, this should not affect your update process in any way.

We are not trying to make utilising Minecraft or CraftBukkit code within your plugins more difficult, we are simply trying to promote using it more responsibly if you have a need to do so within your plugins. If there is no way for you to avoid using the volatile and unsupported internals of Minecraft or CraftBukkit, we recommend trying to work with us to design an addition to the Bukkit API that removes this need.

What if I'd rather take the risk?
Server Admins:
If you'd rather put your server at risk by running unchecked code, you are free to bypass this safeguard, however you will no longer receive support from us as a result. If you'd still like to bypass or disable this safeguard, you have the option of running an unofficial build or a tool to update the plugins you use. Unfortunately, since providing support for code we did not write is next to impossible, we still do not allow the discussion and distribution of unofficial builds within our community.

Plugin Developers:
Plugin developers bypassing this safeguard are willingly putting servers at risk with their unpredictable and unchecked code. If you as a plugin developer choose to bypass this safeguard bear in mind that you are taking full responsibility for anything your plugin does to a server and that this decision can affect your reputation as a developer.

There are several ways to bypass this safeguard that I'm sure many of you will be discussing on these forums, however, we would like to make it clear that plugins using any bypass that includes dynamic code generation will be denied from BukkitDev without hesitation due to the inherent security risks it poses for servers.

Whether you are a server admin or a plugin developer, you are free to discuss ways to get around this safeguard provided it does not involve an unofficial build. The issue with unofficial builds is that regardless of where people get them from, we almost inevitably end up having to provide support for them.

We know that this safeguard might cause a few of you some headaches, however we feel that choosing to let servers burn in the coming weeks is not a viable option. Thank you for your continued support, cooperation and understanding in this matter. This was a difficult decision for us to make, but preventing unchecked plugins from silently destroying servers was a big incentive for us.

 

Here's a pretty good explanation.

 

FYI, the way I note compatibility issues is best exemplified during startup of the server. For example, a wonderful plugin I use proclaims the following at each and every startup:

Code:

2012-12-24 09:39:20 [INFO] [DeathTpPlus] Enabling DeathTpPlus v3.9.16.2320
2012-12-24 09:39:20 [INFO] [DeathTpPlus] allow-wordtravel is: yes
2012-12-24 09:39:20 [INFO] [DeathTpPlus] Configuration v.3.4 loaded.
2012-12-24 09:39:20 [INFO] [DeathTpPlus] Config is up to date
2012-12-24 09:39:21 [WARNING] [DeathTpPlus] You are running on an newer CB Version
2012-12-24 09:39:21 [WARNING] [DeathTpPlus] There might be issues, just letting you know
2012-12-24 09:39:21 [INFO] [DeathTpPlus] is up to date at version 3.9.16.2320.

Isn't that nice? It's so friendly, nudging me that despite the fact that the plugin itself is the latest version available, it might not work because I'm using a version of craftbukkit almost two MAJOR versions than it was intended to work with. It's still working by the way, although I have no idea if it's because of not using this "NMS" thing (I'm assuming it's some kind of linking and/or redirecting core server code? Wasn't explained in the first post, so I'm going to have to go back probably and reread about it...) or not, but just having that nagg is better than the plugin being shot dead without a chance to prove itself.
I actually run a separate server for my own testing purposes for updates to craftbukkit. When something breaks, I have a special folder I put the plugin .jars in. It's called "Broken", fancy that. And until the plugins work (or I find a suitable replacement), I don't update. If that's not easy, I don't know what is.
For what it's worth, I have never had any plugin destroy data that didn't explicitly state (usually in big and or colored letters) that it could do so. If I was blind enough to ignore developers that go out of their way to warn me of such things, I have no grounds to complain when things go horrible wrong.

 

I read it before, I read it again, it still doesn't answer my question. The minecraft plugin API will replace Bukkit, correct? The minecraft plugin API will require at the very least, refactored plugins, correct? Then why bother with a "safeguard" now? I understand that code is being "shifted" but the code has been shifting literally since bukkit showed up. Is the code really shifting so much more now that it is worth disrupting so many people? Am I just missing the huge outcry over plugins "destroying" servers because of NMS code?

 

lol
infinite loop ++

A fix for this issue would be a lot more helpful than re-reading this thread.

 

Before the minecraft API comes out, the internals are likely to undergo drastic changes that will majorly restructure things. The safeguard is being added because plugin developers have, as a whole, not implemented any form of version checking and with the impending major changes this would very easily screw over server owners.

Apologies for the link answer, I couldn't help myself

 

Are the changes somehow drastically different than the changes we've had to deal with in the past? Every update I have to manually fix the obfuscated functions i use, because if I don't they either don't work right or simply won't let me compile the plugins because they point to functions that no longer exist - how would that change in the future?

I understand, more than you'd ever know. I appreciate your willingness to at least discuss the issue

 

mbaxter

I KNEW it! This change is just so you drop all developers that use NMS. Why don't you just say that instead of repeating that 'it could damage'?

You can not 'prepare' for changing to the API. This change will not 'prepare' us, it will merely make it harder to update the plugins. Instead of making it all this hard, just update as normal, and when the API comes out, everyone can update their plugins to work on that. It is a lot less frustrating than the endless re-uploading of plugins.

If preparation for the MC-API is a concern, then doing version checks like this will not help with that. Waiting for it be actually there, and then forcing it, would make a lot more sense.

 

No, you read his reply wrong: It's not the preparation of plugin developers for the MC-API, it's the preparation of Minecraft for the MC-API - it's the fact that, to accomodate the new API, the internals of the Minecraft server and client will be changing: classes might move, methods might disappear or appear or be refactored into other classes...
Even though you could previously have been relatively safe with Minecraft updates, merely changing a letter here or there, with the push towards the API, Mojang will likely be moving code around and refactoring the internals of Minecraft itself majorly, such that this will no longer be a viable approach at all.

 

lukegb
Aha that makes more sense, but can we also expect Bukkit to improve it's API as the Mojang team prepares the API? I can assume that if, for example, Mojang does 'big changes' to allow custom block types, Bukkit would stay updated with that to support this feature too?

It's a bit confusing here, because the internals will change because of Mojang working on the MC API, yet there is no MC API available that developers can use. Why publish new Minecraft versions of only the MC API internals when no MC API is there to support it? Wouldn't it be a lot easier to just have a feature-freeze for Minecraft and have a separate project running that has all these changes?

(or is this one of those infamous decisions that were made without further questioning?)

 

To me (and I could be wrong) this a solution that tackles many problems at once that the Bukkit team struggle with on a constant basis.

1. Plugin/Mod developer relying on MC/CB internals and being comfortable with that instead of trying to contribute to the Bukkit-API (where possible). Changing the names each release of Minecraft turns up the heat on developers hopefully just enough that it nudges them in the direction of the API and possibly contributing to it.
2. Making bug reports easier and quicker to deal with by sorting plugin/mod related errors from bukkit related error a little more easier.
3. Obsoleting plugins/mods that are no longer maintained which will hopefully spur server owners to find alternatives or another/new developer to take over or start a new plugin/mod. Plugins/mods that are abandoned are a ticking timebomb that are either going to crash and/or damage a server (probably a rare thing) or are just going to stop working and leaving server owners with nothing.

That's all I can think of at the moment but it seems like a hard choice that the Bukkit team felt they had to make. Plus I don't think they wanted a band-aid solution that might have changed their long standing position that they do not give support (but not stop) people using the MC/CB internals.

It shouldn't have to be a hard pill to swallow considering they have always stated that the internals can an will change at any time with no notice, hence the no support (it seems it would tie their hands too much). It's unfortunate that some developers feel the opposite.

I don't mean to offend anyone here on either side and if I have, I'm sorry for that. It's not my intention (considering I'm new here, not a dev, and only a private server op/owner). Hopefully I've contributed some interesting.valid points.

 

No, as said many times, the real problem is that this update don't let admins the choice to allow or not outdated plugins by themselves.
As said before, it's just a dirty way to force developpers to change their habbits, and you don't have to be particulary smart to understand that the Bukkit team have took hostages on the pretext of secure us, when i can't imagine a single serious admin not backing up automatically bukkit to avoid this kind of problems (hey why don't you tell us that there was a nuclear risk of war in our servers with old and dirty developped plugins bukkit team?)... It's just very very irritating to be treated like stupid idiots.

 

The lack of options ( allowing outdated plugin to try and run) is what irritates me about this.
If all the devs have to do is add a few lines of code to their plugins to make bukkit think it's ok, implies ( at least to me ) that there is some simple check that bukkit does on each addon.

All I'm asking is that the bukkit guys allow me to bypass this addon check ( or give me the option to configure bukkit to treat every addon i try and load as 'checks out ok'

Give me the option to see if these things will run or not run.

Saying it's not possible to do makes no sense to me.

 

A plugin may run without error report, but slowly corrupt your world in such a way you don't notice for a month. All this change does in ensure plugins doing really risky things are up to date. It doesn't even have an effect on most plugins.

 

so, some plugins can cause errors, like regenerating world chunks that already existed, and we wouldn't know which chunks they are and can't fix them anyway....

 

Yeah that's what i said, there's a secret weapon of mass destruction in our servers, it's called "incompatible plugins with the future minecraft plugin api for dumbs", pff...

"Oh thank you god bukkit from preserving our server from this menace, we, the stupid admins that can't choose and think by themselves".

 

If that happens, then we, as the owner / operators are to blame, since we allowed them to run anyway.

Oh wait.....we can't allow them to run, since our hands are tied.

Let me reach out to the plugin dev and post on their page that hasn't seen any action or updates for 7 months.
I'm sure that it will be updated soon.

In reality, Bukkit doesn't really see if the plugins are up to date.
All it does is check and see if the plugin dev went in and updated a few lines to tell bukkit that its up to date.

The evil plugin menace is still there. This safeguard is just a facade that is making it very difficult for server operators.

All I want is an option to load them anyway.
If it corrupts my server then I take full responsibility, like I always have.

 

Ok, i don't want to beg and cry after developpers to update their plugins every times mojang and bukkit do an update (when they work free for us), i don't want to have to wait and change every plugins each times for every minor updates when the only thing the plugin needs is a line in it, cause updates will become a pain, cause update roadmap are shortenning, and maintain a server will become a hell.

So the best option is that bukkit dare to ask to the community if they want the ability to turn this off or not. A simple poll nothing more.

 

Or you could use a hex editor.

 

u wot m8?

 

This commit prevented many of the renames that happened in 1.4.6 (for code sanity and fast updates) from breaking servers. Those plugins that everyone is upset about us stopping from loading would have broken anyway, but instead of breaking gracefully, they would have broken horrifically, and to disastrous results.

As a server admin, without this commit, you'd still be scrambling to get your plugins updated, as well as scrambling to undo all the damage these plugins could have caused. This isn't a matter of letting these plugins run and hoping they will work, they won't. They're already broken. We need to be able to make these changes for code sanity and to ensure fast updates. We warn that internals are volatile. The API is stable. If there is a need for an expanded API, provide a use case.

 

Well said. I am really more turned off at the community's outcry every time a breaking change is necessary than at any actual changes/decisions the Bukkit team has ever made.

To everyone else: Imagine if they just let NMS code run unchecked and your whole server was slowly hosed? Would you rather have broken plugins until they can be updated and tested, or would you like Bukkit to trash your entire server?

This is not a question of "if":

Read that carefully; this statement doesn't mean "we broke it on purpose because we're Bukkit and we said so," this statements means "Mojang changed the meaning of function net.minecraft.x(), which we at Bukkit have NO control over, and now instead of the function saving a change AND updating the world, it just updates and doesn't save anymore" (hypothetical example). Imagine you run your plugin for a month thinking everything is working, and oops server needs a restart and your map is full of holes and missing stuff, your premium players are screaming for their special locked chests with custom enchanted items back (along with weeks worth of work) and it's not even in your backups because it's been silently failing to save THE WHOLE TIME.

<sarcasm>Yeah, outrage over a version number in a package name is REALLY the way to go here. </sarcasm>

 

ok guys , this damn safguard is a pain in the ass for any casual plugin developer.
"you know ... theres ppl out there who aren´t unemployed yet. pls make it more difficult and time consuming so that in the end noone can enjoy using plugins anymore. best is to shut down MC and CB development for good. MC is dead!"

 

Casual plugin developers don't touch code that this safeguard affects.

 

Your an idiot.

 

Correct. I guess we should all make our voices heard as well as to not make this a very one sided debate, of sorts.

Courier has always been a Bukkit API only plugin, and when new APIs have been required for the functionality users have requested we've just had to wait. Before the two BREAKING API changes in v1.4.5 R1.0 forced my hand I hadn't made a single update to the Courier jar I uploaded to BukkitDev in March.

Server owners like no-fuss plugins.

 

So all I have to do after an update is edit a single character in the imports for a plugin, then recompile it, reupload it, and it will run ... no matter what happened to the underlying NMS and CB code that's imported?

That's a "safeguard"?

 

From the first post:

 

They also said that they changed code, correct? So shouldn't some of the method signatures change as well?

 

So this isn't about safeguarding at all. It's about pointing fingers.

 

No, it's about safeguarding. If people bypass the safeguard in an unsafe way and break things due to carelessness then we point fingers.