RFC: Consider changing how we accept third-party plugins to improve security

laurent · 2023-12-22T11:46:26.951Z

I've opened an RFC here to see whether we can integrate a review process to plugin publishing. If you have any comments or questions about it feel free to post here or on GitHub!

github.com/laurent22/joplin

RFC: Consider changing how we accept third-party plugins

opened 11:44AM - 22 Dec 23 UTC

laurent22

enhancement security desktop plugins

Currently, the Joplin application gets the list of plugins from our [GitHub repo…sitory](https://github.com/joplin/plugins), and that repository is automatically built based on the third-party plugins that have been published to npm. We generally don't do any checks on these plugins except for those that are marked as "recommended", which are those developed by the team or long term contributors. In order to make it safer for users to install plugins, it would be good to have a review process. Many plugins are relatively simple and we have perhaps 3 or 4 updates per week so it should be doable. The advantage is that we can guarantee that all reviewed plugins are safe to install, which would be interesting to users who no longer need to limit themselves to recommended plugins only. To minimise changes to the existing process, we could integrate the review process in that way: - Publishing to npm will no longer be relevant - Instead, we would check the code directly on the repository - The code itself - But also the dependencies - we should only accept dependencies to well-known, safe packages - If all is good, we record the repository url and commit that we've reviewed - When building the plugin repository, we would automatically: - Fetch the third-party repositories at the previously recorded commit - Build the plugin - Add the .jpl to our plugin repository Once we have the .jpl the rest of our process will be identical. ## Questions - What to do about plugins that we have not yet reviewed - should we include them and mark them as "not reviewed". Or exclude them completely? - How about plugins that are not published to any public repository? (not sure if they exist) - For review, we should have some tool to generate a diff between the last reviewed commit and the latest one - We should probably have a process to allow the plugin developer to tell us when their plugin is ready for review, otherwise we may fetch a commit that's still under development

The full post:

Currently, the Joplin application gets the list of plugins from our GitHub repository, and that repository is automatically built based on the third-party plugins that have been published to npm. We generally don't do any checks on these plugins except for those that are marked as "recommended", which are those developed by the team or long term contributors.

In order to make it safer for users to install plugins, it would be good to have a review process. Many plugins are relatively simple and we have perhaps 3 or 4 updates per week so it should be doable. The advantage is that we can guarantee that all reviewed plugins are safe to install, which would be interesting to users who no longer need to limit themselves to recommended plugins only.

To minimise changes to the existing process, we could integrate the review process in that way:

Publishing to npm will no longer be relevant
Instead, we would check the code directly on the repository
- The code itself
- But also the dependencies - we should only accept dependencies to well-known, safe packages
If all is good, we record the repository url and commit that we've reviewed
When building the plugin repository, we would automatically:
- Fetch the third-party repositories at the previously recorded commit
- Build the plugin
- Add the .jpl to our plugin repository

Once we have the .jpl the rest of our process will be identical.

Questions

What to do about plugins that we have not yet reviewed - should we include them and mark them as "not reviewed". Or exclude them completely?
How about plugins that are not published to any public repository? (not sure if they exist)
For review, we should have some tool to generate a diff between the last reviewed commit and the latest one
We should probably have a process to allow the plugin developer to tell us when their plugin is ready for review, otherwise we may fetch a commit that's still under development

JackGruber · 2023-12-22T12:46:36.174Z

laurent:

What to do about plugins that we have not yet reviewed - should we include them and mark them as "not reviewed". Or exclude them completely?

I would display them anyway, as there may be many useful plugins that are no longer listed and all reviewed are marked or the other ones marked as not reviewed.

laurent:

How about plugins that are not published to any public repository? (not sure if they exist)

I would still have them installed manually, but as these are not reviews, it is everyone's responsibility

laurent:

We should probably have a process to allow the plugin developer to tell us when their plugin is ready for review, otherwise we may fetch a commit that's still under development

How would it be that there simply has to be a git tag for the published versions?

james-carroll · 2023-12-22T15:36:37.840Z

I think the ideal situation would be that only "recommended" plugins were visible by default, with a checkbox that allows viewing the rest but labelled advising the users that they haven't been checked for quality and may not get future maintenance.

I think the maintenance part of this is as important to consider as e.g security. Whilst we want the plugins to be secure, you'd also not want the plugin ecosystem to rot overtime, where people might refuse to upgrade Joplin because an essential plugin for their workflow doesn't work with newer releases. Or where a plugin might begin to actively interfere with the core app and might not be ever updated; harming the opinion of the core app when people attribute blame to the core app and not the plugin.

But this is coming from the perspective of someone who absolutely tries minimise how many programs/tools/plugins I install regardless of what they relate to, not opinions about Joplin itself specifically since I don't use Joplin plugins anyway.

Asking plugin authors to promise a best effort going forward as a requirement to becoming recommended is probably as important as the security review side of things.

muzak · 2023-12-22T20:18:22.299Z

Here is my suggestion:

Show all public plugins, regardless of review status, to make them discoverable without extra clicks. Categorize plugins by review status like how the plugin discovery site does for recommended plugins. This visually separates plugins by status and designates a spot to explain each status.

Is there any protocol for handling abandoned plugins, broken plugins, or those incompatible with newer versions of Joplin?

candrak · 2023-12-25T21:43:05.026Z

Delighted to hear of this initiative.

Firefox has a model y'all may consider adapting, in the Recommended Extensions program. My suggestion would be to get started by adopting just the basic tenets. Consider the rest later as the Joplin plugin program develops.

support.mozilla.org

Recommended Extensions program | Firefox Help

Learn how extensions make the cut for the Recommended Extensions program and where they can be found.

tl:dr

What is this?

"Recommended extensions differ from other extensions that are regularly reviewed by Firefox staff in that they are curated extensions that meet the highest standards of security, functionality, and user experience. Firefox staff thoroughly evaluate each extension before it receives Recommended status."

Discovery

Those Recommended get a badge, and can be found through filters.

https://addons.mozilla.org/en-US/firefox/search/?promoted=recommended&type=extension

They can also be found as a category on the Extensions page. Along with others.

addons.mozilla.org

Add-ons for Firefox (en-US)

Download Firefox extensions and themes. They’re like apps for your browser. They can block annoying ads, protect passwords, change browser appearance, and more.

personalizedrefriger · 2024-04-15T16:08:54.365Z

muzak:

Is there any protocol for handling abandoned plugins, broken plugins, or those incompatible with newer versions of Joplin?

Yes. Plugins are occasionally marked as _obsolete on the plugin repository. See obsoletes.md for details. This commit, for example, marks a plugin with the wrong ID as _obsolete.

For unmaintained plugins, there is also a mechanism for transferring the source NPM package used for updates. This could be useful if, for example, the Joplin team decides to start maintaining an abandoned plugin. So far, this mechanism hasn't been used.

(Sorry for taking so long to reply!)