Github downloads

Discussion in 'BukkitDev Information and Feedback' started by rutgerkok, Jul 9, 2013.

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

    rutgerkok

    Hello there! I'm the developer of http://dev.bukkit.org/bukkit-plugins/ender-chest/ and a contributor of http://dev.bukkit.org/bukkit-plugins/terrain-control/. Both plugins need net.minecraft.servercode, so they need to be updated for every Minecraft update. BetterEnderChest can usually be updated in less than a minute, Terrain Control takes a little bit longer, but both can be updated quickly.

    I then upload both files to BukkitDev. Other projects are also updating, resulting in a massive amount of files in the upload queue. This means that it takes about a day before the file is visible, and users can download it.

    Previously, you were allowed to post off-site links. Now you aren't, with the exception of CI servers.

    Recently, Github (re-)added the ability to upload files. They offer a clear interface, no ads are shown, files are linked to a commit, a title and description can be provided. Open source projects can use this to distribute files. Users can easily download the binary or the source.

    I have played around with this a little bit. I have created a release for BetterEnderChest 2.0.7 and 2.0.8. For the first release, I have not uploaded a binary, I just linked to the file on BukkitDev. For the second release, I have uploaded a binary.

    Now my questions:


    If am not allowed to create releases on Github at all, no problem, I'll delete the existing releases and point users to your statement if they are asking why I removed them :) . (I never said there were releases on Github, but an user found it anyway.)

    (Offtopic, but I have a feeling that this is going to be asked: why you don't use a CI server? First of all, I don't have a CI server. Secondly, Terrain Control is difficult to Mavenize (this more or less required for a CI server) because I want the Bukkit and Forge version to end up in one file. Mavenizing a Forge mod is difficult, let alone putting it together in one jar file with the Bukkit version. I'm not experienced enough yet with Maven to do this. One option would be to only Mavenize the Bukkit part, accepting that having one file for everything is not possible anymore. BetterEnderChest is already Mavenized, by the way.)

    Thanks for your time.
     
  2. Offline

    Hoolean Retired Staff

    rutgerkok

    If CI is allowed (linked to repos) then I personally think allowing GitHub projects to be linked too wouldn't be such a bad idea :)
     
  3. Offline

    rutgerkok

  4. Offline

    afistofirony

    rutgerkok The problem is that GitHub's (new?) Releases feature isn't CI. It's manually uploading a file, meaning it is possible that the file is not safe. It does not have to be directly linked to any commit like CI does.

    I still really don't see the problem with waiting for files to be approved (or better yet, just set up a CI server).
     
  5. Offline

    Sushi

    Thanks for clearing this up for me. I'm glad that an automated build server is so much safer than GitHub uploads, especially since it isn't like you could push malicious code to the build server.

    I mean, you couldn't do that. An automated build server is completely safe.
     
    zack6849, cholo71796 and JazzaG like this.
  6. Offline

    afistofirony

    Sushi I agree, CI servers aren't safe. But hey, it's not my policy. :p
     
    HmmmQuestionMark and Sushi like this.
  7. Offline

    rutgerkok

  8. Offline

    TnT Retired Staff

    Only a CI server is allowed, although it looks like our community wants that concession removed.
     
  9. Offline

    rutgerkok

    Ok, then I'll won't put a link up. :)
     
  10. Offline

    TfT_02

    They're not 100% safe, but at least it is safer.
     
  11. Offline

    Sushi

    If someone has intent on releasing malicious code, it isn't safer. It's going to happen anyway.
     
  12. Offline

    zack6849

    I see that it's policy that only CI servers are allowed, but would you mind explaining why exactly github download links aren't allowed? I dont think a CI would be much safer than github in the first place. and as Sushi said, if someone *really* wants to push bad code out to people they will, be it by a ci or a download link
     
    rutgerkok likes this.
  13. Offline

    hawkfalcon

    Can we stop trying to stretch the rules? It's amazing that they even allow ci's in the first place! Lets keep it that way :-(
     
    gomeow likes this.
  14. If developers disagree enough with the policies of BukkitDev, maybe they should not use it anymore.
     
  15. Offline

    Sushi

    Well, there's a feedback forum for a reason...
     
  16. Offline

    rutgerkok

    Previously, it was fully allowed to have offsite links (or at least offsite links were not removed), see my opening post. I think that the Github downloads would offer a nice, clean interface for offsite downloads for open source projects. If I could link to github.com/user/repo/releases, (with a huge warning!) that would be fantastic. If not, also fine, I now have this thread to point them to when they ask why I don't create a Github download.

    That's not the point. I want my users to be able to grab a dev build early, so that they don't have to wait 24 hours before they can update the server. I want to give my users a better, faster experience. It's absolutely not my intention to move away from BukkitDev.
     
  17. I totally agree with being able to use CI and Github downloads, but it's plainly obvious the attitude and opinions of the community managers here won't change.

    Many of these strict rules in the name of 'security' and 'preventing malicious code' (while effective and seeminly justified) are pushing developers away from releasing plugins on their site, or from making them altogether.

    BukkitDev IS their site, and they can run it how they want. The only real solution for those of us who want to allow dev builds (hosted on Github) is to not use BukkitDev-- unless they suddenly decide to stop the trend of lessoning privileges for developers.
     
  18. Offline

    chaseoes Retired Staff

    That's the purpose of a CI.
     
  19. Offline

    Deathmarine Retired Staff

    As much as I appreciate that Github is now allowing uploads again, I can not agree with this. The basis of allowing any type of external download is that the download is controlled per say. There is a certain amount of risk involved with any type of external file, however everyone needs to understand that we check files and do these sort of things for the protection of the end user, not to critique the developer.
    Unfortunately reading these arguments, I see no justification other than statements that it makes it easier for the developer. I find this selfish. Developers uploading plugins are doing so as a service to the users that downloads their file. There is no way to know what is in the file unless its decompiled or distributed uncompiled and built by the user. These users are at the mercy of the developer. So with this in mind to universally allow any type of external resource that is not controlled (Github relies on the file being compiled and uploaded), inherits a huge amount of unacceptable risk in downloading these files. This is the same reason we can not allow Dropbox, Mediafire, or any other distribution platform.

    Edit: If the concept is to get development builds out to your users quicker, then we only allow linking to a CI. Most CI Servers can work with Maven, Ant Builder, I think you can even script a batch to build a file. There are some services that will allow you to have a CI for free if you are open source. I think that taking the extra steps to keep your user safe, is a better the throwing something together quickly and uploading it somewhere.
     
    rutgerkok, drtshock and hawkfalcon like this.
  20. Offline

    TheE

    You pointed out the problem, yourself, didn't you? Any file that has not been reviewed by the team has the risk of malicious code, there is no difference between a file hosted on a CI created by the developer and a file located in the developer's dropbox, on his github etc. From this point it does not make sense to disallow external downloads, if they put up the same disclaimer that is used for CIs.
    Just to be clear, personally I do not really care. After all, bukkitDev is a closed platform without competitors.

    And could you send me a link to a service giving free CIs to open-source projects? I might have some use for that. :)
     
  21. Offline

    Deathmarine Retired Staff

    Actually there is a big difference between a random file uploaded and one that was generated via a CI server. You can see the changes that were made to the file.
    Example: http://ci.modcrafting.com/job/DiabloDrops/3/
    On another note, with that type of logic there is no need for us to host or even check files if a disclaimer is fitting.

    This isn't going to happen. We are trying and working very hard to provide a safe place for developers to upload plugins and allow users to download them.

    We all may not read the nutrition facts on the food we digest however we could if we wanted too and we trust the people that analyzed it and found it fit for consumption.

    http://www.cloudbees.com/ offers free jenkins servers for Free and Open Source Software (FOSS) projects .
     
    rutgerkok and hawkfalcon like this.
  22. Offline

    RingOfStorms

    I completely agree with this. If bukkit is going to allow CI, then they should be allowing any external source with the message disclaimer next to it. Either allow any link, or don't allow a link. CI isn't nay safer than my dropbox, my website, or anything that I put on bukkit dev. My bukkit dev file pages are identical to my dropbox folders. And I even have quick link page on my website for my users to download latest from dropbox.


    "Actually there is a big difference between a random file uploaded and one that was generated via a CI server. You can see the changes that were made to the file."

    Seriously? What's stopping anyone from building the same malicious plugin on a CI as ooppsed to uploading the same thing on dropbox. CI ins't any different from anything else and honestly is no more safe than a directly link to my dropbox folder. They are both external and so they should both be allowed or disallowed.

    Simply put, the disclaimer "These builds have not been approved by the BukkitDev staff. Use them at your own risk." should work for any external link to the plugin.
     
  23. Offline

    Hoolean Retired Staff

    RingOfStorms

    If this were to go through, you could additionally have a:

    You are now leaving BukkitDev
    Be warned! Any files downloaded from external sources may be malicious!​
    (or something similar)​
    As a notice :3​
     
    HmmmQuestionMark and LlmDl like this.
  24. Offline

    RingOfStorms

    That is how it should be. IDC what "notification" they make us put, as long as they make a clear line of, you are allowed or you aren't. And on top of that, the page containing the "rules" is not a concrete rule page. I could technically put a link to anything on my dev page. It just depends on what admin happens to read it, and what mods/standards they are doing things by.
    With that being said, this system is not very concrete and it is designed to favor the biased opinion of anyone with an administrative tag under their name. And because it isn't concrete, confusion can come about when one staff member says something is ok, and then you get warned by another who decides to change the rules on the spot of seeing something.

    So everyone above saying "stop stretching the rules" and "breaking policies" is just eating the feed. There are no concrete "rules" when it comes to linking the external sites. And that's what needs to be changed.
     
  25. Offline

    TnT Retired Staff

    We have been very accommodating to the very large development community we serve. This accommodating nature is why we allow CI links, and only CI links, as it is a way to allow developers to distribute experimental development builds. I, personally, would rather not remove that concession we have made. Its not about safety, it's about managing that grey area that is inherent in all aspects of life. I prefer to leave some of that grey area up to human judgement - which is why that line in our rules: "Please keep in mind these are guidelines. The BukkitDev Staff have the final decision in approving or rejecting your project." exists.

    Not everything is black and white, and forcing us into making our rules so black and white is ridiculous. Life does not work that way.

    Again, let me reiterate - the allowance of CI links is a concession we have made that can be revoked at anytime if it becomes troublesome. Until that happens, we will not go and further rehash this discussion - the OP's question has been answered. Locked.
     
    rutgerkok, hatstand, gomeow and 2 others like this.
Thread Status:
Not open for further replies.

Share This Page