Safeguarding Against Unchecked and Potentially Damaging Plugins

Discussion in 'Bukkit News' started by EvilSeph, Dec 19, 2012.

Thread Status:
Not open for further replies.
  1. Offline


    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.
    Archarin, AlexMl, DanManB and 16 others like this.
  2. Offline


    Yeah I should have used Heroes is my example...
  3. Offline


    So am I getting this right? The only thing this protection does, is using version information in the class pathes?
    And if I want to make a plugin that uses CB or NMC code compatible with a new CraftBukkit build, I have to modify my imports accordingly with this changing version number in the class path, right?
    So that people can "assume", that the author has at least had a look over his code, whenever he marks a plugin as compatible with a new CB version.
  4. Offline


  5. Often? You have exactly one example (at the commit discussion) where it happened at one MC update. Can you give more pls?
    Even with this safeguard this is still the case. I see plugins coupling bukkit and NMS functions to archive their goals. You strip out the NMS parts on updates, so the bukkit calls alone may do unwanted, very bad things like corrupting the world.
    Now? You mean since they started with the API / cleaning code, which was around 6 months ago IIRC.
    Still the same, see above.
    At the comments for the commit server admins told they have that way. You're calling them liars?
    Maybe you should change that instead of adding a safeguard?
    A admin is always responsible for his own security.
    Again: Please give more than one example (that has even been solved long ago).
    Which, again, your safeguard doesn't help.
    Which completely invalidates everything you said above:
    A server admin won't know that a plugin bypasses it nor that it hooks into NMS code.
    Yea, blame plugin developers who use deobfuscated methods only to make sure the code won't break or print stacktraces like done by your safeguard. Very mature move.
    Of couse if affects my update process. If I didn't had to update in the past (and I can give you examples where this worked for a very long time) all I had to do is to check my code. I didn't had to recompile nor to upload a new version to DBO, wasting my time for nothing.
    Why not do this for all plugins using NMS code instead of this safeguard? How do you know that plugins bypass it if you didn't even know they used NMS code before?
    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[/quote]
    Isn't this always the case? It's MY DAMN CODE so who except me should be responsible for it? Also same question as above.
    Because you choose that?
    Which is weird as plugins with dynamic code generation have been accepted in the past (not 100% sure about that, have to ask a developer who loves to use that). Also the methods for dynamic code generation are traceable like Java code is, it's not like they use random generators to generate random code.
  6. Offline


    That's the gist of it, yes.

    mbaxter give a good example of how to use this to enable a plgin to suport multiple versions of nms - so in many ways it can be used to our advantage ;)
  7. Offline


    Correct. If the author just blindly updated, and you update the plugin, you will be better able to narrow down which plugin caused your problems, as you will only need to look at the plugins you recently updated as opposed to all plugins.


    Welcome back!

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 30, 2016
  8. Offline


    1.4.2, 1.4.4, 1.4.5 - All of these had a plugin - I'll not name them - which caused commands and chat to completely stop working. The plugin loaded, no errors were generated, but it completely broke servers and was only discovered by removing all plugins, adding them back in one by one. This commit would have stopped that plugin from loading until the dev released a new build and the admin updated that plugin.

    That plugin caused our team to look into bugs for about a day - bugs that were a red herring.

    Since when is welcoming you back trying to put down your reputation?
    elias79 likes this.
  9. Offline


    Well, this new mechanic will cause server admins to wait longer until they update to a new CB build, because now the are forced to wait for an update of those plugins, even if an old version would have been still usable.
    I understand that such a mechanic is basicly a good thing.
    But even without it, it was always the responsibility and risk of the server admin to choose, whether or not to use old plugins - for the sake of not loosing players by wating too long with updating his server.

    Whenever a new MC Vanilla version comes out, our player counts drop rapidly, because all of them want to explore those new features in Singleplayer. And if we run a vanilla server to make them stay with us, they are still repelled because a vanilla server is not really controllable and maintainable when exceeding a certain amount of players.
    Even with a whitelist there are always players who start to destroy things, because they know, they probably won't be catched without LogBlock, AntiCheat and stuff.
    That surely is a disadvantage for server admins.

    But personally I'm ok with this, because plugins that are no longer maintained will sooner or later break a server.
    And sometimes even destroy something in the proccess.
    (Like old iConomy did for us once...)

    I just tried the new build and saw, that 7 plugins broke. Including LogBlock and NoCheatPlus.
    But we will adapt to it, as we simply have to.
  10. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

  11. Does this corrupt the world in any way? Removing plugins one by one (or better 50% to 50%) is the first thing the admin should do. If he doesn't why do you even listen to him?
    It is cause you tell I left but came back so my opinions aren't stable behind the lines.
  12. Offline


    If you are already using dev builds of CB immediately after a MC version release, then you should be fine using dev builds of plugins. Due to the inevitability of bugs that occur after a MC release, we often cannot promote a CB build for at least a day or two. In my experience, developers often have at least a dev build of their plugin out in time for the promoted build of CB, and often much earlier.

    Besides, all that is moot if you run a plugin which would break anyway - as it is very likely to do when a Minecraft update comes out. If that plugin is a core plugin of your server that you can't live without, you would still need to update it. Even if it didn't break before, the upcoming 1.4.6 and 1.5 versions of Minecraft would very likely break them, since the Minecraft code is getting shaken up quite a bit in the upcoming versions. This is what we can see from the snapshots/pre-releases.

    By your logic we should only do this if they cause massive world corruption, not many other silent issues that cannot be tracked down. Is it not better to have the ability to track down which plugin broke the server, rather than blindly guessing?

    You left. You came back. I welcomed you back. Not sure how you can blame me for your reputation being damaged as a result of those actions.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 30, 2016
    CubieX likes this.
  13. Offline


    Ah go on i'll take that bait!

    How can anyone give a concrete example of something that is potential?
    We're talking about future edits to NMS. And with the API rewrite begun - these changes are getting bigger and more frequent.

    Not sure i followed that. IF it was trying to say what I think you where - NMS isn't gone - just renamed - people CAN still use them. Just that they SHOUND now check when MC updates to make sure it all still works.

    With the extensive work being done

    He used Past tense not present. And yes NMS changes have impacted my plugins every MC version change now.

    Your first sentance implies that all bukkitdevs say when they use NMS code, or carefully list changelog/commits/source code. they don't.
    Then your second sentences suggests you think it should be changes so they do have to? So which point are you following - you swiched to an opposing view point in just 1 sentence. Achievement unlocked!

    I didn't realise I was using a Craftbukkit class till just today!

    How can he do that without accurate information? How can they secure against the unknown?

    Again: How can anyone provide example of a potential outcome?

    Your saying this safeguard in no way provides any kind of incentive for devs to check against new versions and release confirmed working versions? Wow - how jaded are you?

    Cept for the comments on their plugin and their reputation. If someone does update/bypass without bothering to check their code is comparable, they they clearly have taken an action to make their plugin run - but not work. Why do half the job?

    Wow your first correct comment. It is indeed mature to blame people who workaround rather than FIX their code. (oops sorry didn't notice your sarcasm).

    For quite a few releases now I have HAD to update whenever the MC version changed. This is only going to get worse as MC core is re-written. So you'd be in a situation where you have to update each release anyways.

    Bukkit moderators DO know when code uses NMS? server admins don't. And they never have supported NMS use.

    If I use Block.setType() in my plugin and all the diamond in the world becomes stone. That's bukkits issue to fix.
    If I use and block etc and the same -happens it's may fault. Because , YES I chose to use code that changes each update.

    Wow - way to miss the point. he said "any bypass that includes dynamic code generation" not any plugin.

    What you seam intent on missing is that the NMS codebase is going to get even more volatile over the coming months. Bukkit have put in a versioning system so that your plugin only works when the correct NMS is present.

    This is a good thing not a bad one. You just actually have to check and validate your code every time Mojang release a new server build. I know I already did this, don't you?
    slipcor likes this.
  14. vs.
    No you can't. You completely missed the point. The point is what happens if a plugin uses NMS code (not in onEnable, so it won't be disabled) to finish actions started with bukkit API calls?
    And who are you to talk for every single dev out there? Just use deobfuscated methods and see what happens then...
    I said server owners told they have the way to see if a plugin uses NMS code. EvilSeph says the opposite after that so he calls them liars.
    Replying to something you didn't follow closely. Achievement unlocked!
    Completely off-topic. If you didn't it doesn't mean other server admins didn't. Do your job better then.
    Give the information in the first place? Like told before:
    They told this was a issue before this commit, so they should be able to give examples.
    What if a dev uses a workaround? What if a dev just use "find and replace all"? How shortsighted are you?
    Why did they do in half the job (none of the job) in the past?
    You readed the "who use deobfuscated methods only to make sure the code won't break or print stacktraces like done by your safeguard", did you?
    So you know the future? Please give me your crystal-ball. Before you say "But staff told the nighty-builds show it" - that's not true for everything.
    They told different in the commits comments. Again: Replying to something you didn't follow closely. Achievement unlocked!
    Not only that you gave exactly the one example I was talking about that staff gave instead of a new one, you also just prove my words. Thanks.
    What makes a bypass in a plugin different than a plugin? Also again you don't know what was told before: All plugins using dynamic code generation are disallowed (from now on?).
    Why should it be more now than in the previous 6 months? They are still cleaning up codes, they are still preparing the API. But yea, you know the future.
    That's your opinion, mine is different. That's what opinions are for...

    BTW: This questions was for staff, not for some random guy without the needed information to reply to it.
  15. Offline


    Any sever admin that cares about his server will be running a test server for the purposes of testing plugins, whether it be adding a new one to their server or updating to a new version. If they are irresponsible enough to not test before putting on a live server, then in my opinion their server deserves to be "broken" all this change really does in the long term, is protect irresponsible server owners.
  16. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    Many of the issues that this change helps prevent are ones that you might not notice in a test server, such as issues quietly and slowly changing occasional chunks or setting a value that isn't checked while you test but comes up two days into running production. These are issues that don't point to a specific plugin, but rather are due to the plugin meddling with a value that is unsafe to change in a newer version of minecraft.
    slipcor and TnT like this.
  17. //EDIT: If you can't you are just speculating, which I do when telling the same can happen with the safeguard, too.

    I didn't completely left in the first place. Which you see a bit in my goodbye thread (can't make it more clear there...). I'm completely away after I updated all my plugins for the next RB.
    So yes, telling I left, then came back (which didn't ever happen in the first place) indicates my opinions aren't stable, hence it damages my reputation.

    So non-functional commands or chat is silent? Again: Give examples (more than the one you always give).
  18. Offline


    Actually you cant say my opinions invalid - just as good as yours tbh.

    Yes I DO know the future. Mojang are working on MCAPI, I've placed several MCAPI proposals myself and therefore I am helping shape this future, and it is clear from the comments Mojang staff have made on those proposals that major rewrites the the core of Minecraft will be made over the next year.

    EDIT: MC 1.5 is called "the Redstone update". Do you really thing its not going to have some quite radical changes to NMS?

    I've quite aware of the scale of NMS changes that have already happened, and plugins that use them as one of my plugins is a bridge for getting health information about entities. 'Most every plugin I support with it has had to update for every MC update since at least 1.3.5.

    So armed with the knowledge that every MC update breaks many NMS reliant plugins, and that this is only going to get worse... I clearly see the need to force devs to ensure even a courtesy level of checking in their NMS dependant code.

    Yes someone can claim to have 1.4.6 compatible code and just do a find and replace. But at least by taking this shortcut they are actively choosing to deceive, and they have to live with consequences when discovered. What this will stop is any hidden bugs caused by an NMS reliant plugin appearing to work after upgrade but silently causing unpredictable, possibly damaging consequences- the admins that didn't choose to use NMS code.

    I'd rather a server-log full of ClassNotDef errors to alert me, than a future filled with bigger and bigger, harder and harder to find bugs.
    slipcor, TnT and mbaxter like this.
  19. Where exactly did I do that?
    Just like it was the last 6 months. Again: Why is it different from now on?
    To redstone related code maybe. MAYBE as it could also just add new redstone things. You are speculating here.
    How is this different to what we had before? If a dev chooses to not check its code against updates it's his problem, like it is now if he chooses to use a workaround / lazy replace the imports.

    You see me replying to less and less of your points as they are already discovered / waiting for staff reply...
  20. Offline


    No its not HIS problem! That's the point...
    If I release a plugin with 1.4.5 reliant NMS code in it. I can't know it will work on 1.4.6.

    So out comes a 1.4.6 beta, and server owners update. My plugin will stop working. Instead of potential issues it just stops. I can then get a release out - and all is well. Instead of damaging a server - my plugin just failed.

    The point is accidental running of NMS code on the wrong version of NMS is prevented.

    Sure I can claim to update and just push out a find and replace update - but it want be accidental bugs then - it'd be my fault for being a twat!

    Also to reiterate - as you are hung up on it - POTENTIAL problems. We cant give example because the playfeild is changing. Personally I trust that Wolvereness who committed the change has spoken to EvilSeph who DOES know what is planned happen in the next 6 months.
  21. Alas, those "quite issues" are those that are not prevented for the case the dev blindly updates or even bypassed the commit in a generic way :).

    Up to now it has caused irreparable damage including devs leaving and server owners deciding to leave CraftBukkit (affected but probably not too much touched player base: easily ten-thousands), plugins getting dropped, updating overhead, delay for sever owners, heated "discussion", damage of trust (communications, attitude, ...), other. Not sure what people want to use to reason for bringing in the change with 1.4.5 ... one might assume the internal reasoning goes like.... "let's do it in the 1.4.5 RB right away, so people update and we get less tickets for the 1.4.5 RB, so we have more time for 1.4.6 etc.". Bringing it in now is not necessary to prepare the change in 1.4.6, package re-naming has effect once applied, so there must be some reason for doing it now, other than "volatile"/"Minecraft will change a lot" etc. It might have been a fair trade-off to announce it in time and bring it with 1.4.6 instead, with or without "discussion".

    It seems that alternatives to rule out mismatching versions have not been evaluated too deeply, at least no details have been communicated. Neither could i see any attempts to make use of the community of devs to help to judge this and other solutions earlier on. Instead of addressing devs in time, they were "forced" to update and even got called names (potentially).

    If ruling out plugins that did not explicitly update and also won't update will make the day for the ticket-team, is an interesting question. For all other cases it will be uncertain if this change leads to better quality plugins, and in effect less tickets. The current system also does not help to distinguish a dev build of a plugin from a version uploaded to BukkitDev. Correct me if i am mistaken, but do double check pls :)

    This variation might turn out to be somewhat good, to be evaluated within the next months.
    madmac likes this.
  22. Offline


    There is no unneeded "fire and brimstone", the problems this safeguard addresses have the potential to range from really small: Minecraft code used by a plugin no longer exists in an update to really big:
    • A function that just checks if a chunk exists now deletes crucial chunk data.
    • It still looks like chunks are fine..
    • ...until a Minecraft update comes out and all of the chunks start regenerating for some unknown reason.
    • You realise you have no idea what chunks are affected and what chunks aren't
    • You realise you don't know why the regeneration is being triggered.
    • So... backups are useless at this point because you don't know the areas affected and you don't know how long you have had this problem.
    As much as you'd like to say this is us being "dramatic", the fact of the matter is..this is a valid scenario because how Minecraft code changes is completely unpredictable.

    We needed to get this announcement out and have been working on this and all the other announcements for the past week. We're working on the tips and tutorial writeup I mentioned in the commit discussion and will update the main article when it is done.

    Until then, see what mbaxter wrote as it is what we're working on:
  23. Offline


    Hey guys did you hear? WorldGuard, WorldEdit will now break on every minor Minecraft update. So in case of Minecraft 1.4.x versions, up to 3 times! :)
  24. Offline


    Will these dumb changes never stop? By making some of the classes final you've basically killed off the majority of SpoutPlugin. No Custom Blocks / Items, all of our inventory methods are not pretty much dead. Thanks, your just making the case to get people to move away from Bukkit.
  25. Offline


    They already did. That's why they released updates frequently, watch betas and update before its an issue.

    Difference is - now the broken one wan't run at all.
  26. Offline


    Please go on and explain how backups can be useless because you don't know what chunks could get affected? I really do care to know, because (and this is just a logical assumption) if the chunk is never loaded by the server, how can a plugin affect an unloaded chunk because of volitale code? Really even with my 2.35gb world save, if I need to replace things with a backup, my players will live and be able to deal with the situation. I think you guys tend to forget that humans can be understanding and compassionate towards others, and we also know what were getting into.

    Even in your example, only called chunks can be affected, which means that you just
    A: tp to the affected region
    B: pull up the map data using a tool like world edit and
    C: replace the file from a backup and delete the offending plugin.

    Look everyone know when you mod something you run the risk of corrupting data. All this is trying to do is restrict the modifications of the community and force people to use an api they rather would not use. Let them have their freedom to take that risk, and let server admins take the risk of dealing with the consequences of that plugin if they so choose to use it.

    It seems as some of the developers have seemed to pointed out this is just you guys trying to shift the blame onto them, as it makes it harder for unreliable code in both net.minecraft.server and org.bukkit.craftbukkit to be exposed by plugin's using them (Get rid of the plugins exposing sloppy code, get rid of the problem right?). You guys are human too and you do make mistakes. But not officially informing the community before today was a mistake. You're causing headaches for everyone involved including yourselves.
    afistofirony likes this.
  27. Offline


    EvilSeph I understand, I just felt the wording came down pretty hard on devs.

    Devs aren't the enemy, most of us want to make good plugins.
  28. Offline


    Thanks for making it 20x harder for anyone to continue my plugins when I'm gone, I seriously hope you will do the total obfuscation of CraftBukkit you had planned, because I like to see this place burn with anger from all parties involved.

    And still no reasoning for all these changes other than '25 ways to hide the truth' types of replies. Come on Bukkit, we all know you are hiding something, what is it you are trying to hide? Is Mojang forcing you to do this? Copyright problems? Do you have to scare everyone away that doesn't use the Bukkit API so people are more willing to join up with MC API?

    This comment will be deleted by the 'appropriate commenting police' in 3...2...1....
  29. Offline


  30. Offline


Thread Status:
Not open for further replies.

Share This Page