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

21–30 of 274 posts

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

#21

Post by dsissitka »

doesnt_know wrote: post #13

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…

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.

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

#22

Post by zargon »

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

That's ok. I haven't come across an Obsidian plug-in that's worth introducing a dependency for.

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

#23

Post by schmichael »

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

The Simpsons Springfield Nuclear Plant Security scene in real life.

https://www.youtube.com/watch?v=eU2Or5rCN_Y

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

#24

Post by justsomehnguy »

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.

And how exactly you can solve that?

I don't want to press 'allow access' on the every file some plugin is accessing.

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

#25

Post by gjsman-1000 »

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

That just sounds like Linux packages; also not a system known for security of desktop apps and scripts especially compared to MacOS, shoot me.

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

#26

Post by dtkav »

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.

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

#27

Post by jabbany »

0cf8612b2e1e wrote: post #19
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,…

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.

Browser extensions also have a relatively robust permissions-based system.

If they wanted to, one would guess that browser-ish local apps based on stuff like Electron/node-webkit could probably figure out some way to limit extension permissions more granularly.

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

#28

Post by kjkjadksj »

Scramblejams wrote: post #17
montroser wrote: post #7

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.

All code is fundamentally not ever secure.

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

#29

Post by mpalmer »

brandonspark wrote: post #10
mpalmer wrote: post #4

Earlier quoted context omitted.

"Secure" is a different, harder promise than safeR.

but still along the same lines as "safer". the stresses are different, "safer" has the stress as "SAY-fer" and "secure" has the stress as "sih-KYOOR". the latter sounds more similar (and rhymes better) with "more", the originator of the phrase "less is more"

Well uh sure if meter's all you're going for here

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

#30

Post by schmichael »

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

One of the large dependencies they call out is an excellent example: pdf.js.

There is no reason for pdf.js to ever access anything other than the files you wish to export. The Export to PDF process could spawn a containerized subprocess with 0 filesystem or network access and constrained cpu and memory limits. Files could sent to the Export process over stdin, and the resulting PDF could be streamed back over stdout with stderr used for logging.

There are lots of plugin systems that work this way. I wish it were commodofied and universally available. AFAIK there's very little cross-platform tooling to help you solve this problem easily, and that's a pity.

Post reply on HN