Plugin Source Files, Optional or Remote/Dynamic?

[d14na]

Is your feature request related to a problem? Please describe. Currently, plugin source code must be "included" files for the PluginManager to properly handle the copy to /data/__plugins__.

Describe the solution you'd like For the purposes of creating a "Plugin Store", this will quickly become problamatic, as the number of listed plugins increases. (ie. the total site size will quickly exceed 10MB)

Describe alternatives you've considered As I understand it, "optional" files must be "clicked" on to trigger the local download. Would it be possible for the user to "click" a FOLDER (eg. /plugins/PeerMessage) that would trigger a download of ALL files contained within?

Another option would be to pull the plugin's source dynamically (at the time of installation) from a remote source; the most obvious to me would be IPFS (as its immutable), but perhaps BigFiles would work here too (not familiar).

Additional context The goal is to keep the collection of plugins (held by a single site) under 10MB OR dynamically available for installation by the user. Any and all suggestions are welcome.

Cheers! d14na

[HelloZeroNet]

There is a fileNeed API command that you can use to trigger download of optional files.

But I think it's better solution if the plugin store site just links to the plugin developer site that the user can use to install the plugin.

[purplesyringa]

-1 for plugin store idea, at least on the current state of ZeroNet features. Leaked privatekey can result in a diseaster if the plugin store becomes popular. A single plugin per site architecture will most likely work better.

[d14na]

There is a fileNeed API command

ok great! i'll try that out, it might be slow for the user after request, but as long as it works, i'll take that

But I think it's better solution if the plugin store site just links to the plugin developer site

will absolutely have links to: homepage, github, chats, etc. but also, there will be code samples, docs, faqs, etc, that will be CONSISTENT across all plugins. this adds convenience for the dev, and that's usually a very good thing

Leaked privatekey can result in a diseaster if the plugin store becomes popular.

agree 100%, but not just for the store, but for any popular plugin too. as noted during the install, Warning! Plugins has the same permissions as the ZeroNet client.

although NOT in use yet, the plan is to move to HSMs; you know, bank-level security (will have to give up the vanities though)

A single plugin per site architecture will most likely work better.

why?

---

imo, the # 1 reason for having a single repo is TRUST & SECURITY, ideally from a peer-reviewed ratings system, that's the goal. thanks so much for the help and great feedback

[filips123]

For plugin store it is better to use merged sites. Main site should be for UI, but each plugin should be separated merged site (like repositories in Git Center).

@imachug Isn't this something that @krixano will do in new KxoNetwork version?

[purplesyringa]

Isn't this something that @krixano will do in new KxoNetwork version?

We're discussing implementation details now.

[krixano]

I haven't decided on anything concrete yet. All feedback about the security of installing plugins and how to verify plugin tustworthiness would be appreciated (although, is there a better issue to discuss this in?).

One idea... the optional ability for plugins to include a signature by an id so that we can at least link up a plugin with the person/id who created it. If someone trusts this id, they then can trust the plugin. Me and ivanq talked about this idea a bit previously. (@HelloZeroNet)

[d14na]

For plugin store it is better to use merged sites. Main site should be for UI

i've just started working with "merged" sites using the PeerMessage plugin, but otherwise not much experience.

but each plugin should be separated merged site (like repositories in Git Center).

how does Git Center (in the context of merged sites) work anyway? anyone care to ELI5?

the optional ability for plugins to include a signature

another thought i had would be to verify the hash of the entire plugin folder against, say:

1. a github commits metadata (idk)
2. or ipfs hash (that would support remote download)

---

As mentioned before, SECURITY & TRUST are the main objectives in creating this store. I wouldn't even try PeerMessage until I read every line of code. Plugins have FULL ACCESS to the UiServer, which is super convenient, but pretty INSANE! Is this NOT the case?

At the very least, users should be clearly told what the CURRENT VERSION of the plugin has the capability to do. Best reference I can use would be something similar to the Android Permissions system. That would obviously take time to implement in the core codebase, but it could much more easily be presented at the time of installation. BUT IT HAS TO BE TRUSTED.

[krixano]

