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

    EvilSeph

    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

    deadlock989

    That's what I thought.
     
  3. Offline

    TnT

    If this commit isn't bypassed, it effectively safeguards servers. If it is bypassed, then your server is placed at risk by the plugin developer who bypassed that safeguard.
     
  4. Offline

    deadlock989

    So, just to summarise, if a plugin developer was using Bukkit or NMS classes (the very same classes that Craftbukkit itself depends on completely) then they were cruelly putting server admins at horrific risk, since the plugin was still allowed to run after the server was updated to a new version but the plug-ins weren't checked and just plonked onto a live server without thinking. And it's 100% the plug-in dev's responsibility when this happens, not anyone else's.

    So to safeguard these hapless server admins, who are utterly helpless and completely responsibility-free and also (completely coincidentally) sending the Crafbukkit team a lot of messages, the decision was taken to break all plugins that use those classes, every time Minecraft updates.

    End result is a huge array of broken plug-ins, more devs who don't feel like sharing, and, judging by the traffic on this site saying OH NOES MY SERVER IS BROKENED exactly the same kind of miserable traffic complaining about it all.

    Nice move. Look forward to the rename of "beta" and "recommended", I'm sure that will help tremendously.
     
    luciddream likes this.
  5. Offline

    desht

    If you don't like it, why don't you ask for your money back? Or move to a different server mod? Or maybe you could maintain your own fork of CraftBukkit?

    I mean, seriously. Do you honestly think the Bukkit team did this just to make your life more difficult? Or *gasp* perhaps they have a better understanding of what goes on inside CraftBukkit than you (or I, for that matter)?

    Very very bored of all the bitching now and I'm speaking as a plugin dev with an NMS plugin who has to update every MC release. Guess what? It's not that hard.
     
  6. Offline

    hatstand

    Oh, the irony.
     
  7. Offline

    TnT

    That is not a good summary at all.

    Plugin developers who tie into server internals are using volatile code. By not checking that code between Minecraft updates, they could be putting servers at risk. This commit encourages them to check their code by needing to import the proper names on a new Minecraft version. They can still choose to ignore this encouragement and blindly update their plugins without checking that volatile code, at which point they are fully responsible for the situation this leaves servers in, since server administrators now know exactly which plugin they just updated had broke things for them.

    Server admins may never have known they had plugins tying into volatile code. While this is entirely the responsibility of server admins such as myself whether we want to use these plugins or not, prior to this situation we had no idea whether a plugin used this volatile code, short of reading through the source code. Now administrators are armed with valuable knowledge.

    Those huge array of broken plugins would have been broken with or without this commit, however, this commit allows server admins to not accidentally break their servers running a plugin they had no idea that is using that code. Instead of having many people screaming that their servers are damaged and struggling to have them fixed, spending hours to do so, we have admins worrying about getting certain plugins updated, staying at a stable state with their server until those plugins are updated.
     
  8. Offline

    KollegahDerBoss

    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.

    It should be:

    If you are a server admin that only uses plugins developed with the Bukkit API, this safeguard doesn't affect you at all.
     
  9. Offline

    Codex Arcanum

    I believe both are equally correct.
     
  10. Offline

    jeffro1001

    I'm sure that the bukkit community ( bukkit guys, plugin guys, server operators ) will get past this hurdle.
    I just want one thing clarified though.

    Am I to assume that plugins that are posted on the bukkit site, and approved by the bukkit team, and advertised as a bukkit approved plugin are actually safe to run?

    Meaning:
    in order for a plugin to be approved, is the plugin code actually reviewed by bukkit, to make sure that the plugin dev actually did the right thing with the code, and didn't just put those few line in that bypass this safeguard?
     
  11. Offline

    Citizen Derp

    I like coming into this thread to read it days after updating only to find out that I should have been expecting my server to burn down and all I got was some fireworks.

    Shout outs all around to whoever was responsible for me being able to be a lazy admin.
     
  12. Offline

    SniperFodder

    But you never go full Derp. Never.
     
  13. Offline

    EvilSeph

    Bukkit doesn't stamp plugins with a seal of approval, we only try our best to make sure malicious plugins don't get uploaded. That's all we can do and it is already a lot of work.

    All we're doing is trying to give server admins peace of mind that if they're running a plugin from BukkitDev, chances are it doesn't let the author do anything malicious (to the best of our ability). That is all. We do not verify if the plugin is properly coded, properly designed, efficient or anything else whatsoever - doing so would delay the already busy approval queue significantly and hinder plugin developers more than it would benefit the community.

    Plugin developers and server admins are free to figure out ways to bypass this safeguard, but we won't provide any help with doing so and if they do choose to do so, they are taking full responsibility for their actions. If a plugin breaks your server that was irresponsibly and blindly updated by the plugin developer, it will be very obvious which plugin is at fault and which plugin developer's work you should probably avoid using.

    I hope everyone is having a fantastic holiday and will have a joyous new year :)
     
    hawkfalcon likes this.
  14. Offline

    spiral6

    I am so confused by all the arguing... I am pretty sure that what ever the Bukkit team has done is good, because what they have done in the past has not affected us much. Me, as a plugin developer, I feel this safeguard doesn't really affect anything thus far...
     
  15. Offline

    Devil Boy

    Now I know this may be unrelated, but I have an interesting question.
    If a CraftBukkit Dev build happened to harm a server, who would be blamed?
     
  16. Offline

    deadlock989

    "If you love communism so much, why don't you go and live in Iraq?"

    I'm waiting to see what the Mojang Mod API brings, if it ever actually materialises. It would be nice to cut out the middle man.
     
  17. Offline

    desht

    Er, because Iraq isn't a communist state? Not sure what that has to do with anything, though.

    We're all waiting to see what the Mojang API brings, trust me. But part of why these versioning changes were made is because of the API - the Minecraft server internals are getting a lot of refactoring for it, and that dramatically raises the possibility of an old NMS plugin doing something completely unexpected when run on a new CraftBukkit release.
     
  18. Offline

    deadlock989

    I was just pointing out how the response "Go and live somewhere else if you don't like it here" is the last resort of someone with nothing to say. This is just going round and round. The bottom line is, plug-in developers who use NMS and CB classes have to update every single time Minecraft updates no matter whether the plug-in is "broken" or not, just because some reckless server admins run plug-ins compiled against ancient CB builds on a brand new CB build without testing them on a sandbox first.

    Oh, and 1.4.7 pre-release is out. Happy New Year, devs.
     
    KollegahDerBoss and bergerkiller like this.
  19. Offline

    bergerkiller

    Devil Boy
    When that happens, they will put you on a list of 'bad guys' and whenever you are trying to prove a point somewhere, try to address an issue or want a certain feature in CraftBukkit, they will use that one occasion to silence you. This is pretty much what happened to SpoutPlugin, it WAS going well, but it seems that the only times it is referenced by someone it is to point to an old issue.

    So better avoid causing your plugin to crash a server. Try-catch everything. Validate everything. Put a million warnings of incompatibilities on your dev-bukkit page, and don't forget to blame others when something goes wrong!

    On a more serious note, your plugin will simply become one of those plugins they can blame. Even if you correct your issue, your plugin will still be known for 'that world corruption causing plugin'. Eventually, the plugin developer is held responsible, not the CraftBukkit or Bukkit team, neither the server admins themselves. As a plugin developer you have to be aware that you are properly 'licensing' your plugin against these failures (PROVIDED "AS IS") so you can point people to that. Forgetting to do this can mean the end of your plugin.
     
  20. Offline

    TnT

    bergerkiller
    Don't forget how we go to their home, tar and feather them, and repeatedly beat them with a wooden ladle before we cut out their heart with a spoon.

    Or something like that, cause we're pretty evil.
     
  21. Offline

    bergerkiller

    TnT
    Genius comment.
     
    KollegahDerBoss likes this.
  22. Offline

    lenis0012

    happy updating over 500 versioned variables -.-
     
  23. Offline

    Ghomerr

    Well, thank you to TnT for highlighting this topic.

    How would you like us to work with you to propose new features in the Bukkit API, as EvilSeph said ? By opening a ticket on your Jira ? Here on the forum ? By suggesting sample of code ?

    How can we do that ? What is your preferred means ?
     
  24. Offline

    4am

    Refactor. Done.

    False. Minecraft is being re-written almost completely, to optimize and accommodate the Minecraft API. This was not true in the past - although it was entirely possible for breakages, it was not anywhere near as likely. The biggest risk is functions being reduced to perform only their most basic tasks ("update" instead of "update and save" is a good high-level example). If you let the plugin expecting it's call to net.minecraft.something() to do A, B and C, and it now only does B, you're gonna have a bad time. In some cases, you won't even know you're in for a bad time until it's way too late.

    Have you read some of the posts here? The majority of server admins (even of some of the bigger servers) DON'T have a clue what they are doing - and worse, they refuse to accept that Minecraft modding is a constantly evolving beast, since the game itself is constantly changing. Many many people went into being server admins thinking that they could set up a server, throw up some plugins, and it would just work forever. That assumption is the source of much frustration around here, but it's foolish for anyone to blame that on anyone but themselves.

    If you can blame the Bukkit team for anything, I could say they've been slow at times, but they have put out a solid product consistently from day 1 (and I would know - I've been here). Also, I can criticize past speed-of-handing for community pull requests; but I understand and accept why it is the way it is - bug fixes to core code come first (No plugins are no good if CraftBukkit doesn't work), and some pulls are coded in a different style than the Bukkit API - it would make for a messy API if it wasn't consistent.

    Nothing new.

    Here's a better solution: Let's let some of the plugins mysteriously break in odd ways that are hard to detect, and even harder for users to report. It'll be just like Windows 95!

    End result is a huge array of working maps and servers which are slightly inconvenienced by a nonfunctional plugin, which usually doesn't matter that much since essential things like block protection and permissions are part of the actual Bukkit API, and plugins using only Bukkit API calls will not be affected by this change in any way. Also, since plugin authors will HAVE to update, they will be more likely to look for bugs.

    If you want to call that Bukkit "passing the blame" to plugin authors, then you know what? I'm OK with that - because f*ck them, it IS their fault. Why are plugin authors so immune from maintaining their code? If you can't handle the responsibility of maintaining a plugin that uses NMS, or can't be bothered to assemble a team tat can rely on each other (since we all have lives outside of Minecraft), then don't make the commitment.

    Here's the real jist of it, nice and simple:
    1. Minecraft releases an update, Bukkit soon follows. NMS plugins break because non-Bukkit calls are masked with a version number, and calls into the old package go unresolved.
    2. Devs of NMS plugins (who should ALREADY be testing their plugin against every new Minecraft version anyway!) are forced to open their IDE and refactor all their NMS imports/references. Eclipse can do this easily. Pretty sure NetBeans and IDEA can, too. If you use Notepad, well sorry; Ctrl+H. That's silly, anyway.
    3. Since you have to do this, you should also test your plugin to make sure it works. Yes, you are forced to take a look at your plugin's code when potentially breaking changes have been made. I'd image that many times, everything will mostly be fine. At this point, you should be sure; the opportunity is there. Don't be that guy. All plugin devs should be pulling Bukkit Dev builds, reporting bugs on JIRA, and even hanging out on IRC, testing things and taking with others about it - this helps users, server admins, other plugin authors, the Bukkit team, and maybe even Mojang (bug in NMS? Post it on their JIRA!)
    Bukkit and Minecraft are not Ronco products - there's no "set it and forget it". Support your work and your users.

    Now you're just being flippant. I hope you're outspoken because you have a better idea? If you do, please: Let's work out this problem like engineers/coders/real people. Save the rage for comics.;)

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

    deadlock989

    Nice. This attitude is why I took my plug-in off BukkitDev. That's no great loss, but I can't be arsed with this.
     
    Canownueasy likes this.
  26. Offline

    4am

    *facepalm* i give up.
     
  27. Offline

    bergerkiller

    4am
    And strangely, they never <ever> mentioned that this was because of the API when the discussions began. The only thing they mentioned was that they had a lot of false issue tickets related to changed NMS code. It is only after someone finally mentioned that it was because Mojang was going to push the API out, that things are starting to make sense...well slightly.

    For the API to be successful, it needs a total rewrite. Clearly, they are not doing a total rewrite, because 'there are going to be many breaking changes over a long period in CraftBukkit NMS'. By not starting from scratch, they are losing my interest for their API, because it is going to be just as limited as Bukkit is. You can not slap a wrapper onto NMS, you can not make a distinction between Minecraft entities and blocks and custom ones, and you should not put all of the world logic such as weather, lightning and time in the Worlds themselves. Worst of all, I heavily suspect that there will be no deobfuscation at all for the internals, and I'm almost sure that for most plugins to work, you still need to access the internals. What use is an API if you need to hack yourself in? Tweaking the current CraftBukkit to make it an equivalent to a total rewrite is going to take several months, and quite honestly I do not feel like preparing my plugins to work on every minor change of their giant rewrite they are going to push out.

    That's the point: we already did. But now they are taking away the common chance of a plugin NOT breaking. The first thing a developer did was run their plugin on the new CraftBukkit and do a quicktest on all the features. If nothing breaks, they simply add the new build to the supported list, and they are done. This entire option is now gone, and will require needless uploading and downloading.

    Updating is not the problem. Let me repeat: UPDATING IS NOT THE PROBLEM. It is the uploading of plugins, approval times, waiting for admins to test your plugins again, having every admin downloading your plugin over again, and not to forget having to answer countless of comments that ask you to update your plugin. Backwards compatibility is also deduced to nothing unless you start shading in different versions or classes of your plugin in one jar file, something you can not keep on doing forever. For things that did tend to break often in plugins, one could write libraries (ProtocolLib and others) to deal with that, but now you can't pass around NMS-typed objects around, you are stuck to using Object instances all over the place. Deobfuscated methods in CraftBukkit didn't change, ever, but are now unusable because you need to use a library to use them. Some plugins will have to depend on a 2mb 'NMS translation library' to stay alive, and they rather not do this, because what if this library stops being maintained?

    Forcing plugin breaks every new MC version was going to cut me down on time to actually work on new features or even bug fixing. It takes away the fun of writing plugins, because all you are doing is updating pages and uploading compatible plugins. It pretty much reduces survival time of your plugin to a mere week to 2 weeks. SignLink was working for 4 months (I am not kidding), and now it is breaking everytime MC changes, all because it has to use TileEntitySign and Packet130UpdateSign. 'Tis a shame.

    Look, I can understand that it is useful when the internals will undergo an entire rewrite, but that's the root issue: Why are they going to push out changes after changes of a total rewrite, as opposed to letting us use a stable server for a few months and then publishing the API? It's not like we can 'prepare' for this API, all we are doing is renaming and rewriting stuff. Rather spend 2 weeks on rewriting all of my plugins than spending 4 months in total to keep it up to date.

    I think this will be the last time posting on Bukkit btw, since all of my plugins have new maintainers I think I can finally let it go now. So no need to point that out :)
     
  28. Offline

    Phlexor

    If you don't understand why this is the main problem right here, then just give up programming right now.
     
    Feindbild likes this.
  29. Offline

    Linkupdated

    Personally the part that's sad is that no more api is actually release anymore, well not like this summer, since the original bukkit team left for mojang, Bukkit has slowed in so many way making it necessary to use craftbukkit code.

    And now they say if we use it, we get punished by changing it every update....
    Yes that's doable but 2-3h every mc update to going to be crazy, since in 2 week mojang got out 2 versions....


    I think bukkit will die and people will wait for the api if it goes on like that.

    I don't criticize their choice but i think its what will happen.
    And even so mojang don't seems to work at all on the api..... With like 10 commits on their github, they prefer fireworks and baby villagers

    Good day.
     
  30. Simple words: It is not that simple.
     
  31. Offline

    4am

    I am glad you took the time to write this. I've read much on the forums and elsewhere, and everyone seems to be griping about refactoring (I'm guilty of freaking out as well; I even snapped at you on the TrainCarts comments - I'm sad to see you go and I depend on your plugin! I don't want to trust a new author, even if he is good! lol). This certainly offers a new perspective - I didn't really think about BukkitDev. I don't think this was the intent of the change, but it makes sense that passing the approval process is a huge pain for each MC update.

    I really am at a loss for what else could be done about the situation though - it seems to me that we can't go without a safeguard of some kind due to what the Bukkit team has mentioned, but that safeguard will always been an inconvenience. We certainly can't ask Mojang for anything regarding freezing calls or changelogs.

    Well, this is a mess indeed.

    If you decide to post again, can you elaborate on this (or someone else who is familiar with it)? If you can work with the objects why can't they be passed around?
     
Thread Status:
Not open for further replies.

Share This Page