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

81–90 of 274 posts

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

#81

Post by photon_garden »

brentm wrote: post #77

I've been using Roam Research since about 2020. Is Obsidian better?

Haven’t used Roam, but what I like about Obsidian:

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

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

#83

Post by neilv »

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.

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

#84

Post by SilverSlash »

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 lot more secure than C++, since it's a memory managed language.

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

#85

Post by joshdavham »

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?

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

#86

Post by kid64 »

freddie_mercury wrote: post #59
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".

I've used Obsidian for years without a single 3rd party plugin. It is possible to make your same point without histrionic excess.

Yeah, this is always the response. Usability can be assessed objectively, so you just have low standards.

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

#87

Post by ibash »

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

> Obsidian plugins have full, unrestricted access to all files in the vault.

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.

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

#88

Post by netghost »

dtkav wrote: post #26
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,…

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.

Just out of curiosity, what's the plugin? Are there folks interested in paying for plugins?

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

#90

Post by hsbauauvhabzb »

ibash wrote: post #87
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,…

> Obsidian plugins have full, unrestricted access to all files in the vault. 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.

To be fair, it’s no worse of a dumpsterfire than any other plug-in ecosystem.
Post reply on HN