Live data from Hacker News

Less is safer: Reducing the risk of supply chain attacks

obsidian.md

51–60 of 274 posts

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

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

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

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

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.

Perhaps, but I think what you might put onto Obsidian (personal thoughts, journal entries etc) can be more sensitive than code.

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

#53
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. And how exactly you can solve that? I don't want to press 'allow access' on the every file some plugin is accessing.

Specific permissions declared in a manifest much like browser extensions could be a good first step.

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

#54
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 open letter seems relevant here: https://www.emilebangma.com/Writings/Blog/An-open-letter-to-...

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

#55
post #44

Earlier quoted context omitted.

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.

> Gaming is the only area where I expect plugins have limited permissions. Do you mean mods on Steam? If you do, then that's down to the individual game. Sandboxing mods isn't universal.

I was thinking more Lua/Luaua which make it trivial to restrict permissions. In general, the gaming client has access to a lot more information than it shares, so to prevent cheats from plugins, the developers have to be explicit about security boundaries.

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

#56
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 are we expecting users to do so?

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

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

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

#58
post #42

Earlier quoted context omitted.

All code is fundamentally not ever secure.

This statement is one of those useless exercises in pedantry like when people say "well technically coffee is a drug too, so..." Code with publicly-known weaknesses poses exponentially more danger than code with unknown weaknesses. It's like telling sysadmins to not waste time installing security patches because there are likely still vulnerabilities in the application. Great way to get n-day'd into a ransomware paym…

Have you spent time reviewing the security patches for any nontrivial application recently? 90% of them are worthless, the 10% that are actually useful are pretty easy to spot. It's not as big of a deal as people would like to have you think.

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

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

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

#60
post #47

Earlier quoted context omitted.

Doesn’t this mean browser sandboxing is secure, not JS? Or are you referring to some specific aspect of JS I’m not aware of? (I’m not aware of a lot of JS) It’s maybe a nit-pick, since most JS is run sandboxed, so it’s sort of equivalent. But it was explicitly what GP asked for. Would it be more accurate to say Electron is secure, not JS?

I'm really curious about this comment. What would it mean for a programming language to be secure? Any two Turing-complete programming languages are equally secure, no? Surely the security can only ever come from whatever compiles/interprets it? You can run JavaScript on a piece of paper.

A number of operating system security features, such as ASLR, exist because low level languages allow reading and writing memory that they didn't create.

Conversely, barring a bug in the runtime or compiler, higher level languages don't enable those kinds of shenanigans.

See for example the heart bleed bug, where openssl would read memory it didn't own when given a properly malformed request.

Post reply on HN