This is one way to look at it, but ignores the fact that most users use third party community plugins.
Obsidian has a truly terrible security model for plugins. As I realized while building my own, Obsidian plugins have full, unrestricted access to all files in the vault.
Obsidian could've instead opted to be more 'batteries-included', at the cost of more development effort, but instead leaves this to the community, which in turn increases the attack surface significantly.
Or it could have a browser extension like manifest that declares all permissions used by the plugin, where attempting to access a permission that's not granted gets blocked.
Both of these approaches would've led to more real security to end users than "we have few third party dependencies".
When I was young there were a few luminaries in the software world who talked about how there is a steady if small flow of ideas from video game design into conventional software.
But I haven't heard anyone talk like that in quite sometime (unless it's me parroting them). Which is quite unfortunate.
I think for example if someone from the old guard of Blizzard were to write a book or at least a novella that described how the plugin system for World of Warcraft functioned, particularly during the first ten years, where it broke, how they hardened it over time, and how the process worked of backporting features from plugins into the core library...
I think that would be a substantial net benefit to the greater software community.
Far too many ecosystems make ham-fisted, half-assed, hair-brained plugin systems. And the vast majority can be consistently described by at least two of the three.
Funny enough, I thought this earlier about Arch Linux and it's deritives. It was mentioned on reddit that they operate on a small budget. A maintainer replied that they have very low overhead, and the first thought that popped into my mind was that most of the software I use and rely on comes from the AUR, which relies on the user to manage their own security.
If engineers can't even manage their own security, why are we expecting users to do so?
I'm developing an Obsidian plugin commercially. I wish there was a higher tier of vetting available to a certain grade of plugin.
IMO they should do something like aur on Arch Linux and have a community managed plugin repo and then a smaller, more vetted one. That would help with the plugin review time too.
I think it's a matter of time until we see a notable plugin in the obsidian space get caught exfiltrating data. I imagine then, after significant reputational harm, the team will start introducing safe guards. At a minimum, create some sort of verified publisher system.
Don’t most plugin models work this way? Does VSCode, Vim, Emacs, and friends do anything to segregate content? Gaming is the only area where I expect plugins have limited permissions.
Another thought: what about severely sandboxing plugins so they while they have access to your notes, they have no network or disk access and in general lack anyway for them to exfiltrate your sensitive info? Might not be practical but approaches like this appeal to me.
As someone who specifically started building Octarine, just for this reason, I understand.
Having to rely on random devs for the most basic functionality and passing it off as `community does what it wants` is weird. Either add it in yourselves, or accept the fact that given your app requires external contributors to work at a little above the basic level, there are going to be security issues.
Writing a whole blog post, and throwing shade on "other apps" that have far more dependencies than Obsidian is weird to me.
Anyway, it seems like you can't really talk bad about them, since there's a huge following that just comes at you, and that feels weird, cause they apparently can throw shade, others can't just talk back.
> could've instead opted to be more 'batteries-included', at the cost of more development effort, but instead leaves this to the community, which in turn increases the attack surface significantly.
This app deals with very critical, personal, and intimate data – personal notes and professional/work-related notes, but proudly has an Electron app. This alone has seemed like a massive red flag to me.
It's no worse than vscode. Sure there's permissions, but it's super common for an extension to start a process and that process can do anything it wants.
My personal take is that the only way to be reasonably sure you're OK is to install as few apps as possible and then as few plugins as possible (and ideally stick to the bundled ones only). I don’t think it’s controversial, but for some reason this is not how many people think, even if in the real world you don’t give keys to your place to everyone who says they’re cool :)
Among others, this is a big reason I want effect systems to gain more attention. After having seen them, the idea that in most languages, the only option is that any function can do anything without keeping track of what it affects in its type signature is bonkers to me.
I agree Obsidian plugins do nothing about safety. But I'm not sure "most users use plugins", that's not my impression from reading the subreddit. I wonder if there's any data on it?
Is this true? Is there any source about how many obsidian users use third party plugins? For once I don't. Moreover, obsidian by default runs in "restricted mode" which does not allow for community plugins. You have to specifically enable it to be able to install community plugins, hence I assume somebody who does that understands the risks involved. How many people even get into enabling that?
For me it is not even about security firstmost, the whole appeal of markdown is simplicity and interoperability. The more I depend on "plugins" the more I am locked in into this specific platform.
Yes, on desktop, Obsidian plugins can access files on your system, unless you run it in a container. On iOS, iPadOS, and Android the app is sandboxed so plugins are more constrained.
This is not unique to Obsidian. VS Code (and Cursor) work the same way despite Microsoft being a multi-trillion dollar company. This is why Obsidian ships in restricted mode and there's a full-screen warning before you turn on community plugins.
VS Code and Obsidian have similar tradeoffs, both being powerful file-based tools on the Electron stack. This fear about plugins was raised on the Obsidian forums in 2020 when Obsidian was still new, and Licat explained[1] why it’s not possible to effectively sandbox plugins without making them useless.
So... what do you do?
The drastic option is to simply not use community plugins. You don't have to leave restricted mode. For businesses there are several ways to block network access and community plugins[2]. And we're currently planning to add more IT controls via a policy.json file[3].
The option of using Obsidian without plugins is more viable in 2025 than it was in 2020, as the app has become more full-featured. And we're now regularly doing third-party security audits[4].
But realistically, most people want to run community plugins, and don't have the technical skills to run Obsidian in a container, nor the ability and time to review the code for every plugin update.
So the solution that appeals to us most is similar to the "Marketplace protections"[5] that Microsoft gradually implemented for VS Code. For example, implementing a trusted developer program, and automated scanning of each new plugin update. We plan to significantly revamp the community directory over the coming year and this is part of it.
Note that Obsidian is a team of 7 people. We're 100% user-supported[6] and competing with massive companies like Microsoft, Apple, Google, etc. Security audits are not cheap. Building an entire infrastructure like the one I described above is not easy. We're committing to doing it, but it wouldn't be possible without our supporters.
Yes, you are responsible for all the code you ship to your users. Not pinning dependencies is asking for trouble. It is literally, "download random code from the Internet and hope for the best."
Pinning dependencies also means you're missing any security fixes that come in after your pinned versions. That's asking for trouble too, so you need a mechanism by which you become aware of these fixes and either backport them or upgrade to versions containing them.
> We do not run postinstall scripts. This prevents packages from executing arbitrary code during installation.
I get the intent, but I’m not sure this really buys much. If a package is compromised, the whole thing is already untrustworthy and skipping postinstall doesn’t suddenly make the rest of the code safe. If it isn’t compromised, then you risk breaking legitimate installation steps.
From a security perspective, it feels like an odd tradeoff. I don’t have hard data, but I’d wager we see far more vulnerabilities patched through regular updates than actual supply-chain compromises. Delaying or blocking updates in general tends to increase your exposure rather than reduce it.
I agree but there's a bit of nuance here. Today scanning steps typically happen post install, which is wild but the status quo. Therefore preventing anything from running during install is desirable.
I'd like to see the ability to scan/restrict as part of the installation step become popular, there are some proprietary tools that do this already but it's not yet a common capability.
It does protect the build machine though. Seems like quality, low-hanging security fruit to me. If I want to casually hack on some random web app, I don’t have to worry about giving arbitrary scripts running from the ~4 gazillion dependencies.
I’ve been using other apps than Obsidian for notes and sharing, so this is nice to read and consider. But isn’t Obsidian an electron app or whatever? Electron has always seemed resource intensive and not native. JavaScript has never struck me as “secure”. Am I just out of touch?
JavaScript is a very secure language. The browser is a massive success at running secure JavaScript on a global scale. Every website you use is running JavaScript and not able to read other site data. Electron is the same, running v8 to sandbox JavaScript. Assuming you aren't executing user input inside that sandbox (something many programming languages allow, including JS), it's very secure.
The problem with supply chain attacks is specifically related to npm, and not related to JS. npm as an organization needs to be taking more responsibility for the recent attacks and essentially forcing everyone to use more strict security controls when publishing their dependencies.
Not a huge electron fan (thank god for tauri), but Obsidian is a fantastic app and you shouldn't let the electron put you off of it. You can even hook a MCP up to it and an agent can use it as a personal knowledge base, it's quite handy.
There’s some advice that’s been going around lately that I’ve been having trouble understanding: the idea that you should not be updating your dependencies when new patches are released (e.g., X.X.PATCH).
I understand that not updating your dependencies when new patches are released reduces the chance of accidentally installing malware, but aren’t patches regularly released in order to improve security? Wouldn’t it generally be considered unwise to not install new patches?
There's a key missing piece to this puzzle: being informed about _why_ you're updating and what the patches are.
Nobody has time to read source code, but there are many tools and services that will tell you brief summaries of release notes. Npm Audit lists security vulnerabilities in your package versions for example.
I do adopt the strategy of not updating unless required, as updates are not only an attack vector, but also an extremely common source of bugs that'd I'd prefer to avoid.
But importantly I stay in the loop about what exploits I'm vulnerable to. Packages are popping up with vulnerabilities constantly, but if it's a ReDoS vulnerability in part of the package I definitely don't use or pass user input to? I'm happy to leave that alone with a notice. If it's something I'm worried another package might use unsafely, with knowledge of the vulnerability I can decide how important it is, and if I need to update immediately, or if I can (preferably) wait some time for the patch to cook in the wild.
That is the important thing to remember about security in this context: it is an active, continuous, process. It's something that needs to be tuned to the risk tolerance and risk appetite of your organisation, rather than a blanket "never update" or "always update" - for a well-formed security stance, one needs more information than that.
I believe it's about waiting a bit before a new patch is released, not fully avoiding installing updates. Seems like compromises are being caught quickly these days, usually within hours. There are multiple companies monitoring npm package releases because they sell security scanning products and so it's part of their business to be on top of it.
pnpm has a setting that you can tell it that a package needs to be at least X minutes old in order to install it. I would wait at least 24 hours just to be safe
The attack that hit my packages two weeks ago was a patch release, taking advantage of this exact assumption. Wasn't a Post-Install script either.
With all of the latest in automated scanning and whatnot, this is more or less a moot point. You'll know when a package is vulnerable, and the alarm bells are loud and unambiguous. I really agree, and have always pushed the point, that version ranges are the worst things you can have if you care about supply chain attacks.
> Only a handful of packages are part of the app you run, e.g. Electron, CodeMirror, moment.js.
So they ship an extremely bloated package to ship a WebView based on one of the most complex pieces of software ever written, an entire code editor for text editing, and a deprecated time library that could be substituted by newer APIs and some glue code?
Honestly, it doesn't seem impressive at all. What Obsidian does is the bare minimum of how we should manage packages in any piece of software, not a testament to a serious security policy. They do security audits, though, which I find to be a good practice.
I love Obsidian dearly, but if you build an app that's only really useful with plugins, and that has a horrifyingly bad security model for plugins and little to no assurance of integrity of the plugins...
Maybe, just maybe, don't give fullmouthed advice on reducing risk in the supply chain.
Going to preface this post by saying I use and love Obsidian, my entire life is effectively in an Obsidian vault, I pay for sync and as a user I'm extremely happy with it.
But as a developer this post is nonsense and extremely predictable [1]. We can expect countless others like it that explains how their use of these broken tools is different and just don't worry about it!
By their own linked Credits page there are 20 dependencies. Let's take one of those, electron, which itself has 3 dependencies according to npm. Picking one of those electron/get has 7 dependencies. One of those dependencies got, has 11 dependencies, one of those cacheable-request has 7 dependencies etc etc.
Now go back and pick another direct dependency of Obsidian and work your way down the dependency tree again. Does the Obsidian team review all these and who owns them? Do they trust each layer of the chain to pick up issues before it gets to them? Any one of these dependencies can be compromised. This is what it means to be. supply chain attack, you only have to quietly slip something into any one of these dependencies to have access to countless critical user data.
Coincidentally I did that yesterday. Mermaid pulls in 137 dependencies. I love Obsidian and the Obsidian folks seem like good people but I did end up sandboxing it.
To be fair, the electron project likely invests some resources in reviewing it's own dependencies, because of its scale. But yeah this is a good exercise, I think we need more systems like Yocto which prioritize complete understanding of the entire product from source.
Absolutely love Obsidian but had to stop using it because Electron apps don't play well with Wayland. After lots of tinkering around with flags and settings for compatibility layers, it became obvious that it would never work seamlessly like it did on Windows (and probably does on x11). So it was either give up Wayland compositors or give up Obsidian. Luckily I don't use any plugins, so moving to other software was easy, but I still would prefer Obsidian. Electron's "works everywhere" works about as good as Java's "works everywhere", which is to say it works great, until it doesn't, at which point it's a mess of tinkering.
If you use Wayland and it works for you, that's great, but it's not my experience.
In my experience electron + Wayland was absolutely god awful for a long time, but it got dramatically better in the last 4-5ish months. So depending on when you last tried it, might be worth a revisit. Heavily depends on which GPU+DE though, Nvidia+Plasma here.
If the obsidian team did a 2 hour q&a livestream every week, I'd watch every one (or at least get the AI summary). One of my favorite pieces of software ever.
I went from Evernote to Joplin to Obsidian and really like the model of md files with some logic added on top. Initially I used a lot of plugins mostly out of curiosity, but now it's mostly RemotelySave for syncing and some small convenience plugins, so I hope my exposure isn't too high.
The app doesn't have the bloaty feel of other Electron apps, but if there was a good more native alternative that fits my bill (md files editable in a graphical mode with good wikilink-syntax support and similar search etc), then I would actually consider switching.
To be honest, right now I'm thinking about isolating of build process for frontend on my local environment. It is seems not hard to send my local environment variables like OPENAI_API_KEY or .ssh/* to some remote machine.
I know it is not very different comparing to python or projects in any other language. But I don't feel that I cannot trust node/js community at this point.
Switching to Deno might help. It's sandboxed by default and offers granular escape hatches. So if a script needs access to a specific environment variable or read or write specific files, it's simple to configure that only those accesses are allowed.
These practices are very similar to what I've done in the past, for a large, sensitive system, and they worked very well.
(IIUC, we actually were the first to get a certain certification for cloud deployment, maybe because we had a good handle on this and other factors.)
From the language-specific network package manager, I pulled the small number of third-party packages we used into the filesystem tree of system's repo, and audited each new version. And I disabled the network package manager in the development and deployment environments, to make it much harder for people to add in dependencies accidentally.
Dependencies outside this were either from the Linux distro (nice, because well-managed security updates), or go in the `vendor` or `ots` (off-the-shelf) trees of the repo (and are monitored for security updates).
Though, I look at some of the Python, JS, or Rust dependency explosions I sometimes see -- all dependent on being hooked up to the language's network package manager, with many people adding these cavalierly -- and it becomes a much harder problem.
Can’t wait for “implements mechanism to delay application of new patches” to start showing up compliance checklists. My procrastination will finally pay off!
This is obviously the way to do it, assuming you have the skills and resources to operate in this manner. If you don't, then godspeed, but you have to know going in that you are trading expediency now for risk later. Risk of performance issues, security vulnerabilities, changes in behavior, etc. And when the mess inevitably comes, at whatever inopportune time, you don't really get to blame other people...
I was talking to our chief architect about a blog post about our zero dependency home grown HTTP server[0]; the project just hit 1.2 and uses virtual threads. I'm generally a fan of "don't reinvent the wheel"[1], but I think there are some cases where that control is worth the cost.
Defending against security vulnerabilities is definitely one of them, as long as you make the proper investments to harden what you write.
Joel Spolsky write about some other reasons too[2].
An alternative for those who want a native application and/or even less supply-chain risk is Zim [1], which uses GTK and is packaged by the major Linux distributions.
Zim doesn't have a native phone app and syncing, though, and that's a big draw of Obsidian. It's plenty secure if you don't install plugins all willy-nilly.
I installed an AppArmor profile for Obsidian. For an application that displays text files, it needed a lot of permissions. It would refuse to run without network access.
You can install Obsidian flatpak and lock it down with flatseal.
It has been so rewarding and timely to see this post.
I just decided on Thursday after years of covering my ears and eyes from my obsidian-obsessed friends and coworkers that the tool just didn’t make sense to me, and I felt like I’d be in plugin purgatory on my computer for eternity.
I’ve ended up going with Reflect, after ~forever using Apple Notes primarily. So far so good, but I genuinely felt for so long I was supposed to love Obsidian because that’s the trope - appears that’s changing.
I use Emacs and Org-Roam, and some Emacs packages. It is hosted in a VM that is not connected to the internet (a Qube in Qubes OS). I just cannot review all the code running in Emacs.
Was hoping they outlined their approach to handling potentially compromised packages running on dev machines prior to even shipping. That seems like a much harder problem to solve.
Really? Is this some kind of perverted joke?
Electron based thing wants to brag about less being safer?
Get rid of the browser, then we can talk about less.
> Obsidian has a low number of dependencies compared to other apps in our category
Whataboutism. Relative comparisons don't address absolute risk. I checked three random packages: prism pulls 22, remark pulls 51, pixijs 179! So that's 250+ transitive dependencies just from those.
> Features like Bases and Canvas were implemented from scratch instead of importing off-the-shelf libraries. This gives us full control over what runs in Obsidian.
Full control? There are still hundreds of dependencies.
> This approach keeps our dependency graph shallow with few sub-dependencies. A smaller surface area lowers the chance of a malicious update slipping through.
> The other packages help us build the app and never ship to users, e.g. esbuild or eslint.
Build tools like esbuild don't ship to users, but a compromised build tool can still inject malicious code during compilation. This is supply chain security 101.
> All dependencies are strictly version-pinned and committed with a lockfile
Version pinning is, I would hope, standard practice in any professional development team years and years ago. It prevents accidental updates but doesn't stop compromised existing versions.
> When we do dependency updates, we:
> [snip]
While these practices are better than nothing, they don't fundamentally address the core issue.
> That gap acts as an early-warning window: the community and security researchers often detect malicious versions quickly
According to whom? Heartbleed, a vulnerability in a package with far more scrutiny than a typical npm module took what, 2 years to be found? The "community detection" assumption is flawed.
I'm not trying to put Obsidian down here - I sympathize, aside from implementing everything themselves, what can they do! I'm trying to point out that while their intent is good, this is a serious problem and their solution is not a solution.
Of course, it's the same in any project with dependencies. It's the same in other languages as well - if they have a convenient package manager. Like Rust and Cargo.
This problem came with the convenience of package managers and it should be fixed there, not by every application like Obsidian. I'm not sure how but maybe once a package is starting to become popular, additional security measures must be put in place for the author to be able to continue to commit to it. Signing requirements, reproducible builds, 2fa, community reputation systems, who knows.
Individual applications can't solve supply chain security through wishful thinking and version pinning.
Package managers need to solve this at the infrastructure level through measures like mandatory code signing, automated security auditing, dependency isolation, or similar system level approaches.
Obsidian's practices are reasonable given the current tooling limitations, but they don't eliminate the fundamental risks that the package managers bring to modern dependency ecosystems.
'It may sound obvious but the
primary way we reduce the risk of
supply chain attacks is to avoid depending on third-party code."
What a horribly disingenuous statement, for a product that isn't remotely usable without 3rd-party plugins. The "Obsidian" product would be more aptly named "Mass Data Exfiltration Facilitator Pro".
That's just...what? It's highly usable without plugins. Yes, I use plugins...but that's by choice. Obsidian is still a superior Markdown editor with backlink support, plugins or not.
This doesn't make any sense to me. I've always been told you don't write anything yourself unless you absolutely have to and having a million micro-dependencies is a good thing. JavaScript and now Rust devs have been saying this for years. Surely they know what they're doing...
There is a balance to be struck. NPM in particular has been a veritable dependency hell for a long time. I don't know if it just attracts inexperienced developers, or if its security model is fundamentally flawed, but there have been soooo many supply chain attacks using NPM that being extra careful is very much warranted.
I've been focused on writing software the last couple of weeks. What is obsidian again? I can't find a simple "what is obsidian?" FAQ on their site. Is it a browser or a node replacement like deno? Or an AI library? Clearly obsidian has plugins, but what are they in service of?
If it's a browser, they should have something on their web site that says "obsidian is a really cool browser." I think there are a lot of people out there who are ignoring the hype-train and it would do the community a service if they just started with answering that simple question. I mean sure, I get it, it's a "sharpen your thinking app," but I'm not sure what that means.
gejose|5 months ago
Obsidian has a truly terrible security model for plugins. As I realized while building my own, Obsidian plugins have full, unrestricted access to all files in the vault.
Obsidian could've instead opted to be more 'batteries-included', at the cost of more development effort, but instead leaves this to the community, which in turn increases the attack surface significantly.
Or it could have a browser extension like manifest that declares all permissions used by the plugin, where attempting to access a permission that's not granted gets blocked.
Both of these approaches would've led to more real security to end users than "we have few third party dependencies".
hinkley|5 months ago
But I haven't heard anyone talk like that in quite sometime (unless it's me parroting them). Which is quite unfortunate.
I think for example if someone from the old guard of Blizzard were to write a book or at least a novella that described how the plugin system for World of Warcraft functioned, particularly during the first ten years, where it broke, how they hardened it over time, and how the process worked of backporting features from plugins into the core library...
I think that would be a substantial net benefit to the greater software community.
Far too many ecosystems make ham-fisted, half-assed, hair-brained plugin systems. And the vast majority can be consistently described by at least two of the three.
ibash|5 months ago
Unless something has changed, it's worse than that. Plugins have unrestricted access to any file on your machine.
When I brought this up in discord a while back they brushed it aside.
eek2121|5 months ago
If engineers can't even manage their own security, why are we expecting users to do so?
dtkav|5 months ago
IMO they should do something like aur on Arch Linux and have a community managed plugin repo and then a smaller, more vetted one. That would help with the plugin review time too.
bryanhogan|5 months ago
bdzr|5 months ago
0cf8612b2e1e|5 months ago
justsomehnguy|5 months ago
And how exactly you can solve that?
I don't want to press 'allow access' on the every file some plugin is accessing.
varenc|5 months ago
zargon|5 months ago
rajatkulk|5 months ago
Having to rely on random devs for the most basic functionality and passing it off as `community does what it wants` is weird. Either add it in yourselves, or accept the fact that given your app requires external contributors to work at a little above the basic level, there are going to be security issues.
Writing a whole blog post, and throwing shade on "other apps" that have far more dependencies than Obsidian is weird to me.
Anyway, it seems like you can't really talk bad about them, since there's a huge following that just comes at you, and that feels weird, cause they apparently can throw shade, others can't just talk back.
Pikamander2|5 months ago
Ah, the WordPress model.
shelled|5 months ago
hahn-kev|5 months ago
TomaszZielinski|5 months ago
Jeff_Brown|5 months ago
NelsonMinar|5 months ago
freehorse|5 months ago
Is this true? Is there any source about how many obsidian users use third party plugins? For once I don't. Moreover, obsidian by default runs in "restricted mode" which does not allow for community plugins. You have to specifically enable it to be able to install community plugins, hence I assume somebody who does that understands the risks involved. How many people even get into enabling that?
For me it is not even about security firstmost, the whole appeal of markdown is simplicity and interoperability. The more I depend on "plugins" the more I am locked in into this specific platform.
gjsman-1000|5 months ago
kepano|5 months ago
Yes, on desktop, Obsidian plugins can access files on your system, unless you run it in a container. On iOS, iPadOS, and Android the app is sandboxed so plugins are more constrained.
This is not unique to Obsidian. VS Code (and Cursor) work the same way despite Microsoft being a multi-trillion dollar company. This is why Obsidian ships in restricted mode and there's a full-screen warning before you turn on community plugins.
VS Code and Obsidian have similar tradeoffs, both being powerful file-based tools on the Electron stack. This fear about plugins was raised on the Obsidian forums in 2020 when Obsidian was still new, and Licat explained[1] why it’s not possible to effectively sandbox plugins without making them useless.
So... what do you do?
The drastic option is to simply not use community plugins. You don't have to leave restricted mode. For businesses there are several ways to block network access and community plugins[2]. And we're currently planning to add more IT controls via a policy.json file[3].
The option of using Obsidian without plugins is more viable in 2025 than it was in 2020, as the app has become more full-featured. And we're now regularly doing third-party security audits[4].
But realistically, most people want to run community plugins, and don't have the technical skills to run Obsidian in a container, nor the ability and time to review the code for every plugin update.
So the solution that appeals to us most is similar to the "Marketplace protections"[5] that Microsoft gradually implemented for VS Code. For example, implementing a trusted developer program, and automated scanning of each new plugin update. We plan to significantly revamp the community directory over the coming year and this is part of it.
Note that Obsidian is a team of 7 people. We're 100% user-supported[6] and competing with massive companies like Microsoft, Apple, Google, etc. Security audits are not cheap. Building an entire infrastructure like the one I described above is not easy. We're committing to doing it, but it wouldn't be possible without our supporters.
[1] https://forum.obsidian.md/t/security-of-the-plugins/7544/3
[2] https://help.obsidian.md/teams/deploy
[3] https://x.com/kepano/status/1957927003254059290
[4] https://obsidian.md/security
[5] https://code.visualstudio.com/docs/configure/extensions/exte...
[6] https://stephango.com/vcware
mallowdram|5 months ago
schmichael|5 months ago
https://www.youtube.com/watch?v=eU2Or5rCN_Y
montroser|5 months ago
Scramblejams|5 months ago
lelandfe|5 months ago
I mean, jeeze, how much code comes along for the ride with Electron...
darkamaul|5 months ago
I get the intent, but I’m not sure this really buys much. If a package is compromised, the whole thing is already untrustworthy and skipping postinstall doesn’t suddenly make the rest of the code safe. If it isn’t compromised, then you risk breaking legitimate installation steps.
From a security perspective, it feels like an odd tradeoff. I don’t have hard data, but I’d wager we see far more vulnerabilities patched through regular updates than actual supply-chain compromises. Delaying or blocking updates in general tends to increase your exposure rather than reduce it.
mnahkies|5 months ago
I'd like to see the ability to scan/restrict as part of the installation step become popular, there are some proprietary tools that do this already but it's not yet a common capability.
jcgl|5 months ago
system7rocks|5 months ago
anon7000|5 months ago
The problem with supply chain attacks is specifically related to npm, and not related to JS. npm as an organization needs to be taking more responsibility for the recent attacks and essentially forcing everyone to use more strict security controls when publishing their dependencies.
dghlsakjg|5 months ago
It runs on a majority of computers and basically all phones. There will be many security issues that get discovered b y virtue of these facts.
What makes you think that "native" apps are any more secure?
CuriouslyC|5 months ago
da_chicken|5 months ago
I'd also be forced to ask... what exactly are you doing with a markdown note-taking application such that performance is a legitimate concern?
But, I mean, maybe you're reading this in a Lynx session on your ThinkPad 701C.
GabeIsko|5 months ago
tester457|5 months ago
It's not a problem on pc, but an obsidian vault with thousands of notes can have a laggy startup on mobile, even if you disable plugins.
Users sidestep this issue with quick capture plugins and apps, but I wish there was a native stripped-down version of obsidian.
SilverSlash|5 months ago
joshdavham|5 months ago
I understand that not updating your dependencies when new patches are released reduces the chance of accidentally installing malware, but aren’t patches regularly released in order to improve security? Wouldn’t it generally be considered unwise to not install new patches?
RadiozRadioz|5 months ago
Nobody has time to read source code, but there are many tools and services that will tell you brief summaries of release notes. Npm Audit lists security vulnerabilities in your package versions for example.
I do adopt the strategy of not updating unless required, as updates are not only an attack vector, but also an extremely common source of bugs that'd I'd prefer to avoid.
But importantly I stay in the loop about what exploits I'm vulnerable to. Packages are popping up with vulnerabilities constantly, but if it's a ReDoS vulnerability in part of the package I definitely don't use or pass user input to? I'm happy to leave that alone with a notice. If it's something I'm worried another package might use unsafely, with knowledge of the vulnerability I can decide how important it is, and if I need to update immediately, or if I can (preferably) wait some time for the patch to cook in the wild.
That is the important thing to remember about security in this context: it is an active, continuous, process. It's something that needs to be tuned to the risk tolerance and risk appetite of your organisation, rather than a blanket "never update" or "always update" - for a well-formed security stance, one needs more information than that.
flanbiscuit|5 months ago
pnpm has a setting that you can tell it that a package needs to be at least X minutes old in order to install it. I would wait at least 24 hours just to be safe
https://pnpm.io/settings#minimumreleaseage
junon|5 months ago
With all of the latest in automated scanning and whatnot, this is more or less a moot point. You'll know when a package is vulnerable, and the alarm bells are loud and unambiguous. I really agree, and have always pushed the point, that version ranges are the worst things you can have if you care about supply chain attacks.
weinzierl|5 months ago
Not only is npm a prominent target but it also does not allow packages to be removed or blocked for usage without a human on their side in the loop.
The result is that they are slow to remove malicious packages and slowing down your own updates helps to mitigate this a little.
unknown|5 months ago
[deleted]
runningmike|5 months ago
This should be: Supply chain attacks are malicious updates that sneak into source code used by many apps.
Stop blaming FOSS. Too many people still have the perception that FOSS software is insecure
doodlesdev|5 months ago
Honestly, it doesn't seem impressive at all. What Obsidian does is the bare minimum of how we should manage packages in any piece of software, not a testament to a serious security policy. They do security audits, though, which I find to be a good practice.
groby_b|5 months ago
Maybe, just maybe, don't give fullmouthed advice on reducing risk in the supply chain.
MonaroVXR|5 months ago
doesnt_know|5 months ago
But as a developer this post is nonsense and extremely predictable [1]. We can expect countless others like it that explains how their use of these broken tools is different and just don't worry about it!
By their own linked Credits page there are 20 dependencies. Let's take one of those, electron, which itself has 3 dependencies according to npm. Picking one of those electron/get has 7 dependencies. One of those dependencies got, has 11 dependencies, one of those cacheable-request has 7 dependencies etc etc.
Now go back and pick another direct dependency of Obsidian and work your way down the dependency tree again. Does the Obsidian team review all these and who owns them? Do they trust each layer of the chain to pick up issues before it gets to them? Any one of these dependencies can be compromised. This is what it means to be. supply chain attack, you only have to quietly slip something into any one of these dependencies to have access to countless critical user data.
[1] https://drewdevault.com/2025/09/17/2025-09-17-An-impossible-...
dsissitka|5 months ago
PhilipRoman|5 months ago
Mountain_Skies|5 months ago
If you use Wayland and it works for you, that's great, but it's not my experience.
lyu07282|5 months ago
yoavm|5 months ago
qntmfred|5 months ago
callc|5 months ago
An absolutely incredible piece of software. If anyone here on HN works on it, you deserve to be proud of your work.
elcapitan|5 months ago
The app doesn't have the bloaty feel of other Electron apps, but if there was a good more native alternative that fits my bill (md files editable in a graphical mode with good wikilink-syntax support and similar search etc), then I would actually consider switching.
xenator|5 months ago
I know it is not very different comparing to python or projects in any other language. But I don't feel that I cannot trust node/js community at this point.
mark_and_sweep|5 months ago
hahn-kev|5 months ago
neilv|5 months ago
(IIUC, we actually were the first to get a certain certification for cloud deployment, maybe because we had a good handle on this and other factors.)
From the language-specific network package manager, I pulled the small number of third-party packages we used into the filesystem tree of system's repo, and audited each new version. And I disabled the network package manager in the development and deployment environments, to make it much harder for people to add in dependencies accidentally.
Dependencies outside this were either from the Linux distro (nice, because well-managed security updates), or go in the `vendor` or `ots` (off-the-shelf) trees of the repo (and are monitored for security updates).
Though, I look at some of the Python, JS, or Rust dependency explosions I sometimes see -- all dependent on being hooked up to the language's network package manager, with many people adding these cavalierly -- and it becomes a much harder problem.
apitman|5 months ago
pier25|5 months ago
https://npmgraph.js.org/?q=express
mikeocool|5 months ago
Can’t wait for “implements mechanism to delay application of new patches” to start showing up compliance checklists. My procrastination will finally pay off!
montroser|5 months ago
mooreds|5 months ago
Defending against security vulnerabilities is definitely one of them, as long as you make the proper investments to harden what you write.
Joel Spolsky write about some other reasons too[2].
0: https://github.com/FusionAuth/java-http
1: https://en.wikipedia.org/wiki/Reinventing_the_wheel
2: https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...
dankobgd|5 months ago
ptx|5 months ago
[1] https://zim-wiki.org/
huimang|5 months ago
amai|5 months ago
kepano|5 months ago
for export it's the same reason many features don't exist yet — the team only has 3 full time developers
nylonstrung|5 months ago
Did anyone need the newest xz version in the first place? What negative tradeoffs would have come from pinning a 2022 release for example
deafpolygon|5 months ago
aborsy|5 months ago
You can install Obsidian flatpak and lock it down with flatseal.
testfrequency|5 months ago
I just decided on Thursday after years of covering my ears and eyes from my obsidian-obsessed friends and coworkers that the tool just didn’t make sense to me, and I felt like I’d be in plugin purgatory on my computer for eternity.
I’ve ended up going with Reflect, after ~forever using Apple Notes primarily. So far so good, but I genuinely felt for so long I was supposed to love Obsidian because that’s the trope - appears that’s changing.
oulipo2|5 months ago
Still, they can present a security risk by injecting malware at build time
daft_pink|5 months ago
platers|5 months ago
unknown|5 months ago
[deleted]
unknown|5 months ago
[deleted]
brentm|5 months ago
photon_garden|5 months ago
- All your data is just plain files on your file system. Automation and interop are great, including with tools like Claude Code.
- It’s local-first, so performance is good.
- It’s extensible. Write extensions in HTML, CSS, and JS.
- It’s free.
- Syncing files is straightforward. Use git, Syncthing, Google Drive, or pay for their cheap sync service which is quite good.
- Product development is thoughtful and well done.
- They’re explicitly not trying to lock you in or own your data. They define open specs and build on them when Markdown doesn’t cut it.
Things you might not like:
- Their collaboration story isn’t great yet. No collaborative editing.
- It’s an Electron app.
zvmaz|5 months ago
withinrafael|5 months ago
profsummergig|5 months ago
While we're on the topic: what's your default markdown handler on Windows?
password4321|5 months ago
User23|5 months ago
CMay|5 months ago
https://github.com/ionic-team/capacitor
https://github.com/Microsoft/tslib
https://github.com/codemirror
https://github.com/codemirror/autocomplete
https://github.com/codemirror/language
https://github.com/marijnh/style-mod
https://github.com/marijnh/crelt
https://github.com/marijnh/find-cluster-break
https://github.com/marijnh/w3c-keyname
https://github.com/cure53/DOMPurify
https://github.com/electron/electron
https://github.com/electron/get
https://github.com/debug-js/debug
https://github.com/vercel/ms
https://github.com/sindresorhus/env-paths
https://github.com/sindresorhus/got
https://github.com/sindresorhus/is
https://github.com/visionmedia/node-progress
https://github.com/npm/node-semver
https://github.com/malept/sumchecker
https://github.com/szmarczak/http-timer
https://github.com/szmarczak/defer-to-connect
https://github.com/szmarczak/cacheable-lookup
https://github.com/jaredwray/cacheable
https://github.com/biomejs/biome
https://github.com/sindresorhus/decompress-response
https://github.com/sindresorhus/mimic-response
https://github.com/octet-stream/form-data-encoder
https://github.com/szmarczak/http2-wrapper
https://github.com/szmarczak/resolve-alpn
https://github.com/sindresorhus/lowercase-keys
https://github.com/sindresorhus/p-cancelable
https://github.com/sindresorhus/responselike
https://github.com/sindresorhus/type-fest
https://github.com/sindresorhus/tagged-tag
https://github.com/max-mapper/extract-zip
https://github.com/sindresorhus/get-stream
https://github.com/Sec-ant/readable-stream
https://github.com/sindresorhus/is-stream
https://github.com/thejoshwolfe/yauzl
https://github.com/brianloveswords/buffer-crc32
https://github.com/andrewrk/node-pend
https://github.com/i18next/i18next
https://github.com/babel/babel
https://github.com/microsoft/TypeScript
https://github.com/lezer-parser
https://github.com/lucide-icons/lucide
https://github.com/mathjax/MathJax
https://github.com/mermaid-js/mermaid
https://github.com/moment/moment
https://github.com/mozilla/pdf.js
https://github.com/pixijs/pixijs
https://github.com/mapbox/earcut
https://github.com/primus/eventemitter3
https://github.com/matt-way/gifuct-js
https://github.com/matt-way/jsBinarySchemaParser
https://github.com/kaimallea/isMobile
https://github.com/browserslist/caniuse-lite
https://github.com/jkroso/parse-svg-path
https://github.com/avoidwork/tiny-lru
https://github.com/PrismJS/prism/
https://github.com/mourner/rbush
https://github.com/mourner/quickselect
https://github.com/remarkjs/remark
https://github.com/hakimel/reveal.js
https://github.com/barrysteyn/node-scrypt
https://github.com/nodejs/nan
https://github.com/mixmark-io/turndown
https://github.com/mixmark-io/domino
https://github.com/webpack/webpack
https://github.com/acornjs/acorn
https://github.com/nicolo-ribaudo/acorn-import-phases
https://github.com/browserslist/browserslist
https://github.com/web-platform-dx/baseline-browser-mapping
https://github.com/kilian/electron-to-chromium
https://github.com/chicoxyzzy/node-releases
https://github.com/browserslist/update-db
https://github.com/lukeed/escalade
https://github.com/alexeyraspopov/picocolors
https://github.com/samccone/chrome-trace-event
https://github.com/webpack/enhanced-resolve
https://github.com/isaacs/node-graceful-fs
https://github.com/webpack/tapable
https://github.com/guybedford/es-module-lexer
https://github.com/eslint/js
https://github.com/browserify/events
https://github.com/fitzgen/glob-to-regexp
https://github.com/isaacs/node-graceful-fs
https://github.com/npm/json-parse-even-better-errors
https://github.com/webpack/loader-runner
https://github.com/jshttp/mime-types
https://github.com/jshttp/mime-db
https://github.com/suguru03/neo-async
https://github.com/webpack/schema-utils
https://github.com/ajv-validator/ajv
https://github.com/epoberezkin/fast-deep-equal
https://github.com/fastify/fast-uri
https://github.com/epoberezkin/json-schema-traverse
https://github.com/floatdrop/require-from-string
https://github.com/ajv-validator/ajv-formats
https://github.com/ajv-validator/ajv-keywords
https://github.com/DefinitelyTyped/DefinitelyTyped
https://github.com/webpack-contrib/terser-webpack-plugin
https://github.com/jridgewell/sourcemaps
https://github.com/jestjs/jest
https://github.com/yahoo/serialize-javascript
https://github.com/browserify/randombytes
https://github.com/terser/terser
https://github.com/tj/commander.js
https://github.com/evanw/node-source-map-support
https://github.com/LinusU/buffer-from
https://github.com/mozilla/source-map
https://github.com/webpack/watchpack
https://github.com/webpack/webpack-sources
https://github.com/eemeli/yaml
system2|5 months ago
eviks|5 months ago
gchamonlive|5 months ago
hexo|5 months ago
Unbelievable
lyu07282|5 months ago
Eslint with such wonderful dependencies like is-glob smh
brandonspark|5 months ago
mpalmer|5 months ago
bergheim|5 months ago
Whataboutism. Relative comparisons don't address absolute risk. I checked three random packages: prism pulls 22, remark pulls 51, pixijs 179! So that's 250+ transitive dependencies just from those.
> Features like Bases and Canvas were implemented from scratch instead of importing off-the-shelf libraries. This gives us full control over what runs in Obsidian.
Full control? There are still hundreds of dependencies.
> This approach keeps our dependency graph shallow with few sub-dependencies. A smaller surface area lowers the chance of a malicious update slipping through.
Really? Again, this is just one package: https://npmgraph.js.org/?q=pixijs
> The other packages help us build the app and never ship to users, e.g. esbuild or eslint.
Build tools like esbuild don't ship to users, but a compromised build tool can still inject malicious code during compilation. This is supply chain security 101.
> All dependencies are strictly version-pinned and committed with a lockfile
Version pinning is, I would hope, standard practice in any professional development team years and years ago. It prevents accidental updates but doesn't stop compromised existing versions.
> When we do dependency updates, we: > [snip]
While these practices are better than nothing, they don't fundamentally address the core issue.
> That gap acts as an early-warning window: the community and security researchers often detect malicious versions quickly
According to whom? Heartbleed, a vulnerability in a package with far more scrutiny than a typical npm module took what, 2 years to be found? The "community detection" assumption is flawed.
I'm not trying to put Obsidian down here - I sympathize, aside from implementing everything themselves, what can they do! I'm trying to point out that while their intent is good, this is a serious problem and their solution is not a solution.
Of course, it's the same in any project with dependencies. It's the same in other languages as well - if they have a convenient package manager. Like Rust and Cargo.
This problem came with the convenience of package managers and it should be fixed there, not by every application like Obsidian. I'm not sure how but maybe once a package is starting to become popular, additional security measures must be put in place for the author to be able to continue to commit to it. Signing requirements, reproducible builds, 2fa, community reputation systems, who knows.
Individual applications can't solve supply chain security through wishful thinking and version pinning.
Package managers need to solve this at the infrastructure level through measures like mandatory code signing, automated security auditing, dependency isolation, or similar system level approaches.
Obsidian's practices are reasonable given the current tooling limitations, but they don't eliminate the fundamental risks that the package managers bring to modern dependency ecosystems.
arigatoarigato|5 months ago
[deleted]
unknown|5 months ago
[deleted]
saltserv|5 months ago
[deleted]
Mikhail_K|5 months ago
[deleted]
j-krieger|5 months ago
kid64|5 months ago
What a horribly disingenuous statement, for a product that isn't remotely usable without 3rd-party plugins. The "Obsidian" product would be more aptly named "Mass Data Exfiltration Facilitator Pro".
freddie_mercury|5 months ago
It is possible to make your same point without histrionic excess.
gkbrk|5 months ago
That's not even remotely true. Obsidian out-of-the-box is very usable, covers pretty much all use cases for a note-taking software.
I've been using it for ages, and I haven't needed to turn on the Community Plugins switch for anything.
Usually the people I see with tons of Obsidian plugins are people who think "just one more plugin" is what stands between them and productivity.
themadturk|5 months ago
scuff3d|5 months ago
elric|5 months ago
OhMeadhbh|5 months ago
If it's a browser, they should have something on their web site that says "obsidian is a really cool browser." I think there are a lot of people out there who are ignoring the hype-train and it would do the community a service if they just started with answering that simple question. I mean sure, I get it, it's a "sharpen your thinking app," but I'm not sure what that means.
smodo|5 months ago