Best reference I can use would be something similar to the Android Permissions system. That would obviously take time to implement in the core codebase, but it could much more easily be presented at the time of installation. BUT IT HAS TO BE TRUSTED.

Ok... we don't have this yet because Python basically has no sandboxing capabilities. It's super annoying, but hopefully ivanq's backgroundprocessing stuff can work? idk, we need testers and auditors!!!

[krixano]

another thought i had would be to verify the hash of the entire plugin folder against, say:

1. a github commits metadata (idk)

This wouldn't help much honestly, you still have to trust the github commits. The problem isn't at all about verifying whether any outside source changed the files - because ZeroNet already does this. The problem is twofold - trusting the plugin itself, and ensuring that the owner of the zite uploading to doesn't change the plugin - for which a signature is enough. The first problem can be solved by some sandboxing system (BackgroundProcessing!) Let's not add complexity when it literally offers nothing that you can't get with the simpler solution. Github commits are useful for open source projects and for versioning, but that's a separate thing to what signatures provide.

Btw, if you like IPFS use IPFS, don't use ZeroNet.

[krixano]

Me an ivanq talked a while ago about some things that can be done, some of them simple, other's not:

1.) Python plugin sandboxing and permission system - hard 2.) Signatures added to plugins - imo, this is needed, most plugin systems for other software (like browsers) have some way to do this. These plugin systems also make sure updates don't happen unless the signature matches. This doesn't need to be centralized like chrome and firefox stores though. 3.) Software that will analyze plugins to make sure they aren't doing anything malicious - like an antivirus!

[d14na]

but hopefully ivanq's backgroundprocessing stuff can work?

are you talking about this? https://github.com/HelloZeroNet/Plugin-BackgroundProcessing

i kinda get it, but where is it used, so I can see a practical example of its purpose, OR if u don't mind giving me a quick explanation of what its for

trusting the plugin itself, and ensuring that the owner of the zite uploading to doesn't change the plugin - for which a signature is enough

yes, you mentioned the signature before, but how does that solve the problem of code changing UNKNOWINGLY? all you verify is that it came from a "trusted" source. i'd prefer to know that the code I want is immutable, that's the only reason i mention IPFS. as Zeronet updates site automatically be default, you just NEVER KNOW if that's the plugin code you want, unless you CLONE and read the source. am I wrong?

Python plugin sandboxing and permission system - hard

yes, quite challenging indeed, but this is the direction I would support

Signatures added to plugins - imo, this is needed

agreed, its needed, but DOES NOT solve code immutability problem (again, this is ONLY a problem, because sites AUTO-UPDATE)

Software that will analyze plugins to make sure they aren't doing anything malicious

YES! i don't know how to program that (STATIC ANALYSIS), but I can envision the dev community reviewing each commit and maybe SIGN IT! when you go to install, you can review the signatures on a SPECIFIC VERSION of the plugin.

i gotta run, but the idea is to then update the Plugin Manager to verify each file against a REGISTERED hash list of the files. i'd love to discuss this more, and thanks so much for the feedback

[krixano]

yes, you mentioned the signature before, but how does that solve the problem of code changing UNKNOWINGLY? all you verify is that it came from a "trusted" source. i'd prefer to know that the code I want is immutable

Code doesn't change unknowingly. Code changes by the person who uploaded the content or by the zite owner. The only thing ZeroNet allows is if the zite owner changes the plugin. if this happens, then the plugin signature would be invalid (the plugin signature is just the plugins hash encrypted by a key, to verify the signature, decrypt it with the public key then compare hashes). This is literally the same way that zite signatures work to prevent tampering.

And if you're talking about just preventing auto-updates, ZeroNet already does that. You have to manually update plugins I believe and doing this will tell zeronet to copy over the new plugin version. If this is not currently the case, then it's a very easy thing to change.

Otherwise, what your talking about requires big changes to optional files to make them immutable-only (or maybe we can have the ability to make some files immutable). I'd rather have optional file immutability optional rather than forced. "Immutability" is just a fancy word for clients not accepting file changes for already-existing files, so yeah... (also, in this case, no potentially-centralized registered hash of files is really needed I'm pretty sure).

[krixano]

