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 Retired Staff

    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

    bergerkiller

    s32ialx

    First I would like you to point to Point 5 (insults) of wrong argumenting skills. Next, this 'making the flow better' is my argument in my post, so I don't see why you are trying to use my own argument to counter my own arguments. Next I am trying not to troll, but replies like yours (insults, boxing, lack of understanding) tend to send me that direction regardless. You are just inflaming a flame war, so please stop.

    And in my case, the driver is BKCommonLib. Now imagine all programs that use this driver have to be updated when the hardware changes? Doesn't that make my driver useless? Do you get now why people wish to bypass things?

    And unfortunately, the 'standards' cover a mere 20% of the features I use. All I can use in my plugins is:
    • Events
    • Block(Face), World and Chunk
    • Some small methods in the above
    There are many, many things not provided by the standards, hence, I am directly invoking into the hardware. Now I found out that this didn't work, I went ahead and wrote a driver, BKCommonLIb. And now, the moot point you seem to forget: This driver is no longer working as expected because the driver requires hardware references, like a pointer to your mouse/keyboard/GPU handler, which are no longer constant. This makes having that driver pointless, completely agreeing with your entire message about coding standards.

    Now from your belief that Bukkit is the all-contained API, I want you to point to the fact that this simply isn't true. I can assume that you never used anything outside the API, and hence do not understand why other people go beyond the API. Let's respond to that by saying that server MODS require access to components on the server.

    For your understanding, please try to do the following things through Bukkit:
    • Replacing a creeper entity to alter how it moves towards a player
    • Making entities invisible or disguise cows as pigs
    • Directly altering the physics of minecarts to allow trains and additional rail types
    • Replacing components in the server to log server performance
    • Altering the way chunks are sent to players to improve network usage
    • Changing the data file from which players load inventories and other information, this way splitting and merging inventories between worlds
    • Replacing certain sign tiles to change the text seen by different players, to allow personalized text on signs
    • Obtain block/material information such as opacity, powersource, emission and 'suffocates entities'
    • Teleport all types of entities between worlds
    • Improving TNT detonation performance, replacing the explosion algorithm with a faster alternative
    • Obtaining all the signs contained in a chunk when a chunk loads, without looping through 16^3 blocks
    • Obtaining all the signs, furnaces and chests loaded on the world, without looping through trillions of blocks
    • Optimized alternatives for entity distance checks to allow millions of iterations without tick lag
    • Repairing the bugged lighting found in (all) chunks after being generated
    And I can go on. I am not trolling you, to the least, I am trying to give a more intellectual answer that covers everyone's questions, instead of responding like 70% of the other people do. If you can't handle this, don't read my posts.

    And people like you need to stop insulting, thus trolling, people. To me, you sound like a typical COD player that just got killed by a grenade because you were not 'on the move', and are now calling all the players around you hackers. Calm down, start thinking and stop assuming. Because honestly, who here is typing in all-caps and throwing insults into the wrong directions? Did I insult you with my post? Did I call you a worthless piece of trash that should stop hanging around on Tuesdays on the WoW forums? No, I did not, because I am not trying to troll anyone. I will, however, defend my right to give name-callers a piece of their own mind.
     
  3. Offline

    SniperFodder

    So are they going to Version Bump All classes each time they push an update, or only ones that have had code changed?
     
  4. Offline

    s32ialx

    I never called you a piece of trash I have never touched a single COD But I get where you make your point there haha. I may have made a full Bolded Statements by using Caps but that does not mean I'm flaming in all caps lol.

    Well you tell me when you get an ATI Videocard and then your like oh this Nvidia card is much better and cost less LETS GET IT!? don't you have to uninstall the old DRIVER and install the NEW DRIVER or your system is BUNK
    New hard drive OH LOOK size discrepancy now I cannot ghost it. but I really wanted that SSD to bad I cannot just ghost my old spinning platter disc to that shiny new SSD.

    IMPO Bukkit does not need to provide anything above what they came in to existence to provide if they had plans to add things they will but if you need to use the hardware "or interact directly with the server" to make your plugins work than those plugins should stop existing until they are supported then and majority of the servers would have to deal or move to another project, or just make sure they stay active and update.


    IMHO java as a server is pointless anyways. bukkit already has to "start from scratch" with every build and yet like mojang they use java... I know a lot of people will say "you can use java just as good as any other language" and that's semi correct... but when your using it as a server your missing the bigger picture anyways. You do not have full access to the HARDWARE due to the overhead of the runtime not to mention the garbage collection while it scans all the allocated memory to see what can be freed can cause a java to choke.

    I'd like someone to make a game as immense as wow with the graphics as wow or better run a Java Client as well as Java server side app. the world may be long past C++ but any coding language that has full hardware access will be more beneficial in the long run with resource management.

    __

    not to mention writing plugins as a script instead of a completely separate java file is way more logical. LUA is a beautiful scripting language

    --to add to this

    I used to run a Private wow server with Closed Source WoWEmu it was great but closed source. Then updates came and it disappeared and now MangOS and Trinity are the WoWPrivate Servers of choice. and they support (but do not provide support for) you adding your own modifications to there server code before you even compile it because they don't provide a pre-compiled version because EVERYONE has different hardware, so it's up to you the Server Owner to learn how to compile your own server and add your own modifications (some user provided scripts to add in or you can create your own if your bawlzie enough) and then once that down and your server is up you now can use LUA plugins for the actual WoW Client and manage your servers permissions and everything IN GAME with nice GUI's and it's all thanks to lua's being able to provide there own menu's and layouts etc.


    ___
    please do not reply with

    OH Minecraft was made is java so most of the people involved in it are java developers because that's complete hogwash. I personally hate java always have since Sun sued Microsoft and made them scrap MicrosoftVM which was a much more efficient and stable Virtual Machine. But that's another key java is a VIRTUAL MACHINE there for it's not really the machine running the server it's being ran virtually inside java.

    if your not willing to learn anything BUT java then your loss really, you should never lock yourself to one language.

    oh but I did find it amusing that me saying your acting like the people do on the WoW Forums on Tuesday points you to the conclusion that means your a Piece of worthless trash
     
  5. Offline

    bergerkiller

    s32ialx
    Yes, but all programs using these drives don't have to be updated, right? Did you have to update a game that was released prior to when the video card you are now using was released? Nope, you did have to update the drivers perhaps OF the video card, but the game still works. In this case, when CraftBukkit is updated, the driver (BKCommonLib) is updated, but all plugins that use this driver keep working.
    Now that the changes by Bukkit are introduced, this system no longer works. When you install your new video card, you can go ahead and update all your games even though they could still work. These games could've just included the driver in their game, because honestly, they have to be updated anyhow!

    Indeed, Bukkit can not and should not provide an API to replace core logic, but to still be able to do it, you will have to go into the danger zone. So far, this was working well. I wrote my own 'drivers' to do this and to do this safely. But now, Bukkit added a change that completely destroys the use of drivers. They do not have to support it, no, but neither should they add changes that make it impossible for others to support it.

    Actually, you do. Java, just like C#, .NET and other generic languages, can use 'native' methods in libraries to interact with the hardware directly. In fact, Minecraft itself directly interacts with the hardware using LWJGL. This library, in turn, uses the OpenGL/AL natives (.dll files for windows) to interact with the hardware for that specific OS. Java is perfectly capable of performing well, but it is not made for OS or system-specific logic. It is up to libraries and natives to do this.

    I have programmed c++ too, and I understand the benefits. But currently, Java is improved so much that the only benefits remaining are the pointer/value uses and structures. Pointers are already optimized in Java using the garbage collector, so in theory programmers have it better by not having to deal with them. Still, not being able to pass in an int 'by reference' to a method is a bit annoying, but there are ways around it. And for structures Java uses optimized class management so that classes that only contain integers, for example, take up less space in memory.

    However, it can be a good idea to program in c++ because it allows a 'slightly' faster data flow to the hardware. This difference is becoming less and less while Java is improved, though, and it only applies to games that switch between GPU and CPU processing extensively. If games written in Java just write all the instructions to the GPU at once and leave it alone afterwards, Java can run high quality games. Minecraft, however, isn't written like this.
     
    s32ialx likes this.
  6. Offline

    Clavus

    Oh great. Programmers kicking a fuss over standards, compatibility and time investment in a large community-managed project. I think I've seen this scenario a million times now, just different game, different community.

    Personally, plugins breaking and waiting for them to be updated is one of the most annoying things for me as a server admin after a Minecraft update. This change isn't helping with that. I back up my world so I can deal with a little data corruption in the off chance that a plugin wreaks havoc.
     
    s32ialx likes this.
  7. Offline

    bergerkiller

    Clavus
    Hm yeah it is getting slightly off-topic here, sorry for that. Let's try not to expand this into a 'C++ vs Java games' discussion, so I won't be posting anything related to that after this post.
     
  8. Offline

    s32ialx

    bergerkiller

    Ok maybe not but a game update has caused a driver to need to be updated. many many times with WoW and other games like EQ. -- to the point where you even have to go out and get a faster CPU or even a new Videocard... because yours is no longer supported by the game anymore -like my x1650 with WoW.

    I'll accept this as I can say playing Runescape now to back in Classic days... the improvements java has made are noticeable on a high end system but I don't think these "improvements" will be much noticed on my old P4 now if MicrosoftVM was still around and updated I bet even MC and the new RS would play decent enough on it since it does have an x1650 in it.
     
  9. Offline

    bergerkiller

    s32ialx
    Yeah I guess I can agree on it that Java runs 'high-performance' code poorly on the CPU. In combination with more powerful GPU scripts, however, it can run excellently.

    Maybe WoW doesn't do backwards support, or depends too much 'on the latest things'. I guess the same counts for BKCommonLib. If a new method is available to handle the sign text packet in a way more efficient and safe way, I can understand that I will update SignLink to use this new method. This happens rarely, however. In TrainCarts this happens a lot, usually because I decided to push more stuff to BKCommonLib because it didn't belong in a plugin.
     
    s32ialx likes this.
  10. Offline

    s32ialx

    bergerkiller

    Cool that was fun entertaining and enlightening and ended with no bans kicks or pissed off people :)

    Thanks! was very refreshing!
     
    bergerkiller likes this.
  11. Offline

    EvilJackCarver

    Idea: Restructure the code a bit to allow for an override to be placed in the bukkit.yml file. I'm only barely a novice programmer, so I don't know how easy that will be, but it would save a LOT of uproar.
     
    vgmddg likes this.
  12. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı Retired Staff

    It wouldn't solve the issue. I've quoted the FAQ twice in this topic already explaining why it doesn't work :3
     
  13. Offline

    EvilJackCarver

    Must have missed them then... =\
     
  14. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı Retired Staff

    EvilJackCarver likes this.
  15. Offline

    Puremin0rez

    So 1.4.6 was my first "safeguard" update as an admin - went pretty painlessly.

    Thanks to the great developers of Orebfuscator, VanishNoPacket, TagAPI, WorldEdit, etc they all updated in a timely fashion :)

    I will miss NoLagg though...
     
    mbaxter likes this.
  16. Offline

    TheRealZuriki

    Sounds less like "it wouldn't work" and more like "we don't want to do it".

    Regardless of the reasons, I stand on the side-lines regarding this change. Either developers and admins will adapt, or Bukkit will fall out of favor with both groups and it won't even matter. There is a third alternative, but after 8 pages of complaints from developers and admins alike, it would seem very unlikely that Bukkit is willing to undo the change based on show-of-hands alone.
     
    vgmddg likes this.
  17. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı Retired Staff

    Bukkit is a implementation agnostic API. It's not getting an implementation-specific config option :p
     
  18. Offline

    TheRealZuriki

    I'm not complaining, I'm just pointing out it's not that you can't it's that you don't want to - regardless of the reason for that decision.
     
  19. Offline

    hatstand

    Then why are there implementation-specific entity and material classes?
     
  20. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı Retired Staff

    Did you just... ignore what I just wrote? Unless you think us not adding horses to craftbukkit is a "don't want to" rather than a "can't" situation too.

    You're confusing implementation and specification

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

    hatstand

    The material classes aren't specifying anything, it's complete code that assumes your implementation runs on top of Minecraft.
     
  22. Offline

    TheRealZuriki

    :eek: Sorry but that's just silly-talk.
     
  23. Offline

    hatstand

    You're right, I'm just having fun.
     
  24. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı Retired Staff

    I think I see the confusion now. You think I'm suggesting Bukkit is built to run on a TF2 server or some other game, and that's what I mean by implementation.

    Bukkit is able to be implemented on other minecraft server implementations. Such as glowstone, back when that was being actively worked on.
     
  25. Offline

    asofold

    So what is the underlying game? I wonder how this works in practice :) - also a generic mechanism could be a good choice, like with plugins to depend on (very roughly), then it would work with all implementations, because the problem basically is the same on the paper. Otherwise it is a bit of a peculiar point of view i would say.

    Wow, that looks like information spread.
     
  26. Offline

    black_ixx

    Is there any page for suggestions and additions for the bukkit API? For example I would suggest a feature to change the color and text of a players nameplate.
     
  27. Offline

    Derthmonuter

    This isn't because of removing the .getHandle() method with tags. This isn't about making life using CraftBukkit more difficult. This is because, in that post, developers who use CraftBukkit were demonized in front of the entire community.

    It just wasn't polite.
     
  28. Offline

    Lolmewn Retired Staff

    Then again, it is safer.
     
  29. Offline

    tanveergt5

    will big plugins like factions, permissionsex etc all suffer?
     
  30. Offline

    bar10dr

    Microsoft should go down this route as well and change all their API namespaces for every single Windows update, to ensure that all the programs that run on Windows doesn't crash the OS.
     
  31. Offline

    jeffro1001

    While I appreciate the bukkit team looking out for my server, I'm also wondering how I, as a server Owner / Operator can get these now 'broken' plugins to run, without trying to reach out to the plugin developers themselves.

    I don't know how to compile java plugins. I have several addons that have been running that play a major role in the server experience, and those addon developers are no longer around to 'fix' their code to work with this new safeguard.

    Why hasn't the bukkit team given people like me an option to disable this safeguard?

    I'm solely responsible for my server. I always have been.
    If I'm willing to run the risk of burning my server to the ground, then I being the owner / operator of my server should have that option.

    It's nothing that a restore from backup couldn't fix anyway.

    My point is this:

    There needs to be an option ( maybe within bukkit.yml ) that allows me to disable this safeguard if I want to.
    I don't really appreciate being protected from myself.

    Please consider adding a 'disable safeguard' option somewhere in any future bukkit releases. Have the option set to 'false' by default so server owners like myself have to manually go in and disable it.

    Thanks
     
Thread Status:
Not open for further replies.

Share This Page