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

111–120 of 274 posts

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

#111

Post by esseph »

pipes wrote: post #99
esseph wrote: post #92

Earlier quoted context omitted.

If you're using a flatpak, that's not actually the case. It would have very restricted access to the point where you even would have to explicitly give it access to user /home.

So if I run their software in a container they can't access my entire filesystem. I don't think that is a security feature. It sounds like if I ever run obsidian I should be using flat seal too.

Er, what?

I'm not claiming it's a security feature of Obsidian, I'm saying it's a consequence of running a flatpak - and in this situation it could be advantageous for those interested.

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

#112

Post by Alive-in-2025 »

dehugger wrote: post #96
marcosdumay wrote: post #67

Earlier quoted context omitted.

> It's not that engineers cant take care of their own security. I dunno. My computer has at least 1 hardware backdoor that I know off, but that I just can't get hardware without any equivalent exploit. My OS is developed with a set of tools that is known to make code revision about as hard as possible. Provides the bare minimum application insulation. And is 2 orders of magnitude larger than any single person can rea…

You never actually told us what your OS is.

They must mean macos, right?

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

#113

Post by Capricorn2481 »

kid64 wrote: post #86
freddie_mercury wrote: post #59

Earlier quoted context omitted.

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.

I have to agree that I don't find plugins necessary, and I'm not sure why you're so down on people using a solid backlinking note taker. I don't think I have low standards, I think Roam and Logseq aren't that great and Obsidian is all I need.

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

#114

Post by thund »

hahn-kev wrote: post #107
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,…

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.

Plus vscode is maintained by a company with thousands of devs. Obsidian is less than 10 people, which is amazing. About plugins why blame the product, pls check what you install on your machine instead

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

#115

Post by shelled »

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

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.

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

#116

Post by otabdeveloper4 »

SilverSlash wrote: post #84
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.

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.

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

#117

Post by formerly_proven »

HSO wrote: post #101
ibash wrote: post #87

Earlier quoted context omitted.

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

What if you run little snitch and block any communications from obsidian to anything?

Little snitch can block open(2)?

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

#118

Post by bdzr »

hahn-kev wrote: post #107
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,…

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.

It's *significantly* worse than vscode. vscode is at least attempting to grapple the problem: https://code.visualstudio.com/docs/configure/extensions/exte....

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

#119

Post by elric »

HSO wrote: post #101
ibash wrote: post #87

Earlier quoted context omitted.

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

What if you run little snitch and block any communications from obsidian to anything?

Or firejail. Or QubesOS using a dedicated VM. There are options, but it would still be nice if Obsidian had a more robust security model.

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

#120

Post by fa3556 »

eek2121 wrote: post #56
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,…

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

I think this criticism is unfair because most common packages are covered by the core and extra repos which are maintained by Arch Linux. AUR is a collection of user build scripts and using it has a certain skill cliff such that I expect most users to have explicit knowledge of the security dangers. I understand your concern but it would be weird and out of scope for Arch to maintain or moderate AUR when what Arch is providing here amounts to little more than hosting. Instead Arch rightly gives the users tools to moderate it themselves through the votes and comments features. Also the most popular AUR packages are maintained by well known maintainers.

The derivatives are obviously completely separate from Arch and thus are not the responsibility of Arch maintainers.

Post reply on HN