Community Plugin - Security Hint and Quality Gate

[LarsKumbier]

Use case or problem

Community plugins are great and one of the great features of Obsidian is allowing the ecosystem to thrive. However, community plugins pose a lot of security challenges - even if we trust the developer of a plugin, supply chain insecurities and attacks through dependencies are quite problematic.

Currently, you’d have to check every plugin before installing by hand and continuously monitor changes - and you need to be capable in terms of skill to do so. This has been stated extensively on the plugin help page.

This is why there’s already the safe mode check in the settings in place - but the reputation risk of a widespread data leak through a community plugin will fall back on Obsidian - a “they accepted our ToS and disabled the safe-mode-check” is a bandaid for that at best. I think we can do better.

Proposed solution

I suggest to add a developer agreement as a prerequisite for plugins to be listed in the official community plugin list / be accepted in to the Obsidian releases repository. This developer agreement should at the very minimum include:

• the pledge to include automatic security checks for production dependencies through dependabot or a similar product,
• the pledge of the plugin developers to handle security issues within 14 days (either by closing unfitting PRs from dependabot or merging them),
• the pledge to inform Obsidian through a PR to the deprecation-list, if they are unable or unwilling to continue this work in the future, and
• the pledge to continue this support for a grace period of at least 60 days, so that another maintainer can be found or the plugin can be deprecated and delisted

Additionally, a workflow from Obsidian should exist to check the listed community plugins against npm audit or yarn audit or utilizing the existing dependabot to automatically add a clearly visible insecure tag in the plugin list to affected plugins, that have not fixed the security issues within the 14 day window. This could be e.g. done in the obsidian-releases CI pipeline once a day.

Obsidian should also warn any user, if they have installed and enabled an insecure or deprecated plugin.

This measure would

• allow non-technical users to spot and be warned on insecure community plugins
• put pressure on developers to stand by their commitment to fix security issues
• therefore trying to keep their dependency tree small to minize their necessary upkeep time (also has the benefit of smaller plugins and less memory usage)
• while having relatively low upkeep-cost for the Obsidian team through automation

[I-d-as]

While I don’t understand the specifics of everything you say here, I can get the gist and would assume most people would appreciate more security. Perhaps if the critics of your suggestions won out, there could be a compromise that would provide a middle ground between safe mode on and safe mode off that would meet your suggestions. And, it simply wouldn’t be available for plugins that haven’t met the conditions. Consequently, the plugins wouldn’t be available for use while in this liminal state. Anyways, thanks for sharing your understanding of this complex subject!

[LarsKumbier]

Hey @I-d-as,

thanks for your reply! It seems that my proposal or problem domain is not clear enough, which doesn’t help getting it on the agenda… Could you elaborate, which parts you have trouble understanding, so that I can rewrite or extend them? Is it too technical to understand?

Edit: I’ve rephrased and restructured the proposal a bit to make it clearer. The term code-of-development was very misleading, sorry for that.

[EleanorKonik]

I don’t really have any objections per se — this isn’t my area of expertise. I just want to note that I’m reasonably confident —based on my experiences with people asking me about new plugins they heard about through the Roundup — that a potential unintended side-effect of this might be that more plugin developers say “I don’t necessarily feel able to commit to looking at things every 14 days, this isn’t my day job and I have kids, so I’m not going to submit, but if you guys want it, here’s the link to the github repo, you can install it via BRAT.”

Then there’s no code review and it never goes into the plugin store but people still use it because the BRAT plugin makes it easy, and there evolves a sort of “grey market” of popular unlisted plugins that Licat can’t easily deprecate/disable/pull when a data loss bug sneaks through (and data loss bugs are, I think, a thing that is maybe more common of a problem — though it’s still very rare —and that “automatic security checks of the dependencies” are unlikely to catch).

[argentum]

@EleanorKonik

“I don’t necessarily feel able to commit to looking at things every 14 days, this isn’t my day job and I have kids, so I’m not going to submit, but if you guys want it, here’s the link to the github repo, you can install it via BRAT.”

I agree with this. I think we can’t reasonably expect that plugin devs provide support as if it was a full-time job. Most people in the community are creating and maintaining plugins as volunteers, on their free time, out of the goodness of their hearts and with the intention to help as many people as they can.

A developer agreement that includes this, once a dev has decided to stop maintaining a plugin, sounds reasonable to me:

@LarsKumbier

the pledge to inform Obsidian through a PR to the deprecation-list, if they are unable or unwilling to continue this work in the future, and

The remaining three points are good practices, and without the time pressure, would probably be adopted by plugin devs to the best of their abilities. I believe we will get a lot further if we kindly support these volunteers, so they can keep doing the great job that they are doing. These could be added to the PR template (strike-through and bold are my edits):

