As said, I figured you’d have sponge host a certificate authority, and a developer sends a CSR. Sponge’s server responds with a signed certificate saying it’s developer X or Y. If someone wanted to make a false plugin under your name for example, they’d have to release it as YourAwesomeMod, either unsigned, or as sk88q or something. If it’s under the wrong name, the plugin itself can check it, or the sponge server can even host a sort of database saying “this mod is made by sk89q, and all mods by sk89q are signed” so sponge can know to reject (or at most show a warning saying it might be a malicious plugin) an unsigned plugin supposedly made my sk89q. The plugin itself could also try and check for this, though it’d be much easier to remove.
Yeah but internally they can just rename it “sk89qofficial” or something and the user would be none the wiser.
But the fingerprint would change, sponge could detect that. Kind of like webbrowsers or ssh do, notify the user if there is a suspicious change or something looks fishy.
It has to check the fingerprint against something.
If we’re using author name as that something, then yes, it would recognize when Bob released something under my name. However, it would not be able to recognize that “sk89qofficial” is actually trying to impersonate “sk89q.” To it, it’s the same difference between sk89q and Bob.
your name has to be in the certificate, which is signed by the sponge CA. You cannot change that name without invalidating sponges signature.
My point is that “sk89qofficial” is not my name.
“sk89q,” in this theoretical scenario, is my name.
Someone else cannot release under sk89q, but they can release under sk89qofficial.
Most users, if they saw that the WorldEdit that they just downloaded is now by sk89qofficial rather than sk89q, would not even bat an eye.
Maybe not users as in clients, but as a server admin I care (not all do). Any decent updater plugin should care.
I realize that most clients would just click it away like SSL warnings, but it would at least provide a tool to prevent it. Nobody forces you to not connect to an ssh server if the server fingerprint changed, nevertheless it gives you a hint that you might need to look closer.
In my opinion it would help to limit the abuse and increase the security. Even providing only an API to fetch the signatures of plugins that have been checked would be nice. But the plugin checking needs to be in the core before the plugin loading for this to make any sense.
Once it gets to that point only the dumbest of the dumb users would use it though. Sponge can’t hold everyone’s hand to that point, unless it has a big “Hey make sure it’s the right thing and you got it from (sponge’s dev site) and it’s not a fake plugin!” warning, which will also be ignored.
Yeah but with an SSH server, you have to accept a key. Having to accept a key is the norm. If we’re talking the case where mods do not have to be signed, most would not be signed so not being offered a key prompt would be the norm.
Well, utilizing signed binaries is to protect people who don’t know better, isn’t it? If it doesn’t prevent them from ultimately installing a malicious binary, signing isn’t really doing its job then.
edit: Not to mention, if this information is only appearing in a log, then very few people would even notice. Even if we were to throw up a GUI prompt (in a theoretical situation), it would not matter because there would be no signature violation caused by the rename.
To be honest I think it should be mandatory although you can ignore this it will give a warning message of some form.
In a use case where an entity like BukkitDev exsists, they could enforce their devs to sign the plugins or sign them themselfes if they provide it as a download. I’d guess that nearly all admins go to BukkitDev for Bukkit plugins. There will always be some plugins which have fishy signatures, but at least one could proof that the binary was or was not approved by BukkitDev since they are lacking BukkitDev’s signature. Sponge could refuse to load a plugin that looks fishy i.e. fingerprint changed and force the admin to start sponge with a specific start parameter like --remove-fingerprint WorldEdit or a command like /pm remove-fingerprint WorldEdit (Note: This only works on servers, not considering clients for now).
Another use case is the corruption of plugins, as you may have seen in my PoC it is very easy to infect other plugins. This would not be possible with signed plugins, even if they are self signed.
If you are hesistant because you don’t wan’t something more to work on, I am willing to implement such a system.The only reasons I see not to support code-signing is the additional lines of code that need to be maintained. As I see it we are here mostly discussing the policy sponge should have, or is there some strong argument not to have the tools ready?
Your POC for infecting jar files is a terrible way to go, from the quick glance it seems like you’re essentially just replacing the target plugin class, and writing your own into the jar.
Instead you would simply bytecode edit the onEnable method in the main plugin class (or gen one if it isnt there) and allow it to run your code (however you want, streamed, written in, externally, etc.) whilst still allowing the original plugin to function properly
I know, but it’s enough to prove my point 
(and I already had it ready)