On the Issue of Trust With Open-Source, and the Fallacy of Security through Code Review.
Background
This is a continuation of my thoughts regarding trust relationships and risk mitigation, spurred by a recent observation. I have previously stated my reasoning behind minimizing trust relationships by minimizing the software stack, in an effort to minimize risk and maintenance while increasing stability.
Obsidian as a platform
An architecture designed to support the notion of plugins is a beautiful framework for extending functionality of the baseline product. The company limits the workload to the baseline product, while the community may extend the product in ways as yet undiscovered. And yet, while I appreciate the open-source community, I use no third-party plugins with Obsidian because it is against my trust philosophy. Obsidian recognizes the potential for risk, by making the user take an explicit action to enable third-party plugins.
The Observation
A shout-out of Thank You to @nickmilo for the LYT Kit. It’s a great resource for organizational ideas and provides a lot of information for consideration. Upon opening the LYT Kit vault, Obsidian dutifully warned me that third-party plugins are disabled, and asked if I wanted to enable them. For the time being, the answer was No; let’s see what’s going on to see if I can extend a trust relationship to these plugins and receive the full benefit.
My God…It’s Full of Stars…
I started by wanting to review the source code. To be perfectly clear, I went to the LYT vault and issued the following command:
find .obsidian/plugins -type f -exec wc -l {} \; | awk ‘{s += $1} END { print s }’
90415
Yes, the few plugins included with the LYT kit constitute over ninety thousand lines of code. I’ve designed an entire CM system that amounted to 6000-8000 lines of Java. At this point, I could start a dissertation on the failure that is modern computing, such as it is, that it requires one to be so loquacious just to get a computer to do a few things, but I’ll stick to the topic at hand. I have neither the time nor the inclination to review 90k+ lines of source code. I’m sure the plugins do great things (just looking at the names) for the LYT Kit (again, thank-you @nickmilo !). While I believe the risk is low (I don’t truly believe that in this esoteric corner of the computing world, someone set out to spend so much time writing malware), I cannot practically ascertain the safety of the methods employed. I’ve seen sloppy methods create unintentionally dangerous situations, so off to an immutable VM goes the LYT Kit, so I can bask in the ideas that Nick so graciously provided the community.
Why This Rigor Doesn’t Apply to Obsidian
Because it’s commercial software. That doesn’t mean it’s perfect, but it does mean that there’s a financial incentive to do things right, and sloppy or dangerous practices represent an existential threat to the enterprise. No such incentive exists with open-source. And as the Bard would say, therein lies the rub. So you can choose to rely on a beautiful open-source pebble that ultimately will be washed down the development stream to oblivion, or enjoy the commerical, safe boulder that is Obsidian. Stay proprietary, and stay strong.