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

131–140 of 274 posts

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

#131

Post by anon7000 »

fa3556 wrote: post #120
eek2121 wrote: post #56

Earlier quoted context omitted.

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 think this criticism is unfair because most common packages are covered by the core and extra repos which are maintained by Arch Linux. AUR is a collection of user build scripts and using it has a certain skill cliff such that I expect most users to have explicit knowledge of the security dangers. I understand your concern but it would be weird and out of scope for Arch to maintain or moderate AUR when what Arch is…

Disagree. AUR isn’t any trickier than using pacman most of the time. Install a package manager like Yay or Paru and you basically use it the same way as the default package manager.

It’s still the same problem, relying on the community and trusted popular plugin developers to maintain their own security effectively.

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

#132

Post by LilBytes »

RadiozRadioz wrote: post #98
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, b…

Exactly. If you can avoid having to do _any_ patches except those that have a security purpose you've already reduced your risk to supply chain attacks considerably.

This isn't trivial to organise though since semver by it's self doesn't denote when a patch is security related or not. Of course, you can always review the release notes but this is time consuming, and doesn't scale well when a product grows either in size of code base or community support.

This is where there's a fairly natural place for SAST (E.g., Semgrep, Snyk (many more but these are the two I've used the most, in no particular order)), and supply chain scans fall in place, but they're prohibitively expensive.

There is a lot of open source tooling out there that can achieve the same too of course.

I've found there's a considerable linear climb with overheads/TOIL and the larger the number of open source tools you commit to create a security baseline. Unfortunately, this realistically means most companies where time is scarcer than money, means more money shifts into closed source products like those I listed, rather than those ran by open source products/companies.

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

#133

Post by setr »

hinkley wrote: post #97
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…

I’ve been of the opinion that every hard problem in CS shows up somewhere in gamedev. It’s a great space for inspo.

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

#134

Post by anon7000 »

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

Earlier quoted context omitted.

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…

The time has come. The nx supply chain attack a couple weeks ago literally exfiltrated admin tokens from your local dev machine because the VS code extension for nx always downloaded the latest version of nx from npm. And since nx is a monoreop tool, it’s more applicable to larger projects with more valuable tokens to steal.

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

#135

Post by system7rocks »

anon7000 wrote: post #5
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?

JavaScript is a very secure language. The browser is a massive success at running secure JavaScript on a global scale. Every website you use is running JavaScript and not able to read other site data. Electron is the same, running v8 to sandbox JavaScript. Assuming you aren't executing user input inside that sandbox (something many programming languages allow, including JS), it's very secure. The problem with supply…

I need more evidence to believe this.

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

#136

Post by dotancohen »

johnisgood wrote: post #123
elric wrote: post #119

Earlier quoted context omitted.

Or firejail. Or QubesOS using a dedicated VM. There are options, but it would still be nice if Obsidian had a more robust security model.

I have been using firejail for most of these kind of applications, be it Obsidian, Discord, or the browser I am using. I definitely recommend people start using it.

Sell it to us! Why do you use specifically firejail?

There are so many options, from so many different security perspectives, that analysis paralysis is a real issue.

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

#137

Post by dotancohen »

dehugger wrote: post #96
marcosdumay wrote: post #67

Earlier quoted context omitted.

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

Because that would be a distraction to the point they're actually making.

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

#138

Post by anon7000 »

asgraham wrote: post #12
anon7000 wrote: post #5

Earlier quoted context omitted.

JavaScript is a very secure language. The browser is a massive success at running secure JavaScript on a global scale. Every website you use is running JavaScript and not able to read other site data. Electron is the same, running v8 to sandbox JavaScript. Assuming you aren't executing user input inside that sandbox (something many programming languages allow, including JS), it's very secure. The problem with supply…

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 mean, JavaScript doesn’t even have APIs for reading a file from disk, let alone executing an arbitrary binary. (Anything similar comes from a runtime like NodeJS.) You can’t access memory in different JS processes… so what would make it insecure?

To be fair, a plugin system built on JS with all plugins interacting in the same JS context as the main app has some big risks. Anything plugin can change definitions and variable in the global scope with some restrictions. But any language where you execute untrusted code in the same context/memory/etc as trusted code has risks. the only solution is sandboxing plugins

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

#139

Post by pjmlp »

hinkley wrote: post #97
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…

I came to learn that even though in process plugins are easier to implement, and less resource demanding, anyone serious about host stability and security can only allow for plugins based on OS IPC.

And in general, it will take less hardware resources that the usual Electron stuff.

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

#140

Post by antoniojtorres »

varenc wrote: post #62
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,…

Another thought: what about severely sandboxing plugins so they while they have access to your notes, they have no network or disk access and in general lack anyway for them to exfiltrate your sensitive info? Might not be practical but approaches like this appeal to me.

Deno would be a good candidate for this.
Post reply on HN