This is beautiful; pure poetry: https://obsidian.md/blog/less-is-safer/

(Obsidian’s dependency-management philosophy.)

I have a suggestion: If you have a project or repo that's getting popular, stop writing features for a few months and implement this instead.

#softwaredevelopment #softwareengineering #0dependencies

@timbray

I do have to chuckle a bit when one of dependencies they list in their minimal, disciplined list is Electron — a behemoth of a black box with more complexity than some entire operating systems.

@inthehands true, but that is indeed a large library, and that means it will only be updated consciously.

/cc @timbray

@timbray “our vulnerabilities are all homegrown” ;D

@timbray

Exactly. IMHO this is how you do it!

They describe the base principles as:

- For small utility functions we almost always re-implement them in our code.

- For medium modules we fork them and keep them inside our codebase if the licenses allows it.

- For large libraries … we include known-good, version-locked files and only upgrade occasionally, or when security fixes land. We read release notes, look at upstream changes, and test thoroughly before switching.

@jackwilliambell @timbray I have a slight concern with the last point. Yes, projects should have a low number of dependencies, but maybe update them more often than occasionally?

What if there is some critical bug in a big dependency, but you haven't been updating it for a while. Do you skip your usual QA for it (which might break tests) to push the release quicker to your users?

@inthehands @timbray my first thought too, but if electron is compromised obsidian would not be among our primary concerns (esp. because according to this policy they would likely not update before the incident is noticed). So I think electron is more of an attack surface problem than a supply chain one.

@caspicat @jackwilliambell @timbray "only upgrade occasionally, *or when security fixes land*"

@buherator Yes. What I mean is that a security fix might land in the most recent versions of a dependency, which you can't easily update to, if you weren't updating more often. There might be too many breaking changes piled up.

@caspicat gotcha! That's an interesting Q that deserves more discussion for sure.

@buherator @timbray
Maybe? But if people are keeping sensitive data in their private Obsidian notebooks, exfiltration via a supply chain attack could be devastating.

@juandesant @timbray
I do agree to a large extent — or at least hope for it to be true! — but your sentiment suggests that •quality• of maintenance matters at least as much as the sheer •quantity• of dependencies.

@juandesant @timbray

This set me off on a long train of thought, which I didn’t want to jam in your mentions but in case you’re interested: https://hachyderm.io/@inthehands/115237749357270051

@inthehands
But all this keeps pushing the issue back onto humans, and ignoring that there are technical solutions we can and should be implementing.

POLA is a thing, and OCaps-type systems help us have our reuse cake along with our POLA confinement.

I don't find the Obsidian post "beautiful" or "pure poetry"; I view it as a symptom of broken tools.
@juandesant @timbray

@shriramk @juandesant @timbray
I’m out of my depth here, and know nothing about OCAP systems applied to software. Can you say more? (Are we talking about out-of-control action plans here? Or is OCaps something else and I’m even more out of my depth than I think?)

@inthehands
OCap = object capabilities
Probably the best place to learn more is to follow pointers from here:
http://www.erights.org/
@juandesant @timbray

@shriramk @inthehands @juandesant @timbray

Kate Sills’ evergreen article is a great place to start, IMO:

https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99

@neilmadden
Also @inthehands just pointed me to this:

https://justinpombrio.net/2021/12/26/preventing-log4j-with-capabilities.html

@juandesant @timbray

@shriramk thanks, I’d not seen that one.