Obsidian 1.9.13 (accès anticipé) est maintenant disponible pour les membres Catalyst sur desktop et mobile avec des corrections de bugs et des améliorations de performance.

Moins c'est plus sûr : comment Obsidian réduit le risque d'attaques de la chaîne d'approvisionnement Les attaques de la chaîne d'approvisionnement sont des mises à jour malveillantes qui s'introduisent dans le code open source utilisé par de nombreuses applications. Voici comment nous concevons Obsidian pour garantir que l'application est un environnement sécurisé et privé pour vos pensées. Moins c'est plus sûr Cela peut sembler évident, mais le principal moyen de réduire le risque d'attaques de la chaîne d'approvisionnement est d'éviter de dépendre de code tiers. Obsidian a un faible nombre de dépendances par rapport à d'autres applications de notre catégorie. Consultez une liste de bibliothèques open source sur notre page de crédits. Des fonctionnalités comme Bases et Canvas ont été mises en œuvre de zéro au lieu d'importer des bibliothèques toutes faites. Cela nous donne un contrôle total sur ce qui fonctionne dans Obsidian. - Pour les petites fonctions utilitaires, nous les réimplémentons presque toujours dans notre code. - Pour les modules moyens, nous les forçons et les gardons dans notre code si les licences le permettent. - Pour les grandes bibliothèques comme pdf.js, Mermaid et MathJax, nous incluons des fichiers connus et verrouillés par version et ne les mettons à jour que de temps en temps, ou lorsque des corrections de sécurité sont disponibles. Nous lisons les notes de version, examinons les changements en amont et testons minutieusement avant de changer. Cette approche maintient notre graphique de dépendance peu profond avec peu de sous-dépendances. Une surface plus petite réduit la chance qu'une mise à jour malveillante passe à travers. Ce qui est réellement inclus dans l'application Seule une poignée de paquets fait partie de l'application que vous exécutez, par exemple Electron, CodeMirror, moment.js. Les autres paquets nous aident à construire l'application et ne sont jamais expédiés aux utilisateurs, par exemple esbuild ou eslint. Verrouillage des versions et fichiers de verrouillage Toutes les dépendances sont strictement verrouillées par version et engagées avec un fichier de verrouillage. Le fichier de verrouillage est la source de vérité pour les constructions, ce qui nous permet d'obtenir des installations déterministes. Cela nous donne une piste d'audit simple lors de l'examen des changements. Nous n'exécutons pas de scripts post-installation. Cela empêche les paquets d'exécuter du code arbitraire lors de l'installation. Mises à jour lentes et délibérées Lorsque nous effectuons des mises à jour de dépendances, nous : 1. Lisons le changelog de la dépendance ligne par ligne. 2. Vérifions les sous-dépendances introduites par la nouvelle version. 3. Différons en amont lorsque l'ensemble de changements est important ou risqué. 4. Exécutons des tests automatisés et manuels sur différentes plateformes et chemins utilisateurs critiques. 5. Engageons le nouveau fichier de verrouillage uniquement après que ces examens soient passés. En pratique, nous mettons rarement à jour les dépendances car elles fonctionnent généralement et ne nécessitent pas de changements fréquents. Lorsque nous le faisons, nous traitons chaque changement comme si nous prenions une nouvelle dépendance. Le temps est un tampon Nous ne précipitons pas les mises à jour. Il y a un délai entre la mise à jour de toute dépendance et le lancement d'une version. Cet écart agit comme une fenêtre d'alerte précoce : la communauté et les chercheurs en sécurité détectent souvent rapidement les versions malveillantes. Au moment où nous sommes prêts à expédier, l'écosystème a généralement signalé toute version problématique. — Aucune mesure unique ne peut éliminer le risque de la chaîne d'approvisionnement. Mais choisir moins de dépendances, des graphiques peu profonds, des verrouillages de version exacts, pas de post-installation, et un rythme de mise à jour lent et axé sur la révision ensemble rendent Obsidian beaucoup moins susceptible d'être impacté, et nous donnent une longue fenêtre pour détecter les problèmes avant que le code n'atteigne les utilisateurs. Si vous êtes curieux de notre approche plus large en matière de sécurité, consultez notre page de sécurité et les audits passés.

Récompense augmentée à 5 000 $