[deleted]
Less is safer: Reducing the risk of supply chain attacks
61–70 of 274 posts
Re: Less is safer: Reducing the risk of supply chain attacks
#62This 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.
Re: Less is safer: Reducing the risk of supply chain attacks
#63Absolutely love Obsidian but had to stop using it because Electron apps don't play well with Wayland. After lots of tinkering around with flags and settings for compatibility layers, it became obvious that it would never work seamlessly like it did on Windows (and probably does on x11). So it was either give up Wayland compositors or give up Obsidian. Luckily I don't use any plugins, so moving to other software was easy, but I still would prefer Obsidian. Electron's "works everywhere" works about as good as Java's "works everywhere", which is to say it works great, until it doesn't, at which point it's a mess of tinkering.
If you use Wayland and it works for you, that's great, but it's not my experience.
Re: Less is safer: Reducing the risk of supply chain attacks
#64This 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…
> 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 users feel the same about security as they do about taking off their shoes at the airport (what is this nonsense for) and they mostly arent wrong.
It's not that engineers cant take care of their own security. It's that we have made it a fight with an octopus rather than something that is seamless and second nature. Furthermore security and privacy go hand and hand... Teaching users that is not to the benefit of a large portion of our industry.
Re: Less is safer: Reducing the risk of supply chain attacks
#65I also recommend using this site to evaluate the dependencies of your dependencies:
Re: Less is safer: Reducing the risk of supply chain attacks
#66Earlier 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 solution at my job is you can only install extensions vetted by IT and updates are significantly delayed. Works well enough but sucks if you want one that isn't available inside the firewall.
Re: Less is safer: Reducing the risk of supply chain attacks
#67Earlier 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…
> 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 read on their lifetime. It's also the usable OS out there with best security guarantees, everything else is much worse or useless.
A browser is almost a new complete layer above the OS. And it's 10 times larger. Also written in a way that famously makes revisions impossible.
And then there are the applications, that is what everybody is focusing today. Keeping them secure is close to useless if one don't fix all of the above.
Re: Less is safer: Reducing the risk of supply chain attacks
#68> The other packages help us build the app and never ship to users, e.g. esbuild or eslint.
Eslint with such wonderful dependencies like is-glob smh
Re: Less is safer: Reducing the risk of supply chain attacks
#69Yes, 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."
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...
No. "Always downloading random code and hoping" is not the only option. Even w/ the supply-chain shitshow that the public npmjs registry has become, using pnpm and a private registry makes it possible to leverage a frozen lockfile that represents the entire dependency graph and supports vulnerability-free reproducible builds.
EDIT to add: Of course, reaching a state where the whole graph is free of CVEs is a fleeting state of affairs. Staying reasonably up-to-date and using only scanned dependencies is an ongoing process that takes more effort and attention to detail than many projects are willing or able to apply; but it is possible.
Re: Less is safer: Reducing the risk of supply chain attacks
#70Earlier quoted context omitted.
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'm really curious about this comment. What would it mean for a programming language to be secure? Any two Turing-complete programming languages are equally secure, no? Surely the security can only ever come from whatever compiles/interprets it? You can run JavaScript on a piece of paper.
Turing completeness is irrelevant, as it only addresses computation. Security has to do with system access, not computational capacity. Brainfuck is Turing complete, but lacks any primitives to do more than read from a single input stream and write to a single output stream. Unless someone hooks those streams up to critical files, you can't use it to attack a system.
Language design actually has a lot of impact on security, because it defines what primitives you have available for interacting with the system. Do you have an arbitrary syscall primitive? Then the language is not going to help you write secure software. Is your only ability to interact with the system via capability objects that must be provided externally to authorize your access? Then you're probably using a language that put a lot of thought into security and will help out quite a lot.