I really liked the almost guaranteed security full source scanning provided at Bukkit, but it seemed like more trouble than it’s worth to fully scan the jar every time.
I think a better solution would be to have people upload/commit their source to a private repository that only Sponge plugin reviewers could view. Then reviewers will only have to review differentials and trace as far back into the code as needed. If plugins haven’t been fully scanned in x amount of time, they can be flagged for full review on next update so that reviewer errors don’t persist.
It has already been done successfully by F-Droid. Yes, it would take some effort to get right, but it’s not impossible. Actually, here’s a workflow that ought to be able to work:
Add a script to .travis.yml that prints out the SHA-256 of the artifact jar
Add a deployment script to the .travis.yml that uploads to a Sponge-controlled server, also giving the contents of $TRAVIS_BUILD_ID
Sponge server verifies that the uploaded file corresponds to the previously printed checksum, and that the .travis.yml contains a correct version of the script that should print out the checksum
I don’t like the idea of one good plugin and you get ability for automatic upload no approval. However, I think if they have maybe atleast 5 plugins and/or are a certain rank on the forum(this could be a plus) they automatically get it as they are trusted, but still I think every plugin no matter if they are made by the owner of this forums should run through a basic scan for exploits or backdoors because some people might even put them in accidentally(i.e if mysql is implemented and only if mysql is added to the filter) and they dont realize it, the system can pick it up.
Another thing is, how do you filter multiple languages? You couldn’t only do Java as some use MySQL and possibly other languages. So how do we approach this, find professionals in those fields to point out common exploits/backdoor methods? just curious.
I think requiring all projects to be open source(publicly or privately but visible to moderators) so that people can check the code more conveniently would be better and quicker since they can check code changes easily
That makes absolutely no difference. People could have a backdoor in the jar that’s not in the source. Reading decompiled code isn’t bad.
Plugins would be done in Java. Java has a MySQL library. If there are things like plugin loaders for different languages (BukkitDev had a few of those), we’d just have someone with knowledge of that language review that code in your example.
@drtshock Whoa there, calm down chief. I have no clue who you are or what your relation to BukkitDev was. Not only that, I wasn’t calling you nor anyone else incompetent. I know of several plugins that have been disabled on DBO because someone thought some line was malicious when in fact it was just a hack to make use of NBT or something similar. I was part of the BukkitDev staff for a good deal of time in the beginning of it. I am well aware of the overload that many were under, especially if they were also plugin devs themselves. God forbid you had other commitments and responsibilities aside from that. But I’m not going to go into all of that because it is a waste of time and I wouldn’t want to hurt your feelings anymore than they obviously already are.
As for your suggestions, thanks and let me address them. The first one: Every developer knows that not all bugs can be caught in testing or QA. Things slip through, users find creative and unique ways to make a pigs breakfast out of even the most elegant code. Things go bad and sometimes you need to get a bug fix out. Sometimes that bug fix needs to get out immediately. As for the second one, that is just being condescending like you are alluding to me being and irrelevant. I personally use a CI service. I even use a web server for storing long term release builds. Not everyone is lucky enough to be able to afford those though, or know enough about server administration to put one up if they can.
Sounds like someone needs a hug and possibly a nap. My apologies if somehow I offended you by stating what seemed like a fairly benign personal opinion on the topic at hand.
After reading through the comments, I think I’ve put together a full system.
The system relies on the “Community Approved” status @GameplayJDK suggested, as well as the system @Marenwynn suggested.
No matter what, I think the community should be allowed to review and flag plugins. Publicly show how many community members have reviewed the plugin, so the user downloading it can judge the trust of the plugin. Plugins would still be required to be manually reviewed by Sponge staff, but in a way which minimizes the amount of work that has to be done.
Just to increase the security of the system, @kukelekuuk00 suggestion of random spot checks isn’t horrible either.
All together, I think this provides a system which would keep a high level of security, while also allowing minimal work for the Sponge staff. Also allowing the end user to decide if a plugin is trusted enough puts some of the security burden on the user.
Although the first option is exhaustive to those having to review everything, I feel it would be the safest option. In my opinion I feel a strong combination of the first two options would be the best choice.
I personally agree with @Cyclometh’s system, a “Proposal 4” if you will, as it allows for individuals to decide what level of risk they are happy with and operate as such. Given that the BukGet people appear to be working on an apt-get style system, I believe it would be wise to adopt a source classification system, this would also likely have the best trade-off between speed and safety .
Just modifying it slightly to allow for better classification, from most to least trusted: Official: Plugins that have been classified as safe by Sponge Staff. Trusted: Plugins written by developers that are trusted by the Sponge Staff, but have not been reviewed yet. (Would allow for faster release times for well-known developers.) Unofficial: Plugins that have been reviewed by the community and believed to be safe, yet not reviewed by staff. Unknown: Plugins that have not been reviewed by anyone.
As a server owner and would be Sponge plugin repo user I like option 3 with @Ivan idea of a Verified symbol to make it clear that a file has been reviewed
What I think many developers would like to see is something that moves every plugin accepted into a maven repo. It’s quite a hassle when plugins aren’t in any public repos, and having to locally install the plugin through command line.
Moving on… Option 1 to me seems the most secure. You never know when a developer may want to put in a backdoor and whatnot.
Proposal 3 is better. Also we can ask authors for src, checking it, compiling files and taking md5. When they upload the jar file, a program should check our Checksum with authors Checksum. If the check fail, downloading will be removed and BackDoor team will be announced to check the file.
Plugins would be done in Java. Java has a MySQL library. If there are things like plugin loaders for different languages (BukkitDev had a few of those), we’d just have someone with knowledge of that language review that code in your example.