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

91–100 of 274 posts

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

#91

Post by eviks »

da_chicken wrote: post #43
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?

No, it's not really an issue. GitHub and VS Code are also Electron apps. So are Slack and Discord. Postman is, as well. I'd also be forced to ask... what exactly are you doing with a markdown note-taking application such that performance is a legitimate concern? But, I mean, maybe you're reading this in a Lynx session on your ThinkPad 701C.

> what exactly are you doing with a markdown note-taking application such that performance is a legitimate concern?

Launching it and expecting a fast startup.

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

#92

Post by esseph »

ibash wrote: post #87
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. 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.

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.

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

#93

Post by flanbiscuit »

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…

I believe it's about waiting a bit before a new patch is released, not fully avoiding installing updates. Seems like compromises are being caught quickly these days, usually within hours. There are multiple companies monitoring npm package releases because they sell security scanning products and so it's part of their business to be on top of it.

pnpm has a setting that you can tell it that a package needs to be at least X minutes old in order to install it. I would wait at least 24 hours just to be safe

https://pnpm.io/settings#minimumreleaseage

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

#94

Post by dtkav »

netghost wrote: post #88
dtkav wrote: post #26

Earlier quoted context omitted.

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.

Just out of curiosity, what's the plugin? Are there folks interested in paying for plugins?

The plugin is called Relay [0] -- it makes Obsidian more useful in a work setting by adding real-time collaboration.

One thing that makes our offering unique is the ability to self-host your Relay Server so that your docs are completely private (we can't read them). At the same time you can use our global identity system / control plane to collaborate with anyone in the world.

We have pretty solid growth, a healthy paid consumer base (a lot of students and D&D/TTRPG), and starting to get more traction with businesses and enterprise.

[0] https://relay.md

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

#95

Post by xenator »

To be honest, right now I'm thinking about isolating of build process for frontend on my local environment. It is seems not hard to send my local environment variables like OPENAI_API_KEY or .ssh/* to some remote machine.

I know it is not very different comparing to python or projects in any other language. But I don't feel that I cannot trust node/js community at this point.

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

#96

Post by dehugger »

marcosdumay wrote: post #67
zer00eyz wrote: post #64

Earlier quoted context omitted.

> If engineers can't even manage their own security, why are we expecting users to do so? This latest attack hit Crowdstrike as well. Imagine they had gotten inside Huntress, who opened up about how much they can abuse the access given: https://news.ycombinator.com/item?id=45183589 Security folks and companies think they are important. The C suite sees them as a scape goat WHEN the shit hits the fan and most end user…

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

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

#97

Post by hinkley »

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

When I was young there were a few luminaries in the software world who talked about how there is a steady if small flow of ideas from video game design into conventional software.

But I haven't heard anyone talk like that in quite sometime (unless it's me parroting them). Which is quite unfortunate.

I think for example if someone from the old guard of Blizzard were to write a book or at least a novella that described how the plugin system for World of Warcraft functioned, particularly during the first ten years, where it broke, how they hardened it over time, and how the process worked of backporting features from plugins into the core library...

I think that would be a substantial net benefit to the greater software community.

Far too many ecosystems make ham-fisted, half-assed, hair-brained plugin systems. And the vast majority can be consistently described by at least two of the three.

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

#98

Post by RadiozRadioz »

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…

There's a key missing piece to this puzzle: being informed about _why_ you're updating and what the patches are.

Nobody has time to read source code, but there are many tools and services that will tell you brief summaries of release notes. Npm Audit lists security vulnerabilities in your package versions for example.

I do adopt the strategy of not updating unless required, as updates are not only an attack vector, but also an extremely common source of bugs that'd I'd prefer to avoid.

But importantly I stay in the loop about what exploits I'm vulnerable to. Packages are popping up with vulnerabilities constantly, but if it's a ReDoS vulnerability in part of the package I definitely don't use or pass user input to? I'm happy to leave that alone with a notice. If it's something I'm worried another package might use unsafely, with knowledge of the vulnerability I can decide how important it is, and if I need to update immediately, or if I can (preferably) wait some time for the patch to cook in the wild.

That is the important thing to remember about security in this context: it is an active, continuous, process. It's something that needs to be tuned to the risk tolerance and risk appetite of your organisation, rather than a blanket "never update" or "always update" - for a well-formed security stance, one needs more information than that.

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

#99

Post by pipes »

esseph wrote: post #92
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.

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.

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

#100

Post by darkamaul »

> 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, it feels like an odd tradeoff. I don’t have hard data, but I’d wager we see far more vulnerabilities patched through regular updates than actual supply-chain compromises. Delaying or blocking updates in general tends to increase your exposure rather than reduce it.

Post reply on HN