Linking to unapproved files

Discussion in 'BukkitDev Information and Feedback' started by black_ixx, Apr 4, 2013.

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


    All I meant was this. If someone really wanted to, it would not matter if it were a CI or a website.
  2. Offline


    If that were to happen we would re-evaluate our position on allowing CI links on project pages. As of yet, no one has abused that privilege.
  3. Offline


    Yeah, let's hope it doesn't happen :)
  4. Offline


    Its kind of like saying "Your not allowed to murder someone so we are making it illegal to carry any weapon except for guns, just don't abuse it."
    Hoot215, jorisk322 and CreeperShift like this.
  5. Offline


    CreeperShift the_merciless

    I'm sorry, but I have to make a comment here. I understand that you both believe you are fighting the good fight by continuing this discussion, but I promise that you're wrong.

    By not giving up, and continually using the arguments that you are using, the "idea" that off-site downloads or unapproved downloads can be linked to is getting farther and farther from becoming a reality.

    Please just let the BukkitDev Staff handle this how they deem safe and fit. This means not continually bringing up points that harm your main argument more than they help it. The BukkitDev Staff Team is fully aware of the potentials.
  6. Offline


    That comparison is completely off-base. It doesn't take in any of the actual aspects of the situation. Insinuating that we're implementing some sort of overarching, controlling rule such as "you're not allowed to do X at all" or that we allow a way to get around such a rule like "you're not allowed to do X at all, but here's a way to do it anyway, just don't use that way!" is completely wrong.

    If you want an analogy, think of the postal system. The BukkitDev Staff are the employees of the service, and we're checking each package that comes through to ensure they don't have any anthrax in them, or a bomb, or whatever. We have the right to inspect stuff and blah blah blah. Since it takes a bit for this process to be finished, we've implemented a way for customers to attach a document (the disclaimer) to their package notifying the recipient that the package was rushed there and did not go through our inspection. It's up to them whether they'd like to receive it or not; it's entirely based on their trust in the developer as we have nothing to do with the transaction. In the same way you probably trust the postal service to not deliver a bomb to your door, you have trusted the staff to review files for you. The delivery method will have completely changed (and the user will be notified very strongly of this change; we make sure of that) if you want to go through a different service to obtain your package, thus the trust in the staff is not a factor.

    It's not a perfect comparison because there's very little I could imagine that's as close to a situation as this, but your comparison is a totally different one. By your logic, we would be saying something to the effect of "You're not allowed to upload executable files to our website, but here's a special button that will upload executable without it going through the approval process. Please don't press the button!" - We're not "tempting" anyone here, nor are we providing people with a blatant method to get around our rules. We're simply moving the chain of trust away from the staff and onto the developer's shoulders (and consequently the responsibility of being informed about the developer and their files onto the user's shoulders) in the case that they should want to have a distribution point for files that otherwise wouldn't be uploaded at all onto BukkitDev.
    hawkfalcon and drtshock like this.
  7. Offline


    Wow, I'm sorry I can't believe this.
    I was under the impression that I can freely express my opinion here. (as long as I'm respecting the rules) It's funny how you tell me I'm wrong, but you know, there is never a "wrong", just 2 sides to something.

    Really, what is your problem? I'm not sure why you are insulting me here, but maybe you should try reading posts first before you reply.
    I wanted to get clarification, I got it from TnT . I don't plan continuing this anymore, I've written twice that I accept the decision and thanked him for clearing it up.

    Here, look what I wrote:

    I don't know whether you think it is your right as "BukkitDev" staff to come here and insult me, yet indicating I'm an idiot:

    I was under the impression that you can freely suggest and discuss ideas here and TnT made it pretty clear that you guys don't want to do it, which is fine with me. But don't go all out and make this "douchebag" post, yes I really have no other word for it.

    I discussed here because I did not understand the reasons behind the decision, now that I know them, I can accept them. From my point of view, a lot of what has been said "hurts your argument more than helps it" as well, yet I don't go all out and insult you because I think different. You may not understand my reasons, but at least respect them.
  8. Offline


    What if plugin pages were setup (once the plugin has an approved build) so users could click a button that says "show unapproved (unsafe) builds" and explicitly choose each time they want to download an unapproved build?

    This way devs can provide quick fixes, but users are made aware of the dangers they face.

    This could even be an option only after a plugin or dev has received 1,000 downloads, to help safeguard users against devs with no reputation.


    Alternatively, could it be setup where devs can spend Bukkit rewards points to make a dev build available? This way you essentially have to be a well known developer to provide builds, and wont do it for every build because it costs you something.

    I suppose you could also do an "expedited review" button, but that would not be very effective unless the approval was for example guaranteed within a certain timeframe.


    I understand that Bukkit's main goal is to protect users, but developers for the most part are not evil, we just want to be able to (when necessary) provide responsive updates that don't take days to be artificially allowed.
    Hoot215 and black_ixx like this.
  9. Offline



    Look, I can understand your frustration. Rightfully so! I did write a harsh post and made the mistake of not running it past my peers prior to posting it. However, I do stand by my point.

    I was not "insulting" you. I was merely attempting to provide some advice as to how you might better approach this topic. (Not at all) I actually didn't make ANY personal jabs at you. I don't know where you felt you were insulted and I was Most Definitely not posting just because I am on the BukkitDev Staff. I would have made the same post regardless hence the small disclaimer in my signature lol. (However, it seems to be less effective than I had hoped it would be...)

    You are correct in that you decided to stop discussing it, but your post determining that this discussion was "over" introduced new points which in turn moots anything afterwards.
    For example (An imaginary post to a discussion regarding favourite colour):
    The person that that post was meant for will feel obliged to respond based on the first sentence. This post resembles a psychological technique where the author attempts to appear like they "own" the conversation by "ending" it. This is what your post did.

    After that, when TnT expectedly responded, you also responded with statements that needed to be addressed. This is not ending the conversation, but continuing it with the same arguments that you originally were presenting. (Which is fair as that is your opinion and you have your right to it.)

    My point was, and still is, by extending the conversation, you are harming the ground that your arguments stood upon. It is much more effective, and far less annoying, when someone gets their point across in a single, well-versed post rather than 8 or 9. Naturally, you had little choice but to respond to many of the responses to you, but your points were Essentially the same.

    However, I do apologize for insulting you by mistake. It was not my intention, but it came out rude and for that I am sorry. I hope this doesn't come between us in our future conversations. :)
  10. Offline


    You can write a giant disclaimer and it doesn't matter really. Simply the fact that you have a tag means everyone expects you to at least be a tiny bit better than the average person. After all, you do represent the staff, may it be their opinion or not.

    The problem was that TnT and I had really different opinions and it felt like he misunderstood most of what I said, I merely wanted to show what I actually meant and I agree, that did lead to unnecessary discussion going back and forth.\

    However, what really got me with your post was that the impression of: "You are wrong, we are right. Don't do X, understand we have to Y", this alone seems really rude to me as it goes against all kind of "free thinking".

    I get your point, don't worry. If I would have tried to discuss this seriously (and not just trying to find out *WHY*), I would have made my posts clearer and better formatted.
  11. Offline


    The changes you suggest would require significant changes to the CurseForge system, and affect all the other sites that use CurseForge. While what you suggest may be possible, it will not be happening anytime soon, so we work with the system we have. Changes that would undoubtedly require significant work are just not feasible at this time.
    Regardless, this is why we specifically allow CI links already. We stick by our decision to approve all files that get uploaded to BukkitDev, as it has allowed the community one spot for a free, safe, easy to use system to get plugins for their server. Getting a bug fix out in a few hours instead of instantly is not worth countless servers being unable to run due to choosing a malicious plugin they could not possibly know was malicious.

    This discussion we have had has made me seriously reconsider the policy to allow CI links entirely, and keep our policy to disallow linking to unapproved files for many of the reasons you have outlined (which have been discussed in length already between our staff). I do not know if that was the intent you had with your posts, but it is what is being considered yet again.

    We would not allow linking directly to a website for people to download plugins for the many reasons I have outlined in this thread. Your discussion points have not persuaded me otherwise, but has rather had the opposite effect. I can only imagine this is what prompted zeeveener to state "By not giving up, and continually using the arguments that you are using, the "idea" that off-site downloads or unapproved downloads can be linked to is getting farther and farther from becoming a reality." as we have been discussing this point, again, in the staff channels. Personally, I do not like the idea of allowing CI links on BukkitDev but have been persuaded to allow them so far because it allows a way for developers to get development builds out for public consumption. We have made concessions on this area already and I do not feel we are being at all unreasonable.
  12. Offline


    I think you misunderstood my point. I'm not trying to accuse you of being controlling or anything. I was merely tryin to sum up the 3 or 4 posts prior to mine. All I'm saying is, you tell us we can't link to external sites cos the files are not checked and may be harmful however you may link to Jenkins. (Which we don't check so the files may still be harmful). If you want to use the post office as an analogy the it's like saying "if you post white envelopes, we will check them, if they are brown envelopes we will just assume that you have been good and not posted a letter bomb!"

    To be honest. I think what TNT said in post #54 sums it all up nicely. There is no huge issue here for me. As I said, my last was just an attempt at summing up what creepershift was trying to say.

    If for any reason you decide to allow un-approved downloads , i think the most simple and effective solution would be this:

    1. dev uploads file and is given option to allow downloads of the un-approved file
    2. Download link is created, and file is submitted for approval.
    3. User clicks download link.
    4. User is redirected to a page, with a disclaimer from bukkit-dev explaining the file is in the process of being checked and you cannot be sure if the file is harmful in any way. Followed by an option to download anyway.

    This process will remain until the file is authorised. Should the file be found to be (purposely) harmful the dev will be banned.

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


    You just ignored TnT's post regarding changes to CurseForge, didn't you? Bukkit can't add features to BukkitDev, they have to wait for Curse to get off their asses and do something.
  14. Offline


    Not at all, I read it all. I'm sure if you had read it properly you would have seen:

    "While what you suggest may be possible, it will not be happening anytime soon, so we work with the system we have. Changes that would undoubtedly require significant work are just not feasible at this time."

    He clearly states it is possible, and I provided a solution that would not require a 'significant amount of work' (I would think, anyway)
    My idea is just that, and I also clearly stated "if for any reason you decide to". It's just my idea of a solution if they decide to work with curse and change things slightly.
  15. I think we should try to get a compromise.

    Devs want to be able to offer downloadlinks of not-approved files without using CI. No matter how.

    Using your own website instead of CI would contain this disadvantages:
    • At websites people advertise (at least a part of the devs)
    • The websites could contain lots of annoying advertising windows, hidden downloadlinks, malwares etc.
    • Some people would stop uploading files at bukkit because at their own site they get money
    • Websites can always be changed
    • etc.
    But I think there are many ways to solve this. We just need to collect and improve ideas.

    For example this one:

    How far are you able to "edit" the Bukkit/Bukkit Dev website?

    Because I've got another idea too:

    What's about a new bukkit page:
    • Here you can link not approved files
    • It has a dangeous design -> People know/think there's a risk
    • There is a HUGE disclaimer which tells people that the files are dangerous and were not approved
    I can give you some more arguments later when I've got more time.
  16. Offline


    The CI route is the best one we've found thus far. If you don't have a CI, feel free to ask someone who does; they're typically very generous and don't mind hosting someone else's project. Allowing people to get files from their site opens up a totally different set of issues, and we're likely not going to go there. The CI rule IS the compromise, that's what we've been trying to give you guys to solve this dilemma.
  17. Offline


    Is it simple to set up a ci, if not, any one got links for a tut?
  18. Offline


    You don't need to explain yourself to me again. I stated, I accept your decision. My intent was more to find out *WHY* it makes such a big difference, then to convince you. I have my Jenkins, I will continue to use it, no harm done.
  19. Offline

  20. Offline


    Well, if the option of changing the site/policy is off the table entirely, this whole discussion is as you imply sort of futile.


    Not to anyone in particular, but what makes a continuous integration server so much more safe than any other externally hosted link?
    CreeperShift likes this.
  21. Offline


    Nothing that I'm aware of, that's the point. Why allow a ci but not anything else?
  22. Offline


    It's not that it's safer, just that it has such a specific purpose. People aren't going to create a CI to distribute their maps and executables and such, just dev builds of plugins. It's more transparent, and almost all of the time people have direct links to the source code / revision that the build was created from. There's no way we could say it's safer, just that it's more friendly towards the users and makes more sense to be allowed.
  23. Offline


    Don't bother, it's not "how is it safer", but more like "We only allow it, deal with it, we won't allow anything else"

  24. Offline


    TnT and I have explained our reasoning for its allowance in full. We're not just making sporadic rules, please don't insinuate that it is one.
  25. Offline


    It's not sporadic, but it doesn't make any sense for us plugin devs. Hence we should just accept it.
  26. Offline


    Maybe I can clear up anything that is still unclear to you. Feel free to ask, that's what I'm here for!

    The bottom line of all decisions made for BukkitDev typically have the user's security in mind. If Bukkit was a business and we were all getting paid, I would completely understand a different attitude towards this issue; "if we're paying for BukkitDev, why should we be forced through hoops to get our dev builds out?". Unfortunately, this is not the case. We are extremely lucky to be able to call on the community to create our staff teams, and they dedicate a lot of time towards doing this, but we don't expect them to have sleepless nights reviewing and re-reviewing projects to ensure they continue to serve non-malicious links on a daily basis.

    Just to gloat a tiny bit, you pay $99/year to have an iOS developer license from Apple. When you upload an app, paid Apple staff review it to make sure it's up to their standards, and that process can take a week or more. We have a team of volunteers who do the same process in a few hours. Granted, there are a few discrepancies between the two but I assume you get my gist. It's a thankless job and I don't think we should force the team through a lot more than they already deal with.

    With that in mind, the CI rules are created to A) Protect the users as best we can from malicious intent, and B) Create a system which does not overly stress our staff, all while providing a needed way for developers to distribute builds not ready for release. Believe me when I say I'm not one to throw developers under the bus; running a few projects myself I fully grasp the importance of community knowledge about dev builds as well as easy distribution of compiled changes. I was a plugin developer far before I ever became staff; I hold a lot of the same standpoints as most developers on these forums, as I'm sure most of us staff do. Through our ability to volunteer with Bukkit and see the meticulous work that goes into creating various policies and witnessing how they affect the community, I also see the importance of keeping our site sane.

    We've allowed Jenkins/CI servers because they seem like the best option in all of the aforementioned areas. They have a very specific purpose, keep the user informed, allow quick and automated build distribution, and, by using our disclaimer, don't require constant staff intervention or surveillance of a dynamic page. It may just be that these necessities are a bit more clear after seeing the site's policies being put into action, but in either case I can't expect that every developer would study the full extent of every one of the issues that are the base of a policy; that's completely unrealistic and a stupid thing to ask for. Luckily, my job solves this issue; if you don't get something, just ask! I'm actually a friendly person and would be happy to answer any questions about policies. You might understand, hearing this, why it would be difficult to see a question silenced by a community member because they think we are saying "[you] should just accept it". Bukkit is a community project, after all, and while the rules will, in the end, be created to serve the user's and the developer's interests in the best way we see fit, discussion about them is healthy.
    drtshock, tyzoid, JazzaG and 3 others like this.
  27. Offline


    And this statement is coming up every time we get a staff response, yet at the same time Tnt and other's have said that CI's do in fact not improve security.

    I think this example is really off. Remember that Bukkit is open-source, that thousands of people donate, that countless people make pull requests, create plugins, anything to give back Bukkit. I'm not saying what you are doing is wrong, but comparing it with Apple makes no sense.
    There are so many people giving back to the bukkit project, be it by pull requests, discussions, helping people, creating plugins (I mean, without plugins, who'd use bukkit?) and so on. You are essentially protecting the people who (mostly) don't contribute and put restrictions onto those who do.

    Yes, I know this is a bit exaggerated, but the truth is, I see your point, and I know what you all mean, but that does not mean it makes sense for me, hence why I'm willing to just accept it. Others who keep coming back on about allowing "other websites" should too, before TnT changes his mind and disallows CI's too :p

    Also, I appreciate the neutral discussions, don't get me wrong :) I can understand that it must be somewhat frustrating to see so many people just coming back to discuss something that must be "pretty clear" for you guys :)
  28. Offline


    CI links are a compromise, one that works best for our members and staff alike.

    If the option was entirely off the table I would have locked this thread the moment it came up. We need to be presented a good reason to change the policy to allow linking to unapproved builds, but as yet have I have only seen reasons to remove CI links as well as keeping our current policy.

    We have provided concessions in the form of allowing continuous integration server links, and allowing a request for a fast approval if a plugin is found to be causing serious problems a newer, unapproved, version resolves.
  29. Offline



    this seems like a rather hardline approach, I can see why you only want to allow CI for linking to unapproved builds and it has yet to be exploited, however, a webpage isn't all that much different and with the disclaimer of leaving DBO the user should take very heavy warning to that

    --- As a dev (inactive)---
    Honestly, as much as it sucks, if your teams whole idea is to make sure that the code that is downloaded is safe, I would be happier seeing no linking to unapproved whatsoever. As it causes issues like this where some people do not have the know how (or the plugin is small enough it is not worth it) will complain. I know for any of my code I have written (public or private) setting up an automated build would be more pain than it would be worth and I would have to respond with "too bad" to server operators when there is a break, it is fixed, but awaiting approval.

    --- As a server operator ---
    Keep in mind that part of this is also servicing server operators (whether a hosting solution or on their own) and making it hard for them to get much needed updates when their is a major player exploitable bug in a plugin wrecks havoc on the server. It is a fine line between fast updates when needed and making sure code that is uploaded (then downloaded by server OPs) is safe to use.

    --- Side note ---
    I must say being here so long, it is nice to see that you allow discussions for these kinds of topics
  30. Offline


    Did you seriously just say we should remove our rule to allow CI links? Can we point all the angry developers in your direction if we do that?

    We have never denied such discussions.
    zack6849 likes this.
Thread Status:
Not open for further replies.

Share This Page