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

31–40 of 274 posts

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

#31

Post by myvoiceismypass »

zargon wrote: post #22
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.

I use “Templater” and “Dataview” but now I am rethinking my usage; they were required for the daily template I use (found here on HN) but this is probably overkill.

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

#32

Post by da_chicken »

kjkjadksj wrote: post #28
Scramblejams wrote: post #17

Earlier quoted context omitted.

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.

That's why I run Windows 7. It's going to be insecure anyways so what's the big deal?

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

#33

Post by 0cf8612b2e1e »

jabbany wrote: post #27
0cf8612b2e1e wrote: post #19

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.

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.

I would have thought, but it has been how many years, and as far as I know, there is still no segregation for VSCode extensions. Microsoft has all the money and if they cannot be bothered, not encouraged that smaller applications will be able to iron out the details.

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

#34

Post by jabbany »

gjsman-1000 wrote: post #25
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.

Operating systems are different though, since their whole purpose is to host _other_ applications.

FWIW, MacOS isn't any better or worse for security than any other desktop OS tbh....

I mean, MacOS just had it's "UAC" rollout not that long ago... and not sure about you, but I've encountered many times where someone had to hang up a Zoom or browser call because they updated the app or OS, and had to re-grant screenshare permissions or something. So, not that different. (Pre-"UAC" versions of MacOS didn't do any sandboxing when it came to user files / device access)

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

#35

Post by codazoda »

CuriouslyC wrote: post #18
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?

Not a huge electron fan (thank god for tauri), but Obsidian is a fantastic app and you shouldn't let the electron put you off of it. You can even hook a MCP up to it and an agent can use it as a personal knowledge base, it's quite handy.

> Thank god for tauri

I’d love to try it, but speaking of security, this was the first thing I saw:

sh https://create.tauri.app/sh)

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

#36

Post by schmichael »

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.

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 their part, and one that I wish drew more ire.

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

#37

Post by Scramblejams »

cosmic_cheese wrote: post #20
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...

The real answer is to minimize dependencies (and subdependencies) to the greatest extent practical. In some cases you can get by with surprisingly few without too much pain (and in the long run, maybe less pain than if you'd pulled in more).

Yep, and for the rest I've gotten a lot of mileage, when shipping server apps, by deploying on Debian or Ubuntu* and trying to limit my dependencies to those shipped by the distro (not snap). The distro security team worries about keeping my dependencies patched and I'm not forced to take new versions until I have to upgrade to the next OS version, which could be quite a long time.

It's a great way to keep lifecycle costs down and devops QoL up, especially for smaller shops.

*Insert favorite distro here that backports security fixes to stable package versions for a long period of time.

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

#38

Post by scuff3d »

This doesn't make any sense to me. I've always been told you don't write anything yourself unless you absolutely have to and having a million micro-dependencies is a good thing. JavaScript and now Rust devs have been saying this for years. Surely they know what they're doing...

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

#39

Post by jabbany »

0cf8612b2e1e wrote: post #33
jabbany wrote: post #27

Earlier quoted context omitted.

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.

I would have thought, but it has been how many years, and as far as I know, there is still no segregation for VSCode extensions. Microsoft has all the money and if they cannot be bothered, not encouraged that smaller applications will be able to iron out the details.

I think it's just because supply-chain attacks are not common enough / their attack surfaces not large enough to be worth the dev time... yet...

Sneak in a malicious browser extension that breaks the permissions sandbox, and you have hundreds of thousands to millions of users as an attack surface.

Make a malicious VSCode/IDE extension and maybe you hit some hundreds or thousands of devs, a couple of smaller companies, and probably can get on some infosec blogs...

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

#40

Post by cgriswald »

myvoiceismypass wrote: post #31
zargon wrote: post #22

Earlier quoted context omitted.

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

I use “Templater” and “Dataview” but now I am rethinking my usage; they were required for the daily template I use (found here on HN) but this is probably overkill.

I did too but have switched over to “bases” now that that’s in core. Before that I had an apparmor profile restricting Obsidian from reaching the web.
Post reply on HN