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


    This is just like developing a platform to be compatible with all Java versions. You can only use the features defined by the Java version you are trying to be compatible for. If you want to use a new feature in the Bukkit API- Nope! You need to do it in NMS now because if you did it would make your NMS invalid and ruin everything.

    Please, let BukkitDev do the versioning.

    But really, is it so hard for someone to give their honest opinion and not be held back by some title or ribbon?
  3. Offline


    While you were responding I did indeed quote and respond to the rest of your comments. As mbaxter said, however, I'm responding towards your assumptions in areas where you have no knowledge whatsoever. BukkitDev is now my primary goal here, and I'm correcting your misunderstanding.

    Unfortunately, your common sense is wrong. BukkitDev staff do not have any more time spent on plugins because of this change.

    My opinion is made fairly clear by the nice badge, but that doesn't make them void or dishonest. I and others have put a hell of a lot of work into BukkitDev so far, and the fact that you're trying to speak for the staff and use what we've done to your advantage in complaining against this commit rubs me the wrong way.
  4. Offline


    Maybe not individual plugins, but it is common sense that the amount of plugins submissions will go up which would increase the work load. To get the time you would multiply the work load by a magic number and divide by the amount of participants in the team (theoretically). If the team has more additions due to this, I see it as another issue, but logically speaking the work load has gone up.

    Maybe my logic is wrong and the amount of plugin submissions won't go up; with all the people quitting and all.
  5. Offline


    Most plugins submit updates for every new CraftBukkit release regardless of whether it is physically necessitated by the changes or not. If you've ever maintained a plugin, you would know that people don't see an old version number and assume it's compatible, they see an old version number and demand to know where the latest release is. This doesn't change that, it only means that people who don't go to BukkitDev to get new versions of their server's plugins for new releases will now do so instead of neglecting updates. In any case, if you're going to have an attitude about it when we're trying to have a discussion, I don't see any point in trying to explain this to you seeing as all you're going to do is be sarcastic and ignore me.
  6. Offline


    Yes, there are a lot of factors to equate when thinking about people submitted their plugins. What I'm mostly concerned about however are inactive plugins that hardly ever receive updates, and if they do it is a miracle. Most of them have been compatible since 1.1-R6 too.

    I am very welcome to seeing everyone's opinions on the matter as I previously said. But I don't see that in this type of environment on the forums or the git commit we ever got anywhere or will get anywhere.

    My attitude is just in good interest, but how I express myself in text is not that favorable and for that I apologize.
  7. Offline


    You have an odd grasp of the English language. I never begged, only asked a question. If all it takes is to ask you a question for you to return again the 5th time, I imagine you'll return again.

    So much better. So it prints a link before or after it corrupts a world? Clarity would be great.

    So all the posts explaining anything the FAQ didn't cover either are also invalid. Understand this is not a "Lets rehash the discussion" again thread. This is to announce for the community what has happened and how to handle it. Again, you cannot state it is invalid just because you disagree.

    Which has nothing to do with this commit. That said, we think the Spout devs can work around extending that class. We're happy to work with developers who are finding challenges with our API.

    Plugins that break get updates. They update to DBO, we do our thing. Its really not much more work than before this commit. I am not concerned. :)
  8. Offline


    I'm not at all taking advantage of you. I'm simply stating what I believe will happen.

    Plugins that break get forked and get updates, which in turn increases the BukkitDev work load.

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


    If there have been Bukkit plugins that haven't been updated, yet been compatible since 1.1-R6, they will stay compatible. If there are OBC/NMS-using plugins that haven't been updated since 1.1-R6, it is either a one-in-a-million miracle that the changes to that code has not affected them, or they aren't compatible and are silently doing something that was not expected. Anyone who has looked at the diffs between Minecraft updates can attest to that. Either way, you shouldn't be knowingly using those plugins if they aren't updated for the latest CraftBukkit; that's just irresponsible. Some administrators, however, don't know, and so this is a wake-up call.
    We don't let just anyone upload a fork. If the original developer is still around, there's no reason the new developer shouldn't be submitting their changes to that project in the form of a pull request, in which case the developer can update themselves. If the original developer is not around, and a fit replacement is found, the plugin will be updated as usual; it causes no more work for the staff because there's no more active projects that have to be approved than if the original project was still updated.
  10. Offline


    Actually, the reason they do not break is because they are using renamed NMS and OBC calls, thus being responsible plugin developers. Their plugins can't damage anyone's servers. It's not a miracle that they work.
  11. Offline


    Good thing we aren't afraid of a little hard work!
  12. Offline


    What's your point, then? If the developer is actively maintaining the project, they will be maintaining with these updates; it's the same process from them. Your original portrayal of the plugin, one which had been compatible since 1.1-R6, implies that there have been no changes to them since then, and they still remain compatible. This is not in line with what you have just replied with, which says that the developers are actively updating them to the new renamed calls. If the latter is the case, this doesn't change anything in that process. If the former is the case, see my response above.
  13. Offline


    A little? Server owners are already ungrateful enough for what plugin developers do, and now they will be complaining right in the developers face for something they have no control over. These are plugin developers who go over the top too to do something spectacular that everyone would enjoy...

    It's just not right.

    Re-read my original post and you'll understand my point.

    There is no pros to any particular party is my point. It's just some abstract responsibility thrown out there which doesn't even matter in the scheme of things. What does it change?

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


    Yes, a little. As the increase you are talking about is really quite minor compared to what gets dealt with on a daily basis.

    I agree that server admins should be grateful. I am exceedingly grateful to every developer that helps with plugins on my server. Its just not right to be ungrateful to anyone who does this kind of thing for free! We can all agree on that I'm sure.
  15. Offline


    Uh. No.
    Here's what you're saying: a plugin that has been around since 1.1-R6, which is considered inactive, and I'm inferring uses CraftBukkit/NMS code, still works on the latest version and will break with this commit. Correct me if I'm wrong.

    Here's what I'm saying: that plugin is probably broken already. The fact that it has been inactive for so long means that it's something to the extent of a 1/1000 chance that no methods have been changed that breaks or changes what they're doing. Either way, running it is, like EvilSeph said, playing Russian roulette with your server, and you don't want to play roulette with those odds.
  16. Offline


    Renamed methods will never break unless they no longer exist. If they no longer exist, they will throw an error that the method is not found, achieving the exact same purpose as this commit. The plugin developers were responsible and only used rename methods- that was my point.

    But it's not even relevant in the scheme of things compared to what the actual issues are.
  17. Offline


    The fact that they don't break is the point here; it makes things even more dangerous because you don't know what the new method is doing. You say in one sentence that they will never visibly break unless something is completely nonexistent, then in the other say that renders this commit useless, because it accomplishes the same task.

    No, it doesn't, and you've said it yourself. When I said "it's probably already broken", I meant that it's doing something that wasn't intended at the time of it's writing. It could, of course, visibly have an error, but as you said it's more likely that what they were calling before now calls something else, which is more dangerous than visibly having signs of their failure. I'm not sure what using "rename methods" means, but I can assure you that there's no way to provide forwards-compatibility for a plugin when you're accessing internal code like that (unless you update the code yourself), and things change every update, meaning an OBC/NMS plugin from 1.1-R6 is bound to have unintended consequences at this point
  18. Offline


    While some of that is theoretically completely true, I tend to realistically disagree. We can create theory's and predict what is going to happen on this matter, but practice actually shows what actually is going to happen.

    The chance of a plugin ever causing damage to a server is near 1/25000. The chance of a plugin breaking due to a minecraft update is 3/5. I invite you to tell me otherwise, but from mine and many other's experience this is simply what occurs.

    Again, towards my original post I only see this having relevance on my BukkitDev point, which isn't even the strain of my concern, so I don't see a reason to further debate this.
  19. Offline


    What you said above:
    Doesn't seem to line up with what you're saying now:
    I don't know if by "never" (or, more fairly, "[almost] never") you meant "3/5", and that renaming a method has no plausible way of damaging your server unless it's the one out of 25,000 chance that does that (which is clearly untrue if you look at any diff between updates), but you're clearly contradicting yourself.

    The facts are that these plugins have the opportunity to do serious damage to your server that is unintended by the developer, and unknown to the server owner. As EvilSeph said, the changes coming to the code will make it even more volatile, and the prospect of allowing a plugin to do this is unacceptable, especially when it is usually us who has to deal with the problem.

    If all these is not absolutely clear to you, and you see no reason to debate it, you shouldn't bring up things about which you have no knowledge. The staff are working exactly has hard now as they were before, and this does not change that. Unless you're staff, I don't think you have a position to debate that.
  20. Offline


    NMS and OBC plugins that use renamed functions will never break unless a massive change occurs, and even so they have absolutely zero chance of damaging your minecraft server as the method will no longer exist. Generic NMS and OBC plugins have a 3/5 chance of breaking.

    What do you deal with exactly? Did you not read my statistic on how there is a 1/25000 chance of a NMS or OBC plugin causing damage to your server, because there actually is. It's a terribly low chance, so low I don't even understand how you even came to notice it.

    I have no knowledge? Work load is a very simple concept. I don't need a fancy tag to understand it.
  21. Offline


    People don't just used named methods. We can't refactor just unnamed methods.

    Pulling numbers out of thin air? If it was so low, why do we get *ANY* reports about plugins that cause silent breakage?
  22. Offline


    Coelho we've been through this over and over again and it seems like you're just rehashing the same arguments without even the remote intention of listening to what anyone says. You had your chance to provide us with a valid and logical alternative that is in line with the Bukkit project's goals and were unable to do so.

    If you're just going to speak with authority on things you aren't qualified to speak with authority on, I'm just going to point you to this post I made in the commit discussion and politely ask that you step out of this discussion until you're able to not treat everyone like they're lesser than you.
  23. Offline


    That's not a responsible way to develop, that's taking just as big of a risk. The internal OBC code is meant to be just as volatile as the NMS code, and therefor depending on something and assuming it will "never break unless a massive change occurs" is a HUGE mistake. Things change all the time, and unlike the API, there are absolutely no guarantees that they won't change for the next update, or even the next build. The internal code is supposed to change, and assuming it won't is just as bad practice as trying to use any other non-renamed method.

    MOST of the reports we get about CraftBukkit errors or bugs are from plugins poking into the NMS/OBC code, and failing to update properly or misbehaving. It is the primary reason for a report, not the actual CraftBukkit code. Nevertheless, we still have to investigate each one unless we know for a fact that this specific symptom is because of X plugin, because we've already seen so many reports about it.

    I don't understand why you're still arguing this. You've tried to tell me that I and the other staff are now working harder because of this commit, but we are not. Believe me when I say that if this commit did have that effect, I would have a bone to pick with the team. I do not, because it doesn't. Every time you've given me a reason, I've proved to you why it isn't true, and you continue to think it is. This does not cause the staff to work harder, despite what you keep believing. I don't know how to put it any different

    EDIT: I was writing this before the responses above were written. Please pay attention to them, and not me.
  24. Offline


    I have given excellent alternatives on the commit comments that have gone misunderstood, but that is not the fault of me. I have also read every post and considered every point on that commit. I have considered everyone's opinions towards the matter and formulated them into my own opinion. People don't form opinions without prior knowledge leading up.

    I have already stated that my writing is arrogant and this is not how I normally talk. I do believe however that everything I'm saying is valid. Again, I invite others to prove me wrong.

    My previous point was that plugins that have stayed functional for a prolonged amount of time are doing so because they are using renamed methods. Due to how the Bukkit updating process works, these methods are reliable to stay the same name as long as they are existent, history has told us.

    I'm not sure I understand that sentence.

    If they do change, it is only because they would be renamed or removed, and it is safe the developer to assume that it will not cause any damage to any servers. Unfortunately, they don't change often at all.

    These plugins which break, however, cause no permanent damage to the server. They simply have unintended side effects.

    I'm simply replying to what is given to me. I am confident that as soon as a new Minecraft version releases your work load will temporarily increase beyond that of the previous Minecraft version- and the previous. That is what my previous posts claimed.

    Again, please leave the other points in my original post unnoticed and sway away from what actually matters.
  25. Offline


    And that is unacceptable for most servers, especially when the new (API) changes start being implemented. Developers must re-evaluate their code to make sure it still works as intended; to think that unintended side effects are fine is lazy.

    Well, next time there's a Minecraft release, I'll PM you personally and let you know how we're doing. Thanks for your concern.

    Not sure why in the world you would want to "sway away from what actually matters", but okay.
  26. Offline


    People won't reevaluate their code though, and I doubt they'd care enough to take responsibility.

    Thank you.

    It's not that I feel we shouldn't have this commit. It's that I feel it is purposeless and avoids the issue entirely.
  27. Offline


    Coelho apologising for writing in an arrogant tone does not excuse you from doing it. If you want us to respond to you, you're going to have to do better than "apologise".

    The fact of the matter is: you really have no idea what you're talking about, yet are writing as if you do and it is extremely frustrating and annoying. There's no point trying to discuss things with you because you just don't give a crap about anyone else's opinion but your own. What makes it even more frustrating is that you like to hide behind the lie that you *do* care and like to use it as an excuse and reason that we should be forgetting about your argumentative and condescending nature.
  28. Offline


    Why not add an option in bukkit.yml? Something like this:
    plugin-safeguard: enabled
    plugin-safeguard: disabled
    vgmddg and Assult like this.
  29. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

  30. Offline


    That is quite unfortunate indeed, but this is only my writing. Instead of looking at my tone, look at what is behind the message.

    I have no idea what I am talking about? I have not seen any of my points as incorrect.

    I do entirely. Everyone's opinions and knowledge are built off of others.

    My personality is a lie?

    That would be very ugly to implement and would endorse NMS and OBC plugins.

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


    Wait wat? I read that, and I couldn't find why he shouldn't put the option in or why. Can you please explain this to me? I would think this would be preferred over cracked versions of bukkit.

    Sorry, I'm not a coder, I only know basic Batch... If I am annoying, sorry.
Thread Status:
Not open for further replies.

Share This Page