i kinda get it, but where is it used, so I can see a practical example of its purpose, OR if u don't mind giving me a quick explanation of what its for

KxoId Trusted Peers use it to sign user registration requests in the background without having to have the browser open. This is the only know use for it atm, but I'm working on another thing. BackgroundProcessing is very useful when paired with PeerMessage.

[d14na]

the plugin signature is just the plugins hash encrypted by a key, to verify the signature, decrypt it with the public key then compare hashes

i misunderstood your purpose for the signature, as i believed it was to validate the IDENTITY of the developer, not to authenticate the code itself. yes! exactly how it does for the content.json, that's what i'm looking to standardize for easy discover for the user.

You have to manually update plugins

yes you do. but my example is this: i've read the source and installed a plugin (eg PeerMessage) and its working great, no issues. now i tell a friend to install it so that we can chat. I PERSONALLY feel uncomfortable doing that with the current PluginManager, as there's no way to verify that the version I TRUST will be the same version my friend will install (unless i clone the site). so the signature solution, as I now understand your purpose WOULD solve that, now its just to implement it.

the last point i made was it would be nice to have those same CODE signatures, also "signed" by respected community members to reinforce the TRUST. i mentioned Android before, but a much better reference would be F-DROID

---

Otherwise, what your talking about requires big changes to optional files to make them immutable-only

no no no, nothing like that

KxoId Trusted Peers use it to sign user registration requests in the background without having to have the browser open. This is the only know use for it atm, but I'm working on another thing. BackgroundProcessing is very useful when paired with PeerMessage.

got it!

[purplesyringa]

the last point i made was it would be nice to have those same CODE signatures, also "signed" by respected community members to reinforce the TRUST

Something like AMO would help here, wouldn't it?

[krixano]

i misunderstood your purpose for the signature, as i believed it was to validate the IDENTITY of the developer

Actually, I believe it does both, because it makes sure that the code uploaded only was done by that id - that nobody tampered with the code. This is basically useful if someone reuploads the plugin somewhere else.

so the signature solution, as I now understand your purpose WOULD solve that, now its just to implement it.

No, the signature solution doesn't do that.... because the hash of the code would be encrypted by the id of the creator. They can release a new version by reencrypting the new hash.

Basically, what you want is that each new change is released separately so that people can download older versions. Or... versioning (not quite the same thing, but the same result).

[krixano]

We can reinforce trust by just creating a zite where people can upvote a plugin (or separate plugin versions). We can even include a hash of the plugin to ensure what version of the plugin they upvoted if we need. I would also list out the names/ids of the people who upvoted a plugin (and perhaps be able to filter out the people you trust) so that we can see whether the people who upvoted it are themselves trustworthy.

It's good not to overthink things and overcomplicate them when not needed.

[d14na]

We can reinforce trust by just creating a zite where people can upvote a plugin (or separate plugin versions). We can even include a hash of the plugin to ensure what version of the plugin they upvoted if we need. I would also list out the names/ids of the people who upvoted a plugin (and perhaps be able to filter out the people you trust) so that we can see whether the people who upvoted it are themselves trustworthy.

umm, yeah, that's everything that i said. are you agreeing?

[krixano]

What you said was, imo, ambiguous, so I didn't know exactly what you meant. Because there's two ways to do this...

1.) My idea relies on the plugin store and in no way involves ZeroNet core 2.) The other idea was to require multiple people to sign one signature for a plugin and that this one siagnature signed by multiple people is stored in the plugin. I can't remember what this encryption is called.

[d14na]

My idea relies on the plugin store and in no way involves ZeroNet core

agreed, no changes to core

The other idea was to require multiple people to sign one signature for a plugin and that this one siagnature signed by multiple people is stored in the plugin

not stored IN THE PLUGIN (not sure how that would work), but in METADATA for the plugin's store listing. and NOT required, but the more "quality" signatures the higher a plugin's release would be "rated".

in the end, i believe we can agree that trust and security must be prioritized. however the "signatures" work will become clearer i'm sure. no worries, i have enough feedback to at least implement what i have in mind, then i'm sure there will be another round of feedback (then rinse and repeat till its ALL DONE!)