Questions

Discussion in 'BukkitDev Information and Feedback' started by Bjornke, Apr 3, 2013.

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

    Bjornke

    So I do have a question for you all: Why MUST Bukkit decompile everything to approve?

    Some notes: I understand the basic reasoning: you don't want malicious files to be uploaded which is perfectly fine with me, and I fully support this, however I do have a bone to pick as well.

    Decompiling of Java programs is extremely easy, none the less. And I understand that, and thus why if you develop with Java you do have to be aware of this, as opposed to other languages such as C which are extraordinarily difficult to decompile, especially if protected.

    My bone ot pick has to do with this: This is Bukkit, and there's not much you can really "do" to damage someone's server or whatnot with a plugin beyond destroying a map or making the plugin always crash. You can't steal passwords or player's login information, you can't do anything super maliscious to the server directly, although I wouldn't want to have a map destroyed, it's not like anyone wouldn't notice. The smaller things like pragmatically giving certain people op or reporting server IPs and such aren't that big of an issue, and frankly, you'd know about that kind of thing too when some random user logs in and is an OP.

    The WORST case scenario would be someone trying to us ea bukkit plugin to exploit a JAVA bug or vulnerability. However let's be real here folks: if I was a hacker, would I want to do it via a plugin that may get 100 views? No, because that'd be stupid, I'd never be able to widely target people. This is why the MAJORITY of Java exploits are actually JavaScript based. Websites get tons of views. Bukkit plugins? That's like a joke unless your goal was to control the servers of a few enemies of yours? And what's the chances of that actually happening? Slim to none.

    Like I said, I don't mind the fact that you check plugins for malicious code, but the reality is that you could do this for 4 years before you ever see 1 actually serious malicious line of code (not some dumby giving himself OP through his plugin). On top of all this, wouldn't a quick little virus scan find 99.99% of all known exploits? Do you honestly think you'll see the exploit if a large network like McAfee or Norton hasn't seen it yet? Probably not. You're not stopping an kind of exploit by "reviewing" the code that hasn't been seen before by large companies that do this ALL DAY every day.

    I just feel like, the developers of plugins are not trusted at all, and that some of the requirements for approval contribute to LONG waits, and general grumpiness among developers. It would be nice to publish an update and have it approved in an hour, or instantly because an automated scan found nothing wrong with it. The whole decompile ordeal, actually is very intrusive, especially for plugins with All Rights Reserved licenses. This anti-competitiveness at it's best, and anti-developer at it's best. A lot of people who WOULD be interested in developing a plugin are turned off right from the start because they're faced with this massive list of requirements and what seems like a ruthless inspection of your ethics and works. (Not that t is of course, but can seem that way)

    But as I said, I understand the logic behind why, and am perfectly fine with it, I'm just trying to get my general opinion of it out there, in that I personally believe if we changed how files were inspected, we could open those iron bars a little bit more so new devs (and old ones) could publish and develop more freely.

    And one last thing, why is it mandatory to have a turn off for update checks? It seems like the point of it is to justify forcing developers to give a choice for it, because honestly, you're not going to steal or damage anything by looking up a text document to see if the plugin is out of date or something.....???
     
  2. Offline

    TnT

    You can potentially destroy a server, its backups and many hours of work by gaining OP on a server. Grab OP on a server with WorldEdit, any block logging plugin, or numerous other plugins and one could do serious, possibly irreparable damage. It is not always possible to disable OP abilites on plugins. Many plugins allow for both OP only, and permission based servers to reach both large and small scale servers. If it wasn't worth while to gain OP on a server to wreak havoc, people wouldn't be uploading files multiple times a week in an attempt to gain OP on some unsuspecting server. This is why every plugin on BukkitDev gets checked - we ensure server admins don't need to know Java to protect themselves. Server administrators like knowing their server is safe, which is why many will only get plugins from BukkitDev.

    The update check is important to be disabled. How do you know as a developer what is right for the server admin? Many times, yes, you will want to keep plugins up to date, but what about the times when an admin would want to stay on an older version of the plugin because a newer version removes (or adds) functionality the server admin needs? If you force plugin updates onto the server, the server admin has no ability to stay on an existing version, since as soon as they downgrade, the update will be forced. This doesn't even touch on the fact that a server admin should know what changes come with the updated version of the plugin before they download and run it. I can understand thinking its best to force updates on the server admin because you've fixed an important bug, but ultimately its up to the server admin to run their server, their way. The update check only allows for the server admin to retain control of how they want to run their server, and takes nothing away from the developer.
     
    lol768, drtshock and np98765 like this.
Thread Status:
Not open for further replies.

Share This Page