File Approvement is.... yeah you know.... -.-

Discussion in 'BukkitDev Information and Feedback' started by fredlllll, May 6, 2012.

Thread Status:
Not open for further replies.
  1. when i upload a file to devbukkit i want it to be immediately available. i dont want to wait 10 hours plus. when i release a new version i want it to be there in the moment i uploaded it. maybe there should be approvements for the first 3 files i upload and then its automatically free.
    as everyone wants to load the files on devbukkit and not sourceforge, people complain that the file is not there... but it is...
    please remove that annyoing file approvement thing
     
    emericask8ur likes this.
  2. Offline

    Lolmewn

    I think it's called patience.
     
  3. Offline

    jorisk322

    It's there for a reason, but what they could do maybe is immediately make it available, but place a red mark or something to tell the user the file has not yet been approved and there is risk involved in downloading the file.
     
    rmsy, jtjj222, Royal_Soda and 7 others like this.
  4. Offline

    obnoxint

    Do you own the site linked in your signature? If you do, why don't you host the files yourself?

    I always put a download link to the most recent version of the file on the projects main page. If people like to download the file from dev.bukkit.org they still are able to, but my site has proven being more available :p . Also people seem to appreciate it: 90% of all downloads are from my site.
     
  5. Offline

    coldandtired

    The file is available straight away but doesn't get added to the recent files box.

    Just post a comment with a direct link to the file.
     
  6. best idea so far :p

    and its also hosted on sourceforge. and there it is available immediately. so why is dev bukkit like "oh every file has to be approved" ? works on much other sites without approval
     
  7. Offline

    Deleted user

    Every file has to be approved so that plugins aren't being created that have 5 lines of code in it.
     
  8. Offline

    jorisk322

    Hmm. I'll write a 500.000 lines plugin. Then in the next update I remove 499,995 of them?
     
    Deleted user likes this.
  9. Offline

    Superkabii

    And have those five do nothing but give you op on every server that uses it.
     
  10. well as i said: approve the plugin once. but not every release of it
     
  11. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    Files require approval so we can check that it's
    1) A plugin (You'd be really surprised what gets submitted as a "plugin")
    2) Harmless. People submit malicious plugins, or add malicious code.

    We don't wish BukkitDev to be known as a site hosting fake plugins or exploits. I prefer a few hours inconvenience over compromising people's servers.
     
    tuxed, ACStache, jtjj222 and 6 others like this.
  12. Offline

    Gravity

    The reason, as mbaxter described, that we require approval is to protect users of BukkitDev and that the quality is there. People upload malicious code to the site all the time, and if it was not for approval, someone would have been affected by it.
     
    np98765 and kroltan like this.
  13. last file took 7 hours...
    so what about "trusted developers" as a rank or something?
     
  14. Offline

    TnT

    I dislike the idea of auto-approving plugins. I prefer having the manual, human, interaction between the uploaded file, and the file getting presented to the public.

    I feel the safety it offers more than makes up for the delay in the plugin reaching the public.
     
    jtjj222, devilquak, np98765 and 3 others like this.
  15. What about a script approving files instead?

    I don't know if its possible to find malicious code by having a .class decompiler automatically process the source, but it could scan for:

    setOp();
    Running commands in minecraft console
    HTTP fetch/sockets/access outside minecraft server
    touching other plugins
    Showing applet windows in server window system
    running system commands
    accessing files other than /plugins/pluginname/config.yml via the provided YML interface
    Setting permissions on player.
    uncancelling events cancelled by the server or another plugin.

    If anything of these are found, its piped to a manual approval process, else it gets approved instantly.

    Such a compiler could check for a propely formatted plugin.yml and (eventual) default config.yml too, and check its runs against latest craftbukkit, thus ensuring only plugins are uploaded.

    Then most plugins would get approved instantly, but some plugins that are "sensitive" would require manual inspection.
     
  16. Offline

    Gravity

    I actually made something like that a while back, but it can't find everything. We could sit there all day and make a script to detect these things, but it should ONLY be used as a backup after the files have been reviewed manually, that's the only way we can keep BukkitDev and it's users safe in good conscience.
     
  17. Offline

    7cardcha

    Make a developer trusted after a while. Trusted dev's plugin get approved automatically but get reviewed later.

    The amount of developers who would sacrifice their status for a small chance at a grief is very low. Even if they did get a malicious plugin out to 1 or 2 servers before it got taken down it is unlikely to cause any harm as he most likely won't get the servers ip.

    The error rate would be tiny and I wouldn't have to be so fucking mad at your asses constantly.
     
    ZeusAllMighty11 likes this.
  18. Offline

    Gravity

    Then we would just be going back to the plugin dev system again, pretty much. It's not helpful to the mods, and there's no way we would promote them automatically. Also, ALMOST nobody decompiles the plugins except for us. Unless a developer included a backdoor and then massively abused it to the extent that the owner of the infected server knew where it came from, there would be almost nobody who could detect that there was a backdoor, which is why we review it first.

    Also, I don't think there's any reason to put it that way, we do all that work so that BukkitDev stays safe, if you don't like using BukkitDev or giving your plugin's users peace of mind, don't use it. But don't be like that.
     
    jtjj222 and devilquak like this.
  19. Offline

    7cardcha

    Sorry i'm rage nonstop. There is nothing anybody can do about it. I've been up for(counts on fingers) 20 hours. That's not such a great idea but it doesn't need to be completely manual.
     
  20. Offline

    chaseoes

    So approve the actual projects, not each individual file.

    Or automatically approve every file, add it to a queue, and review it later. After all, you don't have to approve every post on the forums in case they break the rules, you find them later and remove them - so why not do it for BukkitDev?
     
  21. Offline

    Deleted user

    I just tag h31ix if i'm too impatient, or if the file has been sitting there for over 3 hours.
    Usually he doesn't mind, but I try to do it when he isn't doing something important, like massive coding or something ;).
     
  22. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    A post made to the forum doesn't give op to players on your server.
     
    firecopy, jtjj222, tyzoid and 9 others like this.
  23. yeah well an approved author would be very good. i would not risk my status (and my plugin) for a backdoor or some stupid kiddy shit
     
  24. Offline

    Deleted user

    Are you guys still looking for BukkitDev staff? I applied months ago, but I haven't gotten a response yet.
    I really want to become a BukkitDev staff because of reasons such as long file approval waits :)

    You might not, but other might.
     
  25. Offline

    7cardcha

    I would apply help and be legit helpful but I would get turned down for being so ragey. I'm building a reputation as a very angry person very quickly.
     
    JOPHESTUS likes this.
  26. Offline

    chaseoes

    You can TaG on BukkitDev?
     
  27. Offline

    ZachBora

    PlgLogCmd has like 5 lines of code but that doesn't make it bad.
     
    Codex Arcanum, Ytry and Deleted user like this.
  28. Offline

    kroltan

    What could exist is "trusted plugin developers", that could be elected by users, mods or via applications, and when those users uploaded files to a project, it would be instantly available for other users, but be linked directly on the "Download" link at the plugin's home page. So users could download it if they went to the files page until a moderator finally approves the file.
     
  29. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    That completely undermines the idea of making sure all file uploads are safe. Plus, there's be very few people I'd ever trust to always upload files that are safe. I'm not a very trusting person when it comes to files that can screw a server over.
     
    jtjj222, WizardCM and Codex Arcanum like this.
  30. Offline

    Gravity

    The problem is that there are inherent security risks involved with this. I'm not even talking about the author uploading something malicious (although it still could be done, a lot of people are dumb as rocks and would vote for pretty much anyone to be 'trusted') - while we can ensure the security of Curse servers, we cannot ensure the security of said 'trusted' people's accounts should they be compromised. If a trusted developer got his password stolen, computer hacked, keylogged, etc, anyone could impersonate them.

    We DBO staff have been through extensive training and gotten lots of experience detecting and handling malicious files. From my point of view, unless you've been in our shoes you don't have the qualifications to decide whether someone is malicious or not, and certainly normal users do not posses the necessary prerequisites in order to call someone's files secure. Because of this, I really have to disregard any other type of approval process; it's not like we're not open to suggestions, but changing how the system works to make it less secure is just not an option for us.
     
    tomudding, ACStache, Dashie and 2 others like this.
Thread Status:
Not open for further replies.

Share This Page