Cheaters will be able to decompile it anyway. Zekuritee by obscurity is not a valid tactic.
Proposal: 2 Is Good, On this site we have levels of trust right, if we upload plugins, people might see our level and trust us more, it is different from bukkit, and since it will be like this, many people will know and not download right away, there could even be a few people that will decompile the plugins and have some special rank by the amount of people that they helped, and those wondering if the plugin is safe they can call them, or we could also provide source code so when people download it they can see and then comment below if it is safe or not then others would download
1 Like
Nice idea! I support this.
Read through about 3/4 so sorry if this is a dupe but what about Certified Developer mark? Developers like TnT, MD5, McMMO dev’s and other large plugin providers can get this mark so there downloads are auto approved with a simple scan. They have proven themselves worthy to be certified developers that can then review others projects and or flag ones as good. Just trying to think of a way to share the load instead of only having a select few volunteers always processing reviews. I for one would work hard to get this so i can help out the community. I have worked with a lot of other developers on bukkit plugins but never stamped my name on any until recently. If this is how bukkit was run before i would have assisted where i could when i have time. Since we all know doing the same thing always gets boring. Side tracking and testing a build would break up the mundane of always coding or always working on the same task. This is a community so we should keep the community aspect alive. We are all here to have fun. 
2 Likes
We’d have to host all the CIs or it’d be too easy to beat that system. You can also just fool git into putting something into an old commit.
This has a similar problem to proposal #3 (and #2): there is still the risk that a developer who has gained this ‘certified mark’ can upload a malicious file that automatically bypasses the review system. It’s unlikely, yes, but there’s still that possibility.
It really depends on the balance between level of security and review speed that the plugin repository should exhibit as to whether something like this can be implemented.
No, you can’t. One of the core reasons for git in the first place is that everything is checksummed. If one was to “change” a commit, its checksum would change and the reference would either keep pointing to the old one or stop working completely.
I like this idea, would allow people to release quickly the plugin if it is a person request, then dev/mod can give it a green flag, CV could have a % of community happy 100 % be community think it’s ok, and 5 % would be community think it need an urgent review/pullout from the dev
Then like a status:
NR [Not reviewd] but download able
CV [Communits Viewd] that the Community viewed the file ant thinks it’s ok
SV [Staff viewed] that the Staff viewed the file and it’s almost to 100% safe
Here is my take on the plugin approval situation. Most people decided to download the plugins from bukkit through the backdoor if it’s unapproved anyways, so here’s what I’d like to see implemented.
I personally like the idea of the community vouching for plugins. For a new plugin there could be a Reputation system setup. It starts at zero and for every user that deems it safe can “+1 Rep” But we could link their SP.org account to a server IP as well in a database to prevent fraudulent reps. Now when the author uploads a new file, the Reps would change font color, for instance from a positive green rep to a purple/blue rep, to indicate a previous Good Rep but also indicates a new file.
From then on a staff member could officially add a “Verified” string to the plugin context.
A second support method is to add a permission request event to the API. I have written a mock-up of an example.
package org.spongepowered;
public class plugin {
Reference reference;
/**
* Contains the event types to be referenced for executing of a event.
*/
public enum Reference {
PLAYERSPAWN, PLAYERJOIN, SERVERSTART, DATABASETRANSACTION,
SERVERCONFIG, PLAYERCHAT
}
/**
* Returns a message to the server requesting to get authorization
* to execute a plugin's event based upon {@link reason}.
*
* @param Reference the type of event being requested
* @param reason the reason the event is being requested
*/
public void requestPermission(Reference $reference, String $reason)
{
/* ADD EVENT TO A LIST AND PRESENT LIST TO CONSOLE REQUESTING AUTHORIZATION. IF RESPONSE IS YES THEN LOAD PLUGIN.
*/
}
}
Then on the plugin’s onEnable()
import org.spongepowered.plugin;
import org.spongepowered.plugin.Reference;
public void onEnable()
{
plugin.requestPermission(Reference.PLAYERJOIN, "Teleport player on firstJoin()");
plugin.requestPermission(Reference.PLAYERCHAT, "Monitor chat for disapproved words");
}
Something like this would be output on the console
Plugin RegionTP is requesting access to the following events
Event Reason
PLAYERJOIN Teleport Player on firstJoin()
PLAYERCHAT Monitor chat for disapproved words
Type 'plugin RegionTP allow/disallow'
Something like this is what I’d love to see.
Doesn’t Android do something similar where you have to request access to features that you want to access within your app in a separate file or something similar?
That’s where I got this from, but I tried to show a little more ‘push’ by giving some example code.
I’m in favor of the 3rd option, although it may be worth rigging up some system of auto-flagging files that are uploaded shortly after validation.
That’s a cool idea.
I think that the 3rd option would be the best… First check if a developer isn’t going to backdoor. If not, make them able to release plugins instant!
Another possibility is to enforce plugin signing via a correct certificate I know it won’t stop it happening but it should be easier to control enforce and reduce chances also you could have the plugin show a list of events or etc much like Android/etc
Honestly I don’t feel this is really feasible on multiple levels. On the one hand that makes it so that you guys are forcing open source regardless of whether the developer wants it that way or not. That isn’t really you guys place to decide how a developer licenses their code or releases it.
The second way is the sheer bandwidth involved in something like this. Unless you guys are going to approach someone like Curse to get some sort of tool setup for this (which is another consideration, the amount of time/code required to set this up) the bandwidth requirements just aren’t a reality for you guys to self host outside of on a large scale networks system.
1 Like
No, but it is their place to decide how code released on their hosting platform is licensed.
+1 for not reading the entire thing and taking it entirely out of context.
If they forced an open source or specific license for any plugins hosted on their system then they are taking away the freedom of the developers to program how they feel best. They might as well force all plugins to conform to specific style and naming practices while they are at it also.
1 Like
The time to code this wouldn’t be much longer than it would the way bukkit had this. I could even do this in my spare time in one day.
It is their right though. Sponge can determine what gets posted to their directory. It’s their resources and if an invalid license is uploaded they can sue or take proper actions for damages.