"The other packages help us build the app and never ship to users, e.g. esbuild or eslint."
Still, they can present a security risk by injecting malware at build time
Less is safer: Reducing the risk of supply chain attacks
121–130 of 274 posts
Re: Less is safer: Reducing the risk of supply chain attacks
#122This 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,…
I think it's a matter of time until we see a notable plugin in the obsidian space get caught exfiltrating data. I imagine then, after significant reputational harm, the team will start introducing safe guards. At a minimum, create some sort of verified publisher system.
Re: Less is safer: Reducing the risk of supply chain attacks
#123Earlier quoted context omitted.
What if you run little snitch and block any communications from obsidian to anything?
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.
Re: Less is safer: Reducing the risk of supply chain attacks
#124This 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…
Kernel design is (to me) another one where ideas have flowed into other software fields - there were monolithic kernels, micro kernels, and hybrid kernels, and they all need to work with third party modules (drivers)
The lessons from all fields seem to be relearnt again and again in new fields :-)
Re: Less is safer: Reducing the risk of supply chain attacks
#125Earlier 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.
vim and emacs are over 30 years old and therefore living with an architecture created when most code was trusted. Encrypting network protocols was extremely rare, much less disks or secrets. I don't think anything about the security posture of vim and emacs should be emulated by modern software. I would say VSCode has no excuse. It's based on a browser which does have capabilities to limit extensions. Huge miss on th…
I'd love to see software adopt strong capabilities-based models that enforce boundaries even within parts of a program. That is, with the principle of least authority (POLA), code that you call is passed only the capabilities you wish (e.g. opening a file, or a network socket), and not everything that the current process has access to. Thomas Leonard's post (https://roscidus.com/blog/blog/2023/04/26/lambda-capabilitie...) covers this in great detail, and OCaml's newer Eio effect system will has aspects of this too.
The Emily language (locked-down subset of OCaml) was also interesting for actively removing parts of the standard library to get rid of the escape hatches that would enable bypassing the controls.
Re: Less is safer: Reducing the risk of supply chain attacks
#126Earlier quoted context omitted.
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 p…
Are you worried about being sherlocked at all? I know "multiplayer" is on their official roadmap.
Re: Less is safer: Reducing the risk of supply chain attacks
#127This doesn't make any sense to me. I've always been told you don't write anything yourself unless you absolutely have to and having a million micro-dependencies is a good thing. JavaScript and now Rust devs have been saying this for years. Surely they know what they're doing...
There is a balance to be struck. NPM in particular has been a veritable dependency hell for a long time. I don't know if it just attracts inexperienced developers, or if its security model is fundamentally flawed, but there have been soooo many supply chain attacks using NPM that being extra careful is very much warranted.
Re: Less is safer: Reducing the risk of supply chain attacks
#128Earlier quoted context omitted.
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…
Kernel design is (to me) another one where ideas have flowed into other software fields - there were monolithic kernels, micro kernels, and hybrid kernels, and they all need to work with third party modules (drivers) The lessons from all fields seem to be relearnt again and again in new fields :-)
Because learning how to make a proper one requires building your own broken one first.
It might be slightly sped up by reading up on theory and past experiences of others.
I am around mid life and I see how I can tell people stuff, I can point people to resources but they still won’t learn until they hit the problem themselves and put their mind into figuring it out.
Re: Less is safer: Reducing the risk of supply chain attacks
#129Re: Less is safer: Reducing the risk of supply chain attacks
#130Going to preface this post by saying I use and love Obsidian, my entire life is effectively in an Obsidian vault, I pay for sync and as a user I'm extremely happy with it. But as a developer this post is nonsense and extremely predictable [1]. We can expect countless others like it that explains how their use of these broken tools is different and just don't worry about it! By their own linked Credits page there are…
To be fair, the electron project likely invests some resources in reviewing it's own dependencies, because of its scale. But yeah this is a good exercise, I think we need more systems like Yocto which prioritize complete understanding of the entire product from source.