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

    supersean63

    TWhy must you keep removing my post about my problem?
     
  3. Offline

    TnT

    jeffro1001
    There is no way to disable this safeguard. Find the developers and get them to update their plugins. If they have abandoned them and they are open source, you can try to find a new developer who will keep them updated.

    Since internals got renamed in 1.4.6, plugins would have broken anyway. This safeguard was there to stop your server from crashing - which is would have without this safeguard. Those methods needed to be renamed for a long time but we were hesitant to do so without this kind of check in place. We needed to rename them for the sake of fast updates and code sanity. Better internal code helps everyone.

    Because this isn't Bukkit Help, where you can go to find help for your server problems.
     
  4. Where to suggest features for the bukkit API?
     
  5. Offline

    AravanFox

    I have 63 plugins that i am currently copying and deleting to start over... Some however, haven't been updated in ages. Like, GravelClay since March, though it's been working perfectly. My players expect that they can make use of gravel by adding water... If a plugin like this breaks, what kind of error do I get? I'm trying to plan ahead, since, with 63 plugins, updates are a huge hassle. I need to know what i'm looking for.
     
  6. Offline

    TnT

    If it broke due to this commit, you will see an error in your console. Plugins that only utilize the Bukkit API methods that haven't changed will continue to work. Best to try them out on a test server to see.
     
    AravanFox likes this.
  7. Offline

    Chikyuno

    I don't like this.
    What you do is vandalize plugins and scare off plugin devs.
    Maybe you have too much of them and don't respect them enough.

    I personally am now at a point to say stop and keep the current version.
    A thing I maybe should have done back at 1.7.3 beta.
    Bye bye Bukkit.
     
    Derthmonuter likes this.
  8. Offline

    TnT

    We don't vandalize anyone. There are changes coming to NMS (some changes we have seen already) and this commit helps safeguard against that.

    We have a lot of respect for plugin developers. If we didn't, there wouldn't be a Bukkit API to begin with, as that was created so developers would have stable code to create plugins with.
     
  9. Offline

    Chikyuno

    I'm sorry but the Bukkit API is by far not enough for the more advanced and complicated plugins. And it probably never can be because you can't cover everything.
    You could have made a plugin.yml entry to check for and which could easily be changed even by code inexperienced seerver admins if they like to put their server on a risk with a single plugin. Or in addition made a command line option to bypass this.
    But no you decided to break the wohle thing without any other option than change all Minecraft and CraftBukkit dependent code in plugins. I've got enough stress now, sorry...
     
    XemsDoom likes this.
  10. Offline

    jeffro1001


    Thanks for the reply TnT.
    The reason I asked is that I was under the impression you could bypass it, based on what EvilSeph said:

    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.

    What sort of tool do I need to update the old plugins?

    Having the actual developer update it is more than likely not going to happen, since his plugin page has seen no action since Feb.
     
  11. Offline

    s32ialx

    jeffro1001

    I think what they mean is someone is eventually going to basically reverse engineer the server and release an "branch" of bukkit that's not from the Official source with a bypass included OR someone will create a tool to bypass it, more then likely both.
     
  12. Offline

    TnT

    Some members of this community have already talked about creating tools to update these plugins, hence EvilSeph's reference. Personally, I wouldn't touch those tools, so I don't know where you can find them.
    A plugin.yml entry, to be useful, would have to be mandatory. A mandatory plugin.yml feature would break every single plugin (even those that only rely on API), every single Minecraft version. I would rather only have this affect plugins that would break anyway, not affect plugins that wouldn't be affected at all. This cannot be a optional configuration as many developers (those who already want to work around this commit) wouldn't use it. This would force our BukkitDev staff to have to police this option, or be completely useless. I'll note here, for a long time developers could have had code to ensure it didn't work on different versions themselves, and only a select few chose to do so. Once we start enforcing that plugin.yml option, people will expect us to police other options as well - like bad permissions entries, bad plugin.yml configurations and even bad coding practices. That would ensure we lose every one of our BukkitDev volunteers due to the heavy workload imposed, and its already quite demanding. Trust me, its already been suggested to have us police those other situations I've mentioned and we've declined every time. We are not there to be police on how to code plugins, we are there to keep server administrators safe from malicious developers.

    Keep in mind, as 1.4.6 has shown, and 1.5 will continue to show, that code is not to be trusted between Minecraft versions. This action was the lesser of two evils (the other option being to let servers suffer horribly under the upcoming changes), and we've done our best to warn people it was coming. We've already seen the results of what can happen when the code barely changes (as people keep pointing out some of those plugins that poke into server internals still work), and its always hard for servers to deal with. This change was implemented over a week before the 1.4.5 RB came out, giving developers time to prepare.
     
  13. Offline

    bergerkiller

    TnT
    But that is wrong! It is only needed for plugins that interact with MC! You can simply check the source code of classes loaded by the PluginClassLoader before loading to see if it uses NMS, and if it does, and no specification is set in the plugin.yml, an error is thrown. No one other than NMS developers are affected by this.

    All answered in one small reply. Isn't that nice? See the first part. And also, no one said it was mandatory to do a version check yourself. Again, no communication with us before pushing these changes. No official post saying that we should do MC version checks. No stating the consequences. You are now trying to make us belief that we already knew that we were doing bad things for months and that this entire commit is a punishment for that? It's like hitting a child because he doesn't understand that 5 + 5 = 10 on his first lesson on school.

    Mhhh why not
    And now you are. Congratulations, you just proved yourself wrong with an argument against your own changes. See: " I'll note here, for a long time developers could have had code to ensure it didn't work on different versions themselves, and only a select few chose to do so."

    It was completely trusted in 1.4.6. The only changes I've seen were caused by your server developers, not Mojang, adding changes to the nms ItemStack, netServerhandler and other classes, and changing the logic of BlockFace. It can not be trusted, indeed, BECAUSE OF YOU, not because of Minecraft changing, because of your developers causing changes. Method changes are bound to happen, yes, but can be prevented by using a library to invoke them, or by you by de-obfuscating them.

    Oh really? The lesser of two evils? And the 'other option' is included in the first option. If you didn't notice already, servers now have to suffer horribly because they have to wait for plugins to start supporting your changes. I don't see how, not having these changes, would make this any more horrible. I actually think it would be less horrible.

    You didn't, you stated these changes days after actually pushing out the commit. There was no warning, at all, that this was going to happen.

    I've had barely time to prepare, I am in fact still fixing up countless of bugs because of your nice CraftBukkit developers (again, NOT Mojang) hiding all ItemStack constructors, causing lost references all over the place. The static methods do not work, because 'get handle' doesn't actually get the handle, it gets a clone.

    *yawn* I'm off to bed again, have fun repeating the arguments that I just refuted for the 5th time this week. It's not all that hard to hide 'the other truth' from your message, but people like me that do know the other half are not going to take it. You can keep on ignoring it, but it will return, forever.

    Oh and for those reading all of this: You may be thinking that I am going to continue on and on until I get what I want. Actually, I am trying to ease the workload for the people continuing my plugins. Luckily TnT was nice enough to move the entire thread that I made for this into a hidden section of Bukkit (Bukkit+) so no one could see it. Isn't he a nice guy, preventing me from finding substitutes? I would've liked off-topic better, as that is a way more appropriate location.

    I have already decided to leave, so to me all these changes mean nothing. I just want to see how far this is going to have to escalate before Bukkit staff finally realizes that the things they say are not 100% positive for the change. Thus, they should state the (+) AND (-) points of this change in the main post, not only the (+) point(s). It's already clear that they are unable to make the (+) come out better than the (-), so better let the community say something about it? Thank you.
     
  14. Offline

    TnT

    Easy, except we have no means to do that currently and if we did would very likely slow down server start times. This is all so you can avoid fixing your plugins due to this commit. You can explain to server administrators why their servers now start much slower than before. Believe it or not, checking for server internals on startup was debated, but we couldn't find a good way to do that without hindering performance.

    Besides, that ignores the point we've mentioned multiple times, a plugin.yml specific code would imply we support modifying internal code. We do not support that, but we do not hinder the use of internal code. Again, if you want to avoid doing anything except rename 1.4.5 to 1.4.6 you are free to do so, which is extremely minimal effort.

    Wait, you didn't know server internals were volatile? NoLagg breaks every Minecraft update. If it wasn't volatile, why did your plugin break because of tying into those volatile internals? What would you have BKCommonLib if you didn't know that already? Are you seriously expecting me to believe you didn't know it was volatile?

    You didn't. If you cared to not break servers between builds, you would have asked for a way to version code. Spout implemented versioning in their code, something I applaud them for, because of serious bugs caused by their plugin. This all but removed reports about Spout plugin causing issues on Bukkit Help and leaky. It was a fantastic idea for them to do that.

    Those changes came as part of the ItemMeta API (ItemStack). Keep this on topic - this thread isn't about your troubles using the new API, its about this commit. A desire for faster updates on MC releases resulted in the renames. We didn't have to make the changes, but I think being able to have more sane code for the sake of maintaining code is a good reason. We've wanted to make those changes for a while, but knew it would have horrible consequences to servers if we did. Then we thought of this commit and realized we can now speed up our update process without breaking servers. You take everything so personally it seems.

    My server is running fine, and avoided suffering horribly because of this change. Without this commit servers would be suffering horribly due to the rename that happened in 1.4.6, and further when 1.5 comes out. Do you really want that to happen for the sake of you avoiding updating your plugins?

    So the week long discussion on GitHub wasn't enough for you? How many times do we have to state that dev builds are meant for this type of change to happen? A promoted build, which is what server owners should use unless they are willing to take the risks of using dev builds, are where these changes get considered final. You may disagree, but that is how our release system works. Please, don't turn this into a debate about our release methodology, that is another topic.

    I am sorry we need to make changes to volatile code for the sake of long term stability and implementing new, awesome features like the ItemMeta API.

    There you go, refuted your points yet again. I know you like circular arguments, but this commit is here to stay. Work with it, work around it, or abandon the community that uses your plugins. I see you've chosen the last option.
     
  15. Offline

    s32ialx

    This is what I was talking about with the whole "Tuesday on the WoW forums" all these people whining about the developer builds that are not designed for main stream servers. sorry bukkit is not mojang they cannot push there server 100% comparable to mojangs same day. they release dev builds to help plugin developers keep up to date with server releases "with no promise of it being 100% perfect off the bat"

    So what they renamed a few calls to better sure mojangs new changes, they added this version check IMO to weed out the lazy developers that ruin peoples servers because they come to depend on a plugin that stops working randomly and the dev has no been seen for ages.

    I mean correct me if I am wrong TNT


    bergerkiller
    I mean you are abandoning Bukkit and you want people to take over your work... but All I hear is you saying you want it and that Bukkit "hid your forum topic on it"... well your making enough noise about it that I'm sure people if they want to will read it... I mean it is your signature
     
  16. TnT

    Is it possible to equip skeletons with the bukkit API?
     
  17. This ^
     
  18. Offline

    bergerkiller

    TnT
    Sigh....

    Well providing that I made a class remapper plugin that had ZERO performance problems on the server (note that classes are loaded ONCE), this is simply not true. It does not hinder performance at all. I used ASM, a very small library that works way above my own expectations.


    And in reply to that, I stated the use of 'CraftJavaPlugin' in CraftBukkit. If you do not want it to be part of the API, make it part of the implementation. It is not a minimal effort, because the plugins have to be uploaded again, all changelogs need to be updated, the same debug cycle can start all over again and I can wait for it to be approved answering 100 comments asking when it will be available.


    NoLagg is not volatile. If you did not notice this already, I've done countless changes to make it use BKCommonLib to overcome these incompatibilities. Indeed, BKCommonLib needs to be updated, but it is a driver, it makes perfect sense. And this is only ONE plugin. Right now, I will have to update 8 of them instead.


    Again, you never stated anywhere that I had to do that? I was in the middle of massive debugging and feature adding, how can I possibly think of versioning in this coding frenzy of mine? You are assuming that we all already knew this, I did not, at all. You need to back up your claim with an actual message somewhere that this was a requirement, and point me to that.


    All right then, but for what reason was it needed to do pointless class renames? For a fact, I know that you are deobfuscating all the code, including the class names. Class name changes are part of the deobufscation team, and clearly they decided to rename the class, not Mojang. If this is not correct, please point me in the right direction and tell me what source you have for the nms internals.


    Your server is not the server of others. Please look over the comments on my NoLagg page. I was scared shitless knowing that so many people were using it that there was such a huge feedback on the project having big delays. Unfortunately, servers DO suffer greatly. If all of these changes didn't happen, I could've uploaded updated versions a week ago, but I am still fixing up countless of problems caused by it. I do admit, however, that the 'going down' of gist, the inability to access Bukkit pages and the author changes play a big role in all of this. However, knowing that this sort of updating has to be done every 1 to 2 weeks, I do not particularly envy the people continuing it. Depending on how aggressive the amount of MC changes are, they could end up in a pretty busy situation.


    In what way does that support the changes at all, other than saying that Bukkit processing acts as a dictatorship? My old example:
    Or, of course, the BlockFace example:
    Neither the above was explained on the forums, 'it just happened'. I think one important aspect here is the lack of communication between Bukkit staff and the plugin developers. Before you are going to make huge breaking changes that affect everyone, you should inform us well ahead in time. I've spend several days to get TrainCarts working again, this includes the waiting time before the material classes were fixed.

    And why is it not suitable to post about it AFTER performing the changes? Because a lot of server admins use the latest development build, or more often, they use Spigot. Unfortunately, I get to hear about these changes way too late. This is not a good thing.

    Features that do not apply to me, because they've been delayed for months. But you are right, new features can be useful, though I do not see how hiding ItemStack constructors is important with the implementation of ItemMeta. It is unsupported code. Why hide stuff or make classes final? From an API standpoint, it has no additional value to do that.

    Anyway

    Since this is too much repetition anyhow, I think it is best if I write an essay on gist (It's down, somewhere else) instead, showing all the good and all the bad points. I will update that page with all the information that is lacking or that you find incorrect, I think that is a bit more productive than going left and right for days.
     
    Ne0nx3r0 and s32ialx like this.
  19. Offline

    vgmddg

    I understand and agree with the general purpose and reason behind adding the safeguard feature, which is to protect a plugin compiled for a previous version of MineCraft/CraftBukkit from accidentally doing something completely different upon updating to a new version of MineCraft. However, the lack of user approval testing via a beta build, much less advance public (on-site) warning at all, and in fact the final implementation of the feature itself, were done very poorly.
    A feature as game-changing as this needs at least a week or two of advance public warning before implementation. In addition, you should not have put the new system as it is directly in the Recommended build that everyone was waiting for, and called it a Recommended build, if it shuts down so many plugins at one time, EVEN IF that was its intended function. I realize that there wasn't really much time for action with MineCraft 1.4.6 out now and more frequent updates later, but I still think there was a better way to show the new feature.

    I think a better way to do it would be to put out the Recommended build without the feature, and then immediately after, post a Beta build with the feature.
    -----
    The addition itself should have been more user friendly – and configurable – as well. If you're going to add in as big a feature as this, you need to allow server administrators to turn it off and/or modify the effects of SafeGuard. Add "SafeGuard" field to Bukkit.yml to determine what the safeguard does with a "potentially damaging plugin".
    Possible values:
    • FailPlugin - Bukkit will not load the plugin if it does not meet the requirements, and will continue loading the server. Upon otherwise successful load of the server (and at the plugin failure event as well if possible), Bukkit will write out to console a clear and user friendly listing of which plugins failed to load. If possible or if already occurs, when doing /plugins in-game failed plugins should appear in red to indicate they are bad.
    • FailServer - On recognizing a bad plugin, Bukkit will stop loading the server and (after searching for other invalid plugins) will again provide a user-friendly listing of what plugins failed before quitting. The idea behind stopping the server altogether is if the "potentially damaging plugins" are core parts of the server, like Essentials, or maintain in-game security, like WorldGuard. If these are not loaded the much more real threat of griefers may more likely outweigh the chance that a plugin that doesn't match the current version could do something bad. At this point the admin needs to decide whether to wait for an update, uninstall the plugin, or bypass safeguard and possibly have issues from the plugin. This brings me to my next 2 settings:
    • LoadMessage: This setting will allow the server to load the "potentially unstable plugin", but will again provide a message that the plugin is out of date and could potentially be dangerous. When using this setting and the one below, the admin should be well aware of the potential dangers of loading out of date plugins.
    • Disabled: Plugin loads uninhibited, no messages at all. This mode should be made clear to be HIGHLY UNRECOMMENDED, but an admin could want to use this if they have an out of date plugin that still seems to work, but they are annoyed at the messages safeguard gives all the time.
    • (Optional) LimitedFunctionality: With this setting, when safeguard detects that a plugin is out of date, before going "BANHAMMER!" or "Move along.", to the plugin, it can first notify the plugin of its obsolescence, and it can either know for itself to fail gracefully, or choose to operate in a limited capacity if it can, where maybe it allows only commands that don't rely on native MineCraft or CraftBukkit code. This allows plugins that cover a wide area of purposes like Essentials to still function in some regards with a slightly higher (though not complete) level of safety until the new version can be put out. With something like this, APIs will most likely need to be created to handle this coordination.
    I understand that you guys really don't want to have options like this, in part because (from the FAQ from Git-hub):
    However, like it or not your Bukkit API is not complete, and some plugins need to bypass the API to support features not yet otherwise available.
    Also to note, the following quote from the public post on the safeguard does conflict greatly with the quote I copied above:
    Both quotes were made by EvilSeth. (Note: Seth, I do really like you, and I like the work that you and the rest of the Bukkit team do on Bukkit, but I have to call you on this.)

    The amount of support you give to admins whose configs are set to non-fail values is up to you, but just like if a plugin dev updates his code to bypass safeguard without checking for version breaks any world corruption is their fault; a server admin should be able to bypass the safeguard as well – say, while waiting for a new version to come out – and have any server burning be their own fault. Give us allowance for blame as well.
    ----------
    To summarize the above:
    • If a plugin developer chooses to bypass the safeguard without actually doing any updating (and tells no one about it), it's the plugin developer's fault.
    • If a server administrator decides to bypass the safeguard for a little while, say, to wait for a new version of a plugin, then it's the server administrator's fault.
    • If you (Bukkit devs) decide to implement a new "feature" that breaks hundreds of plugins and not tell anyone (publicly) about it or give them time to react, then servers burning from reduced functionality is YOUR fault.
    Please implement this feature to allow server admins to modify safeguard functionality. It's very needed.
     
    jeffro1001, bergerkiller and s32ialx like this.
  20. Offline

    luciddream

    Great, so now the big ol' plugin I maintain for my server is now broken, with really frustrating to debug errors, and I'm going to have to make even more changes every update. Yeah this makes a lot of sense given that all of this Bukkit crap is going to be replaced with the mod API anyway, thanks for making my life a hell of a lot more frustrating in the meantime. I quit modding Minecraft because of crap like this, thanks for making sure that decision is reinforced constantly. I appreciate all the work that went into Bukkit, but come on guys, cut us plugin developers a little slack sometimes, its already a huge hassle to work around Minecraft's limitations, its just a huge kick in the teeth to now have to deal with these new changes knowing full well that all the effort is basically wasted with the new API around the corner.
     
  21. Offline

    TheBeast808

    I made the second comment in this thread but was ignored. Can somebody in an appropriate position please respond to my post? (Quoted below)

     
  22. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    TheBeast808 In the time since the commit went up we've worked with devs to add new API, and will continue to do so.
     
  23. Offline

    mouffles

    As said before by many admins, you don't let us the choice and that's not the good way to respect the real end users of bukkit wich use, make grow and donate time and money for bukkit.
    I don't think that there's a single server admin who is happy with this api update, if you wanted to force developpers to update and change their habbit, you had to deal with them but not to take us as hostages and wait for us to beg and cry updates to developpers, that's NOT the good way, and the real one who are screwed it's us, the end users.

    Cause we as end users we need plugins because bukkit is useless without them and have no purpose to exist.
    And if we want to use old and abandonned plugins, we are the only people who can say that its a security risk for us, you don't have to protect us from anything, we can do it ourselves.

    I'm quite sure like berger told it at the very beginning of the thread that you do this for endusers wich are NOT administrators, but who will use plugins in further minecraft update.

    And as an end user administrator, all my respect go to the plugins developpers.
     
    russjr08, luciddream and vgmddg like this.
  24. Offline

    StarScore

    I love this thread ^^ It kinda tells me what devs i should avoid in my next plugin update run but also what devs i should look into more. Rather choose those that goes through the code carefully then just think it works. running around 60plugins, time to clean up and change some of them ^^
     
  25. Offline

    Codex Arcanum

    Honestly, I don't want to get to involved in the big unpleasant discussion that has emerged around this issue, and regardless of what happens, I am not going to fly off in a towering rage and quit Bukkit. However, I feel it would be irresponsible not to state my opinion when a big change like this is occurring.

    As both a developer, and a server administrator, I am rather unhappy with this update. I have personally never had problems with a plugin malfunctioning due to outdated NMS code, but I understand the need to take some action to deal with this problem. I don't even object to the installation of a feature that throws errors on startup of outdated plugins containing NMS calls. However, I think that Bukkit itself should allow you to run these outdated plugins if you so choose, without having to rely on an external tool, and I don't think that is an unreasonable request.
     
    vgmddg likes this.
  26. Offline

    chaseoes

    I honestly don't see the big deal here..
    It's not too hard for me to change one or two numbers in my imports then recompile.

    Developers using NMS/CraftBukkit should be updating their plugin every Minecraft update anyways.
     
    4am likes this.
  27. Offline

    jeffro1001

    It's probably not a big deal for a plugin developer to go into their code and update a few lines to make the new bukkit accept it.
    The problem is that some servers have addons that play a big part of their server, and the developer is no longer around to fix those few lines.

    These now 'broken' addons might still work, but now that the 'big brother' feature wont even let it attempt to run, the operators of these servers are SOL.

    Protection is nice, cudos to bukkit, but removing the option to allow outdated addons to run is not nice.

    We know what's best for you... that's fine if you're 3.
     
    russjr08, Codex Arcanum and vgmddg like this.
  28. Offline

    Codex Arcanum

    For the record, if you want to make it so that every single admin without common sense on the entire Bukkit forums isn't hitting the "run anyway" button on outdated plugins, you could make it require something (sarcasm) incredibly difficult and knowledge intensive, like command line arguments (/sarcasm).

    I emphatically second this statement.
     
    Tsaukpaetra and vgmddg like this.
  29. Offline

    vgmddg

    Third. Perhaps we are server administrators who understand the risks of running a plugin not yet completely up-to-date, yet still want to run it anyway because it provides core functionality to our server. Perhaps we are plugin developers who want to bypass the safeguard server-side on a private test server so we can see what currently happens when we try to run our plugin, so we can pick at it more and try to debug it more effectively, so we can put out a safeguard-safe version to the public faster.

    If it's at all possible, can you please consider my suggestion on the previous page to add a configuration option to the Bukkit.yml to determine what to do with an out-of-date plugin? Don't just bark "No" at this post and move on. Do read the other post please, as there is important information about my views on this event that I'd like to share.
     
  30. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    I don't think you've ever written a plugin that touches net.minecraft.server, or particularly have any idea what this safeguard actually does. Please re-read the first post.
     
  31. Offline

    luciddream

    I really don't understand why this is necessary all of a sudden, given the proper API is coming eventually. Could some bukkit staff explain that? It seems like a lot of disruption for devs and server administrators for a questionable benefit to a platform that has a death sentence already.
     
Thread Status:
Not open for further replies.

Share This Page