#Plugin Signing

1 messages · Page 1 of 1 (latest)

winged obsidian
#

A safety feature where players can see if a plugin is officially compiled by Pumpkin devs from source code using a signature system. This could be good for non-open-source plugins that are fine with sharing their code to the Pumpkin devs to prove it's safe.

dusky garden
#

You can always just use sha256 and publish checksums

winged obsidian
#

yeah but I meant like a system where pumpkin devs and trusted contributors can verify plugin hashes as safe in cases where they're closed source

#

so like, if a closed source plugin wants to be verified, they can submit the source code to the pumpkin staff, and have a vote were 3 ppl need to agree that the hash should be added to a list of verified plugins. and if vulnerabilities are discovered (like dependencies, or unintentional backdoors), server owners can be notified.

#

this can be done by a 3rd party plugin, but you get the point

knotty pawn
#

Also, signing plugins means once a plugin is downloaded from a trusted source, updates cannot be taken from malicious mirrors or modified copies (which could happen if, for example, the repository storing the plugin gets hacked)

winged obsidian
#

a huge inconvenience is trying to push out updates as a verified plugin developer. you'd either have to sacrifice security by allowing updates to be verified without being checked, or have all future versions of the plugin be unverified by default until reviewed again, by checking every update for malicious code(which would take a lot of time). Unless there's some automatic scanning/flagging system to make it quicker to verify

#

it wont stop users from downloading malicious plugins, but it will let them know if it's verified as safe. Kinda like how the Windows Smart Screen lets a user know that the executable file has not been verified by Microsoft

knotty pawn
#

Actually, absolutely no check is done for Smart Screen...

knotty pawn
#

I guess, that plugin developers could sign their plugins using a key they have (on per developer), so users will get updates only from the same developer (so repository hack won't have any impact), then Pumpkin could either enroll the hash of a verified plugin or a key that the developer has if it is trusted, or re-distribute the plugin with an additional signature, claiming that the plugin was check by the Pumpkin MC team

#

Either way, signing to allow Pumpkin to verify plugins is nice, but it should also be possible to developers to sign their plugins, ensuring that the users won't suffer from a hack somewhere between them and the developer

foggy viper
#

this just seems like a dumb idea. I personally dont like signing, as it slows the rate that you can publish updates. I think if a user downloads a plugin, it should be at their own risk. I think if you want to verify that a plugin is an official build, there should be some hosted hub for this, much like papermc's hanger. and if you are very paranoid about malware, the hosted hub could have a sandbox, for piece of mind. the hub, should pull the files from the github or gitlab releases of the plugin. this method gives PumpkinMC control over the plugins that get published, and downloaded. With the hub implementation, it could hash the files, and if a plugin is truly malicious, the pumpkinmc instance can pull the list of malicious hashes, and if there is a plugin that matches the hash it will disable and alert the operator. and pumpkinmc can label some plugins as trusted, and add them to a list. I just don't think that signing is the best way to go about this, as I think it will just cause inconveniences.

knotty pawn
#

It does slow down the update rate, if the plugin is also signed by the Pumpkin MC team. If the plugin is signed by the dev itself, I don't see what the problem is

#

Also, having a huh means it could get hacked

#

Even GitHub/GitLab, who knows?

#

And signing shouldn't be mandatory

#

I find the idea of a malicious plugin hash list pretty good

candid vault
broken hearth
#

This inevitably brings up another issue, which is the malicious violation by plugin authors, embedding backdoors within the plugins. Don't think that the probability of this happening is very low.

#

I think there should be a rating system established, with ratings for multiple aspects such as security and practicality.

candid vault
#

why would it happen in pumpkin, and not in spigot ? Jvm ?

flat bobcat
#

However I think the checksums should be up to the plugin authors themselves. Or just have a trusted way of distributing plugins, like a plugin marketplace

dusky garden
# flat bobcat I think this would be a good first solution, after that sandboxing plugins seems...

Well the thing that we've run into multiple times already is that there isn't any great way to sandbox DLLs. Theoretically there are projects like https://github.com/PLSysSec/rlbox or https://github.com/servo/gaol (which has been dead for half a year now), but neither of them seem super capable or reliable. Honestly I think a rating system and dangerous hash list are our best chances. The signing could also be beneficial (anyone could sign their plugin, and the ranking feature could theoretically be tied to the signature; this would also mean that plugins could be verified by the pumpkinmc team, and then signed by a special key that would be a kind of guarantee that the plugin is safe)

GitHub
GitHub - PLSysSec/rlbox: RLBox sandboxing framework

RLBox sandboxing framework. Contribute to PLSysSec/rlbox development by creating an account on GitHub.

GitHub
GitHub - servo/gaol: Cross-platform application sandboxing for Rust

Cross-platform application sandboxing for Rust. Contribute to servo/gaol development by creating an account on GitHub.

flat bobcat
#

Yeah, I agree. Would definitely make the most sense at this time.

dusky garden
#

When I get home tomorrow (in about 12 hours), I'll write up a proposition for a signing/hash verification system for plugins. Everything will be configurable and possible to disable in the configs, but it's main purpose will be to help protect the admin from known threats, so I don't really see any reason to disable it. The base of my proposal will be: on startup check plugin hash against known problematic hashes -> if found, prevent load (of plugin); check signature -> if none warn admin, if signature associated with bad hashes prevent plugin load, otherwise just load as normal. I'd like the hash and signature databases to work similarly to repos in package managers (so you can supply your own, disable others, etc.), and also make all the behavior configurable as well (whether to warn, prevent load, or shutdown server completely)

winged obsidian
# foggy viper this just seems like a dumb idea. I personally dont like signing, as it slows th...

It doesn't slow the plugin development down at all, and users can still run unsinged plugins. The idea of signing is having a public list of plugins that are verified to be safe, kinda like a verification on a social media platform. It could be useful for things like proprietary plugins, or enhancing the trust between developers and users, without adding any unnecessary friction. It would also allow for other stuff like voulnerability warnings. A good example is what happened with Vulcan AC, there was an arbitrary console command exploit, and many server's were griefed because they didn't know about the exploit. This could be done by a third party, but it's just a suggestion.

winged obsidian
# knotty pawn And signing shouldn't be mandatory

I never proposed mandatory signing. Its like a social media checkmark, it doesn't affect the plugin at all. It just shows that the code was verified by trusted members/third party. Having a hash list could allow for verifying, voulnerability warnings, and malicious plugin alerts

winged obsidian
#

and have some rules for verified plugins. For example, disallowing auto-updates.

#

auto updated plugins won't immediately be marked as malicious, but it will just be ineligible for verification

dusky garden
winged obsidian
#

ig, though we wouldn't really know about certain features if they aren't disclosed, so maybe have a little survey in the submitting request?

knotty pawn
#

Like, signing is useful for devs to make sure users won't get updates from potentially malicious sources, and useful to Pumpkin so that they can say that a specific plugins has been reviewed and should contains no malware

candid vault
#

Just Download it from thé same source

#

Like

#

Same github repo

knotty pawn
#

It can get hacked

candid vault
#

Wow

#

If you’re that concerned about that

knotty pawn
#

I am lmao

candid vault
#

Développ everything on your oN

#

Own

knotty pawn
#

Well
I'm unfortunately not skilled enough

#

But more seriously someone could get access to the dev account

#

And publish updates

candid vault
#

That’s why you never make the update first

#

That’s why people join the dev’s discord server

knotty pawn
#

I don't think small admins will take time to do so

#

Plus some can download the bad updates before someone notices they are bad

#

Like it happened to Curseforge and Bukkit

winged obsidian
#

As I said, it's similar to how social media verfication is. It ultimately means nothing, but it just says that the account is who they say they are(well, that's how social media verification used to be)

#

now it's just subscription based

candid vault
#

sorry i was kind of drunk earlier...

#

I'm not really against it, if it's not mandatory.

foggy viper
#

I think universally, there should be a hash list of malicious plugins. But I still think that certification is not necessary. I think a central registry of plugins, which developers can push to is better. A developer can push a plugin, then that plugin runs in an sandbox, if no issue are present, the plugin can then be pushed where it can be seen publicly. If you are afraid of someone compromising a developer account, this would actively work mitigate the effects of that as malicious pushes would be blocked.

foggy viper
dusky garden
knotty pawn
#

But it is still worth considering

knotty pawn
foggy viper