They result in a fixed length, turning that hash into a string, and then compressing that string with something for example Snappy would prove useful. For example:
Take this MD5 (from a bukkit poison plugin, when I started working on a project to detect poison plugins): “b38248b80b6b157470bdf7fc994141ba” We take that Hash as a string, and run it through for example Snappy (One of my favorite compression methods). Which would output “[B@78308db1” (Note there may be a weird string to the byte[] to string.)
Therefore this is technically compressed more. I wouldn’t suggest doing it, it was more just a rebuttal to the guy who was worried about size of the hashes. This showing it wouldn’t really take that much time (snappy compression took around 3 Milliseconds from Snappy snappy = new Snappy() to System.out.println(snappy.compress(args[0]); Just an example nothing more.
I am honestly going to go with a mix of the first and second proposals. Here’s how the process will go:
A plugin developer uploads a file.
A moderator/reviewer receives a notification of a new plugin.
The moderator/reviewer checks the plugin. If it is marked as good, something near the download link will be a “Moderator Verified” sign, if not, it will be immediately deleted.
Any member with i.e. 25+ positive reputation and 500+ posts can write a review of the plugin and have the option to choose “Good” or “Malicious/Bad”. If there is at least i.e. 5 reviews (disregarding if they are positive or negative) there will be a “Community Verified” sign and “Click here to check reviews” button. You can also hover over the Community Verified sign and a small bubble will appear right beneath it, telling you how many positive and negative reviews are there.
If a plugin exceeds i.e. 25 negative reviews a notification is sent to a moderator and he reviews it very carefully this time, and decide whether to delete it or keep it (and remove the invalid negative reviews).
I also have another idea that would be an integration between Sponge and the Plugin Hosting portal. Whenever a moderator checks a file, he assigns the plugin and ID by using a small piece of code. If a person downloads a plugin, Sponge will take the ID of each plugin and put it in a read-only API in the Plugin Hosting portal and it will return if the ID is deleted, or still available for download (since that resembles if a plugin is malicious/bad). If the ID is deleted, Sponge will delete the plugin and will never run it. But if it was available, it will run the plugin.
I know that this may affect the start up time, but it’s worth it to make everyone safe.
Too long discussion to go through, so I have a simple question/suggestion: would earlier Bukkit “reputation” mean anything? Meaning, for us who have developed Bukkit plugins which have been hosted on BukkitDev for months, even years, could the process of getting the Sponge-ported versions in SpongeDev (or whatever) be a little smoother than for new developers?
I’m asking this because I really think it is crucial to get as many of those Big Bukkit Plugins into Sponge as soon as possible, for Sponge to gain momentum as The Minecraft Server Platform.
I like this idea, and I agree with your reasoning…in order for Sponge to be successful you want to get those big Bukkit plugin ported to sponge, that way the change to Sponge for server admins is easy.
However, the problem I see with this is that, there’s nothing stopping a “trusted” Bukkit plugin developer from uploading a malicious plugin. I think there either needs to be a high standard of what constitutes a “trusted Bukkit plugin developer” or that Bukkit ports just get a high priority in the queuing.
Also, can someone explain to me the difference between the first and third proposal? It just seems like the third proposal is a way to do the autonomous part of the first one.
Yes, you’re right - a higher priority in the queue for Bukkit ports would solve this, while still maintaining the standard for checking for malicious code. I expect the plugin queue to be pretty awful soon after the first Sponge release comes out, so this prioritising would help.
I personally don’t think that that is quite fair. It makes it really hard for plugin developers that haven’t developed for bukkit to create a plugin and have it out as soon as possible. Sponge is a different community to sponge and I don’t see why known bukkit community members should have special treatment. Or do you carry your post count with you everytime you register for a new forum?
The idea is to give popular Bukkit plugin developers a higher priority when submitting ported plugins. We want the switch for server admin to be as smooth as possible. If they can’t find WorldBorder because it’s stuck under 50 other plugins, then they might not switch.
We would give review priority to ported Bukkit Plugins by Bukkit plugin developers, not to just any plugin they make.
I know. I just don’t like the idea of someplugin developers having priority (or even quite a lot) and lengthening the wait for everybody else. Thats what bothers me. Also, wether people switch or not shouldn’t depend on how fast a working server with as many plugins as possible can be created, but on the quality of the project.
Well, regarding that, someone should make a poll on that before the Plugin Hosting website is released to the public. That would be a great idea to get the community’s response.
Having priority based on popularity is problematic: it makes it easier for devs to upload new versions of popular plugins while making it more difficult for devs to upload new plugins, limiting competition.
I am in favor of 3. Option 2 will allow too much malicious software through. Option 1, however, will lead to long wait times, plus I feel it gives the review team a little too much power over the devs. Both of these were problems I noticed with BukkitDev. I am a former Bukkit plugin developer, and it got to the point where I could easily have to wait a week for my files to get approved, and many of my files got rejected erroneously or for nit picky reasons, such as not liking the way I structured my .jar files.
Option 3, I feel, is a good compromise. It keeps administrators reasonably safe from malicious plugins while still allowing for an open, community driven plugin repository.
Edit: Is there any chance we can create a poll for this?
I feel that 1 is best, but I can see practical reasons why 3 might be an acceptable option.
I do feel that a plugin author should submit source only, and building a jar is handled by a trusted party (eg: Sponge staff). After being audited, the known-good jar is posted with a SHA sum and source to the repository.
If an author doesn’t wish others to make derivative works or redistribute: they can license it in such a way as to not permit that. Open Source != Free Software. I know you can audit by decompiling, however it makes less work for the reviewer and lowers the threshold for the community to audit the code. By handling the building in-house you can be assured that the jar corresponds to the code. Also by having the code there, the end user can build it themselves for the greatest assurance.
I do not feel it is fair to put the Sponge staff/volunteers in a position where they have to vouch for the safety of a binary.
I am definitely against sending source and having them compile it. It would require immense capacities to be able to (anfd thats what that basically is) have a ci for plugins. Also, I believe that building a program is something it’s author should be able to do himself. A lot of plugins have dependencies. And we don’t all use fancy buildscripts. Also, that forces people into having to use certain technologies to publish their plugin (If everybody just use their preferred system, we’d end up in a right mess.) Also, how would authors submit the source? inb4 zipbomb? xD And back to builds, if they build it themselves, they’d also have to check buildscripts. What if the plugin includes (possibly malicious) code from some separate repo at compile-time? That would require the staff to know all the build automation technologies out there… Gradle, Maven, Ant just to name a few. (Hell, you could even write a buildscript in Python.) Forcing people to open up the source to their plugins publicly will drive a lot away.
They still would for plugins that aren’t distributed through Sponge.
And, incidentally, we have quite sophisticated tools for dealing with them.
Why not?
That would be the case in order to have a centralized repository anyway.
Git?
Build it in an isolated virtual machine that is destroyed after each build. Travis has already effectively solved this problem. Besides, build scripts are usually trivial compared to whatever is being built.
Well, either the staff would standardize on one tool, plugin authors would be able to specify the tool used programmatically (once again, see how Travis does this), or gasp, someone would need to check whether to run ant, gradle build, mvn package, or sbt package.
Boohoo, malware authors wouldn’t be able to keep their code ‘secret’. The only other potential use case (commercial plugins) has already been banned from everything officially Sponge-related anyway.
So you are publicly going to distribute compiled versions of somebodys probably copyrighted work possibly violating their copyright. Amazing.
Congratulations, you might as well tell the authors to just distribute anywhere else, just not on Sponge. Where is the logic in that?
Because a lot of people don’t know how to use them.
Am I misunderstanding something or do you want to force devs to host their code on Sponge?
And what if I preferred to use svn or mercurial?
You didn’t get my point. You can change the code to be compiled before compiling it by including / excluding files (also from external repos)
Well, let me tell you something: People might want to keep their code closed source even if they aren’t hiding malware or selling it, and nobody but them has the right to decide what they do with their code.
Huh? Of course you’d write this into the ToS of your hosting service.
You said “should be able to do”. You’re perfectly able to build it locally, and you’d need to for development. This doesn’t inhibit you from doing anything, it would just do it for you when releasing.
Then perhaps they should put in the 5 minutes required to learn. Honestly, I’m not sure I’d want to use a plugin made by someone who is unable to copy/paste the equivalent of
Sorry for being unclear, I meant a build artifact repository (plugin listing). That said, yes, I do want there to at least be some way to link back to an exact source commit from each hosted build.
For hg hg-git gets you some of the way there. SVN simply doesn’t support the features required to accomplish what I listed above in a secure way.
Sure, they have a right to keep their source private, but that doesn’t mean they have an automatic right to have it hosted. Besides, nobody would lose anything from the source code being available if it’s freeware regardless.
They submitted the plugin for distribution: permission is implied, and probably explicit under the terms the repository will accept submissions. If they didn’t want distribution, then why submit it?
They always have the option to distribute a jar themselves, however Sponge doesn’t have to vouch for them being trustworthy, nor is responsible for an independent party’s actions or product. If a plugin author wants the exposure and to have a trusted party’s “seal of approval” then they can weigh that against the terms to receive that.
They should learn to use those tools. More to the point, if they are writing something and not taking the time to get it right (code that only builds on one machine is poorly written), should they really be releasing this to the public? Setting the bar higher ensures that better coding practices are followed.
I believe he means the compiled jar, to be hosted by Sponge. However, having a snapshot that the jar is based off of would be ideal as well.
It would be trivial to handle other code versioning systems or even common archive formats. It is easy to protect oneself from a zipbomb.
Review the source, if it looks good, build. As part of reviewing the source you would check what else it pulls in. If there is something questionable, sure you can decompile the jar and check to make sure nothing hinky is going on.
They have every right to, however they do not have an intrinsic right to have Sponge vouch for it’s safety and to host it in an official repository.