Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Less is safer: Reducing the risk of supply chain attacks

obsidian.md

Post reply on HN
Print view View original

251–260 of 274 posts

Re: Less is safer: Reducing the risk of supply chain attacks

#251

Post by kepano »

gejose wrote: post #16

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,…

(CEO of Obsidian here)

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

Re: Less is safer: Reducing the risk of supply chain attacks

#252

Post by darthwalsh »

otabdeveloper4 wrote: post #116
SilverSlash wrote: post #84

Earlier quoted context omitted.

Javascript is a lot more secure than C++, since it's a memory managed language.

Buffer overflows are 0.001 percent of security incidents in practice. Let's fix private key leakage and supply chain issues before worrying about C++ haxxors p0wning your machines.

Memory management vulnerabilities are estimated to account for 70% of bugs.

As less code at trust boundaries is being written in memory-unsafe languages, we'll get to 0.001%!

Re: Less is safer: Reducing the risk of supply chain attacks

#253

Post by TomaszZielinski »

eli wrote: post #249
TomaszZielinski wrote: post #197

Earlier quoted context omitted.

I „love” such sandboxing defaults. Apps like Docker Desktop also share the whole home by default [1], which is pretty interesting if a big selling point is to keep stuff separated. No idea why node_packages need to have access to my tax returns :). Of course you can change that, but I bet many users keeps the default paths intact. [1] https://docs.docker.com/desktop/settings-and-maintenance/set...

Needed for volume mounting to work easily I assume.

Yeah, I forgot there’s the intermediate VM level, and user folders are shared there so that folders could be mounted to the individual containers using host paths.

Re: Less is safer: Reducing the risk of supply chain attacks

#254

Post by bobthebuilders »

deafpolygon wrote: post #246
cptnmrvl wrote: post #224

Earlier quoted context omitted.

How do I use Apple Notes cross-platform?

You can't. But that wasn't the point, was it? Point is, you don't need Obsidian (or all of its plugin). People have been making do with Dropbox and plain text (.txt) files perfectly fine for years.

Wow I never knew I "can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem".

This is why people use Obsidian.

Re: Less is safer: Reducing the risk of supply chain attacks

#255

Post by schmichael »

tlavoie wrote: post #125
schmichael wrote: post #36

Earlier quoted context omitted.

vim and emacs are over 30 years old and therefore living with an architecture created when most code was trusted. Encrypting network protocols was extremely rare, much less disks or secrets. I don't think anything about the security posture of vim and emacs should be emulated by modern software. I would say VSCode has no excuse. It's based on a browser which does have capabilities to limit extensions. Huge miss on th…

I'd love to see software adopt strong capabilities-based models that enforce boundaries even within parts of a program. That is, with the principle of least authority (POLA), code that you call is passed only the capabilities you wish (e.g. opening a file, or a network socket), and not everything that the current process has access to. Thomas Leonard's post ( https://roscidus.com/blog/blog/2023/04/26/lambda-capabilit…

Sadly capabilities are older than emacs. I’d welcome advancements here but their practical utility is clearly not a foregone conclusion.

Re: Less is safer: Reducing the risk of supply chain attacks

#256

Post by burnt-resistor »

chrisweekly wrote: post #69
lelandfe wrote: post #14

Earlier quoted context omitted.

Pinned dependencies usually have their own dependencies so you are generally always downloading random code and hoping. I mean, jeeze, how much code comes along for the ride with Electron...

No. "Always downloading random code and hoping" is not the only option. Even w/ the supply-chain shitshow that the public npmjs registry has become, using pnpm and a private registry makes it possible to leverage a frozen lockfile that represents the entire dependency graph and supports vulnerability-free reproducible builds. EDIT to add: Of course, reaching a state where the whole graph is free of CVEs is a fleeting…

This. It would be a partial improvement. A greater improvement would be rewriting it for native per platform, conscientiously sandboxing plugins, and minimizing the supported "js" language with a strict subset that doesn't allow arbitrary file, network, or system operations unless signed and approved entitlements are granted.

Re: Less is safer: Reducing the risk of supply chain attacks

#257

Post by burnt-resistor »

anon7000 wrote: post #5
system7rocks wrote: post #3

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…

> JavaScript is a very secure language.

I almost fell out of my chair laughing. Thanks for the comedic relief.

Re: Less is safer: Reducing the risk of supply chain attacks

#258

Post by burnt-resistor »

dghlsakjg wrote: post #9
system7rocks wrote: post #3

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 probably one of the most used, depending on how you measure it, languages on earth. 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?

Nit: "Earth" is the proper noun for the planet most of us live on, "earth" is dirt.

Re: Less is safer: Reducing the risk of supply chain attacks

#259

Post by themadturk »

kid64 wrote: post #57

'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.

Re: Less is safer: Reducing the risk of supply chain attacks

#260

Post by tlavoie »

schmichael wrote: post #255
tlavoie wrote: post #125

Earlier quoted context omitted.

I'd love to see software adopt strong capabilities-based models that enforce boundaries even within parts of a program. That is, with the principle of least authority (POLA), code that you call is passed only the capabilities you wish (e.g. opening a file, or a network socket), and not everything that the current process has access to. Thomas Leonard's post ( https://roscidus.com/blog/blog/2023/04/26/lambda-capabilit…

Sadly capabilities are older than emacs. I’d welcome advancements here but their practical utility is clearly not a foregone conclusion.

It seems to me that it's not their utility, but lack of support in general for the sorts of changes that enable its wider use. E.g., looks like it's getting practical use in FreeBSD: https://www.cl.cam.ac.uk/research/security/capsicum/freebsd....

Linux has seccomp, but I think that was changing the access for an entire process. The language-focused aspect seems useful to me, from that application aspect where maybe I want access to something, but I don't want to pass that access on to all the code that I might call from a library.

Post reply on HN