Trend-Themen
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Weniger ist sicherer: wie Obsidian das Risiko von Angriffen auf die Lieferkette reduziert
Angriffe auf die Lieferkette sind bösartige Updates, die sich in den Open-Source-Code einschleichen, der von vielen Apps verwendet wird. So gestalten wir Obsidian, um sicherzustellen, dass die App eine sichere und private Umgebung für Ihre Gedanken ist.
Weniger ist sicherer
Es mag offensichtlich erscheinen, aber der Hauptweg, wie wir das Risiko von Angriffen auf die Lieferkette reduzieren, besteht darin, die Abhängigkeit von Drittanbieter-Code zu vermeiden. Obsidian hat im Vergleich zu anderen Apps in unserer Kategorie eine geringe Anzahl von Abhängigkeiten. Siehe eine Liste der Open-Source-Bibliotheken auf unserer Credits-Seite.
Funktionen wie Bases und Canvas wurden von Grund auf neu implementiert, anstatt vorgefertigte Bibliotheken zu importieren. Dies gibt uns die volle Kontrolle darüber, was in Obsidian läuft.
- Für kleine Hilfsfunktionen implementieren wir sie fast immer neu in unserem Code.
- Für mittlere Module forken wir sie und behalten sie in unserem Code, wenn die Lizenzen es erlauben.
- Für große Bibliotheken wie pdf.js, Mermaid und MathJax fügen wir bekannte, versionierte Dateien hinzu und aktualisieren nur gelegentlich oder wenn Sicherheitsupdates verfügbar sind. Wir lesen die Versionshinweise, betrachten die Änderungen im Upstream und testen gründlich, bevor wir wechseln.
Dieser Ansatz hält unser Abhängigkeitsdiagramm flach mit wenigen Unterabhängigkeiten. Eine kleinere Angriffsfläche verringert die Wahrscheinlichkeit, dass ein bösartiges Update durchrutscht.
Was tatsächlich in der App enthalten ist
Nur eine Handvoll Pakete sind Teil der App, die Sie ausführen, z.B. Electron, CodeMirror, moment.js. Die anderen Pakete helfen uns, die App zu erstellen und werden niemals an die Benutzer ausgeliefert, z.B. esbuild oder eslint.
Versionssperrung und Lockfiles
Alle Abhängigkeiten sind streng versioniert und mit einem Lockfile festgelegt. Das Lockfile ist die Quelle der Wahrheit für Builds, sodass wir deterministische Installationen erhalten. Dies gibt uns eine klare Prüfspur, wenn wir Änderungen überprüfen.
Wir führen keine Postinstall-Skripte aus. Dies verhindert, dass Pakete während der Installation beliebigen Code ausführen.
Langsame, überlegte Upgrades
Wenn wir Abhängigkeitsupdates durchführen, tun wir Folgendes:
...

Top
Ranking
Favoriten