That plugin approval

Discussion in 'BukkitDev Information and Feedback' started by blint66, Jul 16, 2014.

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

    Lolmewn

    StealthBravo Very well said.

    I'd like to add that we are actively working on getting the queue down as fast as possible again (especially since holidays etc). What this basically means is that I keep poking everyone up until the point where's it's starting to get annoying to work on the queue.
    Any suggestions are of course welcome, always. Keep in mind that we've had lots of suggestions over the past few years, so hit that search button before you suggest stuff :)
     
    _LB likes this.
  2. Offline

    xTrollxDudex

    There is no solution for human judgement. Airport security could be completely automated, but another. 9/11 will inevitably occur. I can find a reference to it tomorrow.

    Also, stop complaining about approval times urg. 1.7 -> 1.8 and other major release transitions cause a lot of NMS and version based plugins to update compatibility, thereby filling up the approval queue. The community and plugin developer count rises every single day, it's no surprise to have approval times fluctuate depending on the month, whether or not it is a holiday, last minecraft update day, time of the day (or night), amount of staff online, size of the plugin, function of the plugin, how many commands the plugin has, etc...
     
  3. Offline

    fromgate

    There's no bukkit for 1.8 (and there's no Minecraft 1.8 release). So version changing is not a reason for a long approval time now.
    I'm waiting five days {edit 27.07.2014: seven days} to approval of simple project. And as I can guess, after project, uploaded file must be approved too. It will take same time (my previous file for another plugin was approved after five days)...

    So... What will happen after release of a new (1.8) craftbukkit version? Will approval process totally freeze?
     
  4. Offline

    xTrollxDudex

    I know. 1.8 is coming, and recent changes were made to a different release. I've waited about 3 days around that, and I can't care less.

    fromgate Five days are not taken to inspect and approve your project. These are five days to inspect and approve all the plugins and project on the queue up to you.

    If you think you can contribute to the approval process, you can volunteer to dev.bukkit staff and join in the approval.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Sep 14, 2019
  5. Offline

    fromgate

    I understood. I'm afraid what will happens when 1.8 released. How much my this process will take? Month? Two month?

    Sometime ago I sent an email, according to this thread. And as I understand my candidacy was rejected. Reasons for rejection I have not received (May be I have not enough Java experience). But I tried ;)
     
  6. Offline

    Maximvdw

    I wish there was a way to set priority on updates. some developers just reupload a plugin compiled with another build so players think its newer. If there would be some way to mark updates with 'features', 'bugfixes',.. it would help a lot of devs..

    But it will prob get abused anyway :s
     
    drtshock and biel like this.
  7. Offline

    Skye

    TnT What if Bukkit had an option to build releases from source via Jenkins, so plugin approval for new plugin versions only required review of commits since last release? I know you said the BukkitDev platform is in fix mode, but surely it isn't locked forever?
     
  8. Offline

    Zettelkasten

    Skye I like that solution ... most projects on BukkitDev have a public source anyway. But properly there are ways to "hide" bad commits.
     
  9. Offline

    Necrodoom

    Skye dev.bukkit doesn't know where you got your jar from, for all it knows you built it locally, so there's no promise that the Jenkins build is identical to your uploaded build.
     
  10. Offline

    Skye

    Necrodoom What do you mean? I am suggesting that BukkitDev builds the jar from source.
     
  11. Offline

    biel

    Well okay i completely understand. Maybe this sugesstion isn't applicable for the actual community but i had to say it somewhere. Everyone who reads these forums should know that what i explained is what happen most of the time. Isn't it?

    <removed random part of post>

    Good idea![diamond]

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

    Lolmewn

    Skye Unfortunately this is not a solution. If it is the case that we miss something malicious once, it'll stay in there forever. It can also be that functions that are not malicious are later used somewhere else for some malicious purpose. The risk is too big.
     
    drtshock and Necrodoom like this.
  13. Offline

    Necrodoom

    biel you just linked to a thread describing file lock, which would not be related to bukkit.
    If more information was presented, such as OS, bukkit version, and if the world is generated by server or a plugin, then it could be identified as something else.

    You pretty much linked to a thread without much information, and TnT suggesting the most common cause to said issue, I don't see the problem.
     
  14. Offline

    biel

    Necrodoom TnT Lolmewn Well we are mixing 4+ conversations in this thread. I see bukkit and bukkit team is on a "hold position" status which isn't bad. Maybe i'm wrong and this behavior is a must do for a community as large as bukkit's one. I don't know. You got the reason this time! I'm (unlike bukkit xD) open-minded so you convinced me!
     
  15. Offline

    Necrodoom

    biel you don't even attempt to explain why what you said is correct, or better than the current situation. You just claim its outright wrong, and that's it.
     
  16. Offline

    Skye

    Lolmewn Are you saying that BukkitDev doesn't already face those same risks with the current review process? If somebody succeeds in publishing malicious code due to a staff member's mistake, the jar is going to sit on BukkitDev until a user reports it. In such cases, the author would just chill on it and hope for the best, rather than bring his plugin under further scrutiny.

    A plugin reviewer would still need to trace code from new commits as far into the full source as needed, but it would be much faster than having to decompile and check all of it.
     
  17. Offline

    Maximvdw

    The point is that a lot of plugins are not equally approved...
    1) You are not allowed to check for specific names (like when you as an author join)
    2) You are not allowed to fetch data from remote sources

    MCbans for example breaks both of these because it gets past the 2nd rule.. You get "xxxx is an MCbans Admin" everyone time they join because it fetches those name from their site.

    Makes me feel sad that I can't even upload plugins that use a remote API while 'the big plugins' can....

    Or when an update gets rejected 2 times for 'Obfuscation' because you use Reflection to get obfuscated code in minecraft...

    Or when an update gets rejected because you use your own (better) curse updater but are forced to use some crappy updater that doesn't work as I want it to..
     
  18. Offline

    Necrodoom

    Maximvdw I think you need to read the guidelines again, because there's nothing against fetching data if you follow the guidelines, as well as the updater.

    If you think a plugin is breaking the rules, report it.
     
  19. Offline

    Maximvdw

    I have reported 5 plugins since I joined bukkit, all of them are still unchanged and some of them filled with comments of people complaining "it deleted my map" ,etc..

    PS: Back in the days there was like a triangle to report, where is it now?
     
  20. Offline

    Necrodoom

    Maximvdw these I reported were handled fine.
    If a plugin is malicious, then it would be removed as noticed.
    All plugins follow the exact same guidelines, small as big. As essentials support I can confirm that.
     
  21. Offline

    _LB

    Scroll to the top of the page and look at the bottom right corner.
     
  22. Offline

    Maximvdw

    What am I missing
    [​IMG]
    [​IMG]
    Complete right hand side scrolled up (when on a plugin page)
    [​IMG]
     
  23. Offline

    _LB

    Maximvdw
    [​IMG]
    It stays at the same spot on your view when you scroll, do you maybe have javascript disabled?
     
  24. Offline

    Maximvdw

    no, what browser are you using?
     
  25. Offline

    jthort

    Maximvdw If you scroll far enough, it disappears. Maybe that's why you didn't see it?

    (Google chrome, windows 7)
     
  26. Offline

    _LB

    Maximvdw Google Chrome on Windows 7.

    Maybe this should be split into a separate thread by a moderator?
     
  27. Offline

    lol768

    Most objects can be reported, so try throwing a "/report" onto the end of the URL and you should get a report form as a workaround.
     
  28. Offline

    Maximvdw

    yes thats what I did eventually
     
  29. Offline

    Lolmewn

    Skye This would mean that there is one malicious build up. The staff aren't perfect, we sometimes miss something and something slip through. However, the chance of it slipping through again are much smaller if the full source is checked every time, which is what happens now. If a malicious file is found, the older files are also checked for this.
    It simply is the most "safe" way to go. I like the suggestion, but trading speed for safety is something I don't really like.
     
  30. Offline

    Skye

    Lolmewn It's true that my suggestion could result in malicious code being present in multiple builds. However, under the current system, such builds would be available for download until someone reports it, or if another build (with the malicious code still present) is uploaded for review.

    Personally, if I wanted to put a trojan in my plugin and it made it through the review process, I would stop updating my plugin and let people keep downloading the last version until someone notices. Or release a new build without the trojan and find a clever way of getting users to download the previous version; or download and inject a class from a previous version.

    What I am trying to say is that the current system makes a huge tradeoff of speed for a very slight gain in safety. As it is impossible to catch everything, with the only real fail-safe being user reports, perhaps it would be wise to reconsider this tradeoff.

    Edit: Or a better question would be, how many members could the Bukkit community gain/lose from a quicker plugin approval process versus how many members would it gain/lose from a mistake the community considers inherent risk?
     
Thread Status:
Not open for further replies.

Share This Page