Obsidian 1.9.13 (Early Access) ist jetzt für Catalyst-Mitglieder für Desktop und Mobilgeräte mit Fehlerbehebungen und Leistungsverbesserungen verfügbar.

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: 1. Lesen das Änderungsprotokoll der Abhängigkeit Zeile für Zeile. 2. Überprüfen die durch die neue Version eingeführten Unterabhängigkeiten. 3. Vergleichen den Upstream, wenn das Änderungsset groß oder riskant ist. 4. Führen automatisierte und manuelle Tests auf verschiedenen Plattformen und kritischen Benutzerpfaden durch. 5. Committen das neue Lockfile erst, nachdem diese Überprüfungen bestanden sind. In der Praxis aktualisieren wir Abhängigkeiten selten, da sie in der Regel funktionieren und keine häufigen Änderungen erfordern. Wenn wir es tun, behandeln wir jede Änderung, als ob wir eine neue Abhängigkeit hinzufügen würden. Zeit ist ein Puffer Wir drängen uns nicht zu Upgrades. Es gibt eine Verzögerung zwischen dem Upgrade einer Abhängigkeit und dem Pushen eines Releases. Diese Lücke fungiert als Frühwarnfenster: Die Community und Sicherheitsforscher erkennen bösartige Versionen oft schnell. Bis wir bereit sind, zu versenden, hat das Ökosystem in der Regel problematische Releases bereits markiert. — Keine einzelne Maßnahme kann das Risiko von Lieferkettenangriffen beseitigen. Aber die Wahl von weniger Abhängigkeiten, flachen Graphen, genauen Versionssperren, kein Postinstall und einem langsamen, überprüfungsintensiven Upgrade-Rhythmus machen Obsidian insgesamt viel weniger anfällig und geben uns ein langes Zeitfenster, um Probleme zu erkennen, bevor der Code die Benutzer erreicht. Wenn Sie neugierig auf unseren umfassenderen Ansatz zur Sicherheit sind, sehen Sie sich unsere Sicherheitsseite und frühere Audits an.

Die Belohnung wurde auf 5.000 $ erhöht