@LarsKumbier

• the pledge to include it is highly recommended that you set up automatic security checks for production dependencies through dependabot or a similar product, here is a guide on how to enable them,
• the pledge of the plugin developers to handle security issues within 14 days here is a guide on how to handle dependabot security alerts (either by closing unfitting PRs from dependabot or merging them),
• the pledge to continue this support for a grace period of at least 60 days, so that if you need help maintaining your plugin, here is a guide on how another maintainer can be found or the plugin can be deprecated and delisted, (e.g. by opening a specific issue type in the obsidian-releases repo).

Some server-side checks that inform users in the plugin store when was the last release, and whether there are any known dependency vulnerabilities for it sound reasonable to me.

As a user, you can also take up part of this work load and periodically review your plugins, e.g. Scan Your Code and Open Source for Vulnerabilities for Free | Snyk or another scanner of your choice and of course opening PRs to solve such issues.

[Dor]

@argentum

As a user, you can also take up part of this work

I think it’s important that users have an understanding and take responsibility for their own security. Neither software, nor the internet can be separated into safe and dangerous. There are degrees of risk across the board (never nil) and some data needs more protection than others.

[LarsKumbier]

Thank you for your support and a lively discussion, @argentum, @Dor and @EleanorKonik.

@argentum

I agree with this. I think we can’t reasonably expect that plugin devs provide support as if it was a full-time job. Most people in the community are creating and maintaining plugins as volunteers, on their free time, out of the goodness of their hearts and with the intention to help as many people as they can.

In my experience, regular security updates are not only best practice, but they also only take a few minutes 95% of the time due to non-breaking changes. And if it’s pipelined, it’s a breeze.

I’d even go as far as saying, that you should not write a plugin, if you are unable to support a few minutes every two weeks to accept a security PR - you are endangering every user of your plugin, if you don’t do this regularly.

But I see your concerns in terms of devs pulling out. How about making this pledge an opt-in feature, that plugin devs can get as a tag behind the plugin? That way, we’d have some peer pressure.

@argentum

As a user, you can also take up part of this work load and periodically review your plugins, e.g. Scan Your Code and Open Source for Vulnerabilities for Free | Snyk or another scanner of your choice and of course opening PRs to solve such issues.

@Dor

I think it’s important that users have an understanding and take responsibility for their own security. Neither software, nor the internet can be separated into safe and dangerous. There are degrees of risk across the board (never nil) and some data needs more protection than others.

While this is possible for users with the skillset to do so, a lot of users probably(?) don’t - I can’t say how many non-tech-savvy users Obsidian has. Additionally, it would make a lot more sense to have this central in one location instead of expecting thousands of users to do this by themselves.

Blaming the user for not doing this misses the point. Publishing software bears responsibility - there’s a heap of problems from insecure services and servers on the internet for decades, which are being used for DDoS attacks, data exfiltration, spam, etc. Saying that people need to take responsibility for what plugins they run and install - without having any quality indicator - just feels wrong to me and shifts blame towards the enduser. Who might not even be able to differentiate between good and bad or up-to-date and outdated software…

We could help them decide that with the aforementioned flag and the warning, if a security issue has not been handled in time. This would make the situation better for everyone with minimal effort from plugin developers and the Obsidian team.

[EleanorKonik]

@LarsKumbier

I’d even go as far as saying, that you should not write a plugin, if you are unable to support a few minutes every two weeks to accept a security PR - you are endangering every user of your plugin, if you don’t do this regularly.

When I see a statement like this, it says to me, “I should never try to join the plugin developer community because it would be dangerous and irresponsible of me to even try.”

I’m not sure that philosophy is in line with the community obsidian has built… but I’m not an expert, and I guess you’re right, I never should have even tried to create something that other people could use to help concatenate their files. What if they didn’t know enough to make backups and it went wrong, or it accidentally infested their operating system with malware that was involved in one of my dependencies.

You’ve given me food for thought, thank you.

[argentum]

@LarsKumbier

In my experience, regular security updates are not only best practice, but they also only take a few minutes 95% of the time due to non-breaking changes. And if it’s pipelined, it’s a breeze.

I’d even go as far as saying, that you should not write a plugin, if you are unable to support a few minutes every two weeks to accept a security PR - you are endangering every user of your plugin, if you don’t do this regularly.

But I see your concerns in terms of devs pulling out. How about making this pledge an opt-in feature, that plugin devs can get as a tag behind the plugin? That way, we’d have some peer pressure.

I am strictly against imposing any time constraints on this.

I am speaking for myself only right now: I don’t need peer-pressure to add more work to my plate. Personally, this would make me pull my plugins from the store, even if we made this an opt-in workflow. I have enough to do with work, PhD and other personal projects to keep me plenty busy. I developed the plugins because I had a problem that I wanted to be solved, and decided to offer them to the community because they could help others. I’ve taken issues and PRs whenever I’ve been able to, but this has added a not insignificant amount of work that does not benefit me, but helps others. And I do it gladly, whenever I can spare some time and even enjoy it!

Once you turn that into an obligation to respond within X time, or else… it becomes a job. It’s a job that doesn’t pay me. Sponsorships (if I could legally accept them) would not be able to cover my hourly rate. And, when given the choice between an additional job and what I consider a hobby, I would simply unlist my plugins, stop accepting PRs and requests, and maintain them for myself, so I can spend my time in another hobby of mine. I am a single data point, maybe other devs won’t mind.

@LarsKumbier

Blaming the user for not doing this misses the point.

Putting the burden on the developers only would give users, especially non-technical ones, a false sense of security. If security is an issue, in my opinion, either (a) users should not use plugins or (b) should have a threat model that allows them to evaluate their risks and take appropriate measures, whatever those may be. Would this feature help? Maybe, but IMO it would be insufficient and potentially dangerous for users that don’t understand what the “tag” means or implies. See Security of the plugins for a more thorough discussion.

For many developers, plugins are their first programming project ever. Many have learned to program just to tackle something they wanted to do differently. The community really prides itself with supporting people who are eager to learn. In that regard, I’d consider the plugin store a hobby plugin store. People have shared something they made, and no one has forced anyone to use it. Imposing this feature with time constraints, even by making it “optional” and expecting peer-pressure to take care of it, would discourage many/most or at least some developers and the community would suffer for it. If security and timely responses are a requirement, in my opinion, people should consider hiring a professional developer to build and/or maintain the plugin they need, and who can respond within their expected/required timeframe (whatever that may cost).

[LarsKumbier]

Eleanor, being salty and condescending is uncalled for and unnecessary, and does not add anything to this otherwise respectful exchange of opinions.
I grossly misinterpreted @EleanorKonik post. Please refer to my next message to keep it up. I’ll leave the original reply here for future reference, so that others can learn from it.

[LarsKumbier]

@argentum

I am speaking for myself only right now: I don’t need peer-pressure to add more work to my plate. Personally, this would make me pull my plugins from the store, even if we made this an opt-in workflow.

@argentum

For many developers, plugins are their first programming project ever. Many have learned to program just to tackle something they wanted to do differently. The community really prides itself with supporting people who are eager to learn.

I would not have expected this to have such a strong response, even for an opt-in point - I do see your point though. As you said: The “obligation” makes it more of a job than a hobby, which takes most of the fun out. Your idea of supporting the plugins developers instead might be the best compromise between enhanced security (automatic pipeline checks could still be done by Obsidian, community could offer help to implement it via PRs, etc.).

Also, since the other post you mentioned already covers the same topic, I’d close this one - no need to have duplicates. Thanks for your thoughts!

[EleanorKonik]

I want to be clear, because I was asked to be by another mod, that I didn’t mean that in a “Salty and condescending” way, I meant it genuinely, from the heart. Your post caused me to rethink my desire to join the programming community in a very real and genuine way, because I am not in a position to do so ethically and safely, and to be rather more emotionally honest than I am wont to be on the internet, moved me to genuine tears because I thought I had finally found a place where I could learn and I’m now finding out that I am part of the problem.

I used to be very excited about what this community did for transforming the gatekeeping of programming and now I feel like a horrible person.l

I thought it was important to express that so that that point of view was not missed here.

I am sorry if that was expresssed poorly and made you think I was being rude

[LarsKumbier]

Hi @EleanorKonik,

in that case I have to apologize - it seems that I completely misinterpreted your comments. I interpreted your comment as an ironic and over-topped mockery and not as a genuine approach of providing your emotions. I am very, very sorry for this - the usual subtones of a normal face-to-face conversation are unfortunately lost here and sometimes things get misinterpreted through that. Again, I’m very sorry.

You should not be discouraged of writing plugins or code that solves any of your problems - code is poetry and it’s one of the very few hobbies that is creative and accessible and can do so much good for so many people, if it’s open sourced. And you are absolutely right, that my original proposal would be a hard pill to swallow for beginners.

I think @argentum is on the right track here. Start with a developers pledge, but always in a supportive manner. Encourage programmer newbies to share their first plugin on the forums and ask for feedback. Encourage them with PR to setup an easy pipeline for things like automatic dependency upgrades. Checking the code and getting in PRs to make it better, so that newbies can learn.

Pledge and support - how do you feel about that?