Maybe, just maybe, don't give fullmouthed advice on reducing risk in the supply chain.
Less is safer: Reducing the risk of supply chain attacks
51–60 of 274 posts
Re: Less is safer: Reducing the risk of supply chain attacks
#52This 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.
Re: Less is safer: Reducing the risk of supply chain attacks
#53This 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. And how exactly you can solve that? I don't want to press 'allow access' on the every file some plugin is accessing.
Re: Less is safer: Reducing the risk of supply chain attacks
#54This 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,…
Re: Less is safer: Reducing the risk of supply chain attacks
#55Earlier 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.
> Gaming is the only area where I expect plugins have limited permissions. Do you mean mods on Steam? If you do, then that's down to the individual game. Sandboxing mods isn't universal.
Re: Less is safer: Reducing the risk of supply chain attacks
#56This 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,…
If engineers can't even manage their own security, why are we expecting users to do so?
Re: Less is safer: Reducing the risk of supply chain attacks
#57What 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".
Re: Less is safer: Reducing the risk of supply chain attacks
#58Earlier quoted context omitted.
All code is fundamentally not ever secure.
This statement is one of those useless exercises in pedantry like when people say "well technically coffee is a drug too, so..." Code with publicly-known weaknesses poses exponentially more danger than code with unknown weaknesses. It's like telling sysadmins to not waste time installing security patches because there are likely still vulnerabilities in the application. Great way to get n-day'd into a ransomware paym…
Re: Less is safer: Reducing the risk of supply chain attacks
#59'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".
It is possible to make your same point without histrionic excess.
Re: Less is safer: Reducing the risk of supply chain attacks
#60Earlier 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.
Conversely, barring a bug in the runtime or compiler, higher level languages don't enable those kinds of shenanigans.
See for example the heart bleed bug, where openssl would read memory it didn't own when given a properly malformed request.