Less is safer: Reducing the risk of supply chain attacks • Hacker News Board

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

#191

Post by gkbrk » Sat, Sep 20, 2025, 12:23 PM UTC

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

> a product that isn't remotely usable without 3rd-party plugins

That's not even remotely true. Obsidian out-of-the-box is very usable, covers pretty much all use cases for a note-taking software.

I've been using it for ages, and I haven't needed to turn on the Community Plugins switch for anything.

Usually the people I see with tons of Obsidian plugins are people who think "just one more plugin" is what stands between them and productivity.

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

#192

Post by mcgrath_sh » Sat, Sep 20, 2025, 12:27 PM UTC

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'm shocked it is most of your software. I think I have under a dozen AUR packages. It has been that way for about a decade. I added a couple for gaming recently (mostly because Lutris just crashes for me), but nearly all of my software comes from the official repos.

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

#193

Post by doodlesdev » Sat, Sep 20, 2025, 12:30 PM UTC

   > Only a handful of packages are part of the app you run, e.g. Electron, CodeMirror, moment.js.

So they ship an extremely bloated package to ship a WebView based on one of the most complex pieces of software ever written, an entire code editor for text editing, and a deprecated time library that could be substituted by newer APIs and some glue code?

Honestly, it doesn't seem impressive at all. What Obsidian does is the bare minimum of how we should manage packages in any piece of software, not a testament to a serious security policy. They do security audits, though, which I find to be a good practice.

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

#194

Post by TomaszZielinski » Sat, Sep 20, 2025, 12:35 PM UTC

formerly_proven wrote: post #117

HSO wrote: post #101

Earlier quoted context omitted.

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

Little snitch can block open(2)?

I treat LS as a privacy/anti-telemetry/anti-accident tool, not as anti malware.

Obviously it can detect malware if there’s a connection to some weird site, but it’s more like a bonus than a reliable test.

If you need to block FS access, then per app containers or VMs are the way to go. The container/VM sandboxes your files, and Little Snitch can then manage externa connectivity (you might still want to allow connection to some legit domains—-but maybe not github.com as that can be use to upload your data. I meant something like updates.someapp.com)

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

#195

Post by TomaszZielinski » Sat, Sep 20, 2025, 12:38 PM UTC

HSO wrote: post #188

lxgr wrote: post #170

Earlier quoted context omitted.

If it can open and write any file on the OS, it's pretty much game over. Too many ways to exfiltrate data even without network/socket access.

Worse, what keeps this from editing the config files for Little Snitch (or similar blockers)?

I believe LS has some protections against this. Never tried them, but there are config related security options, incl. protection against synthetic events. So they definitely put some thought into that.

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

#196

Post by CuriouslyC » Sat, Sep 20, 2025, 12:45 PM UTC

skydhash wrote: post #184

edoceo wrote: post #78

Earlier quoted context omitted.

Right. But you know how to fetch and inspect (yea?) so, I with you that piping random crap to sh is bad. Maybe these snips encourage that behavior. Tauri is trustable (for some loose definition) and the pipe to shell is just a well known happy-path. All that to say it's a low value smell test. Also, I'm in the camp that would rather git clone and then docker up. My understanding is it gives me a littl more sandbox.

I think I would prefer to see official supports for major package managers, even with unofficial repos (Debian, Macports,...). We went from a time where software were usually tarballed to one where devs are encouraging piping to shell.

https://snapcraft.io/obsidian

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

#197

Post by TomaszZielinski » Sat, Sep 20, 2025, 12:46 PM UTC

s_ting765 wrote: post #156

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.

You're wrong. The obsidian flatpak ships by default with access to /home. https://github.com/flathub/md.obsidian.Obsidian/blob/5e594a4...

I „love” such sandboxing defaults. Apps like Docker Desktop also share the whole home by default [1], which is pretty interesting if a big selling point is to keep stuff separated. No idea why node_packages need to have access to my tax returns :). Of course you can change that, but I bet many users keeps the default paths intact.

[1] https://docs.docker.com/desktop/settings-and-maintenance/set...

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

#198

Post by [deleted] » Sat, Sep 20, 2025, 12:47 PM UTC

joshdavham wrote: post #85

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

[deleted]

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

#199

Post by TomaszZielinski » Sat, Sep 20, 2025, 12:53 PM UTC

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

My personal take is that the only way to be reasonably sure you're OK is to install as few apps as possible and then as few plugins as possible (and ideally stick to the bundled ones only). I don’t think it’s controversial, but for some reason this is not how many people think, even if in the real world you don’t give keys to your place to everyone who says they’re cool :)

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

#200

Post by mnahkies » Sat, Sep 20, 2025, 12:54 PM UTC

darkamaul wrote: post #100

> We do not run postinstall scripts. This prevents packages from executing arbitrary code during installation. I get the intent, but I’m not sure this really buys much. If a package is compromised, the whole thing is already untrustworthy and skipping postinstall doesn’t suddenly make the rest of the code safe. If it isn’t compromised, then you risk breaking legitimate installation steps. From a security perspective,…

I agree but there's a bit of nuance here. Today scanning steps typically happen post install, which is wild but the status quo. Therefore preventing anything from running during install is desirable.

I'd like to see the ability to scan/restrict as part of the installation step become popular, there are some proprietary tools that do this already but it's not yet a common capability.