L’avenir des plugins Obsidian

• Obsidian Community est lancé comme un nouveau répertoire et un tableau de bord développeur pour les plugins et thèmes, unifiant les flux de soumission, de gestion, de découverte et d’utilisation
• Depuis la publication de l’API Obsidian en 2020, la communauté a créé plus de 4 000 plugins et thèmes, et les plugins ont dépassé 120 millions de téléchargements
• Le nouveau répertoire propose la navigation, la recherche, le filtrage et le tri, et affiche sur les pages de projet des captures d’écran, des informations détaillées et une fiche de score de sécurité
• Un système de revue automatisée s’applique à toutes les versions afin de vérifier le respect des politiques développeur, la qualité du code, ainsi que la présence de vulnérabilités connues et de potentiels malwares
• Les projets existants seront migrés vers le nouveau système, et les plugins ou thèmes ne respectant pas les critères les plus récents seront temporairement exemptés avant d’être progressivement retirés du répertoire officiel

---

Lancement d’Obsidian Community

• Obsidian Community est lancé comme un nouveau répertoire et un tableau de bord développeur pour les plugins et thèmes Obsidian
• Depuis la publication de l’API Obsidian en 2020, la communauté a créé plus de 4 000 plugins et thèmes, et les plugins Obsidian totalisent plus de 120 millions de téléchargements
• L’objectif est de permettre à tout le monde de créer, distribuer, découvrir et utiliser des plugins et des thèmes plus facilement et en toute sécurité
• Ce lancement marque le début d’un plan plus large qui introduit en même temps le site Community, le tableau de bord développeur, la revue automatisée, la sécurité des plugins et des outils pour les équipes

Site Community et tableau de bord développeur

• Le nouveau site Community propose la navigation, la recherche, le filtrage et le tri pour explorer les plugins et les thèmes
• Les plugins peuvent être trouvés via des dizaines de catégories comme Integrations, Bases, Charts et bien d’autres catégories
• Les projets peuvent être triés par nom, nombre de téléchargements, popularité, date de publication et date de mise à jour
• Chaque page de détail de projet inclut des captures d’écran, des informations détaillées et une fiche de score de sécurité
• Les plugins payants et les intégrations officielles affichent de nouveaux labels
• Les auteurs peuvent ajouter à leur page de profil des options de soutien, un lien vers leur site web et des liens vers leurs réseaux sociaux
• Le site Obsidian Community fournit un nouveau tableau de bord développeur permettant aux auteurs de soumettre, gérer et suivre l’état de leurs projets
• Tous les plugins, thèmes et soumissions en attente qui étaient auparavant ajoutés via GitHub sont automatiquement migrés vers le nouveau site
• Pour revendiquer la propriété d’un projet existant, il faut se connecter au site Community et lier son compte GitHub
• Une fois le compte GitHub lié, il est possible de gérer les projets existants, soumettre de nouveaux projets et modifier sa page de profil

Revue automatisée et sécurité

• Une revue automatisée est introduite pour tous les projets de la communauté
• Le nouveau système de revue automatisée analyse non seulement la soumission initiale, mais aussi toutes les versions selon des critères de sécurité et de qualité du code
• Jusqu’ici, une petite équipe examinait manuellement les premières soumissions pour vérifier leur conformité aux Developer Policies, mais avec la popularité croissante d’Obsidian, il est devenu difficile de suivre le rythme des soumissions, et les versions suivantes n’étaient pas relues
• Avec les agents de codage qui accélèrent la création de plugins, la file d’attente des revues s’est encore allongée, tandis que des outils comme Obsidian CLI rendent la création de plugins plus facile
• Lorsqu’un plugin ou un thème est soumis, le système de revue automatisée vérifie le respect des politiques développeur, les bonnes pratiques du code source et l’absence de vulnérabilités connues
• Comme les tests automatisés peuvent être continuellement améliorés, cela fournit une base pour renforcer de manière plus globale la qualité et la sécurité de l’écosystème Obsidian
• La revue manuelle continue. Le nouveau système permet de concentrer les efforts sur les plugins qui nécessitent un examen plus approfondi, comme les plugins populaires, les plugins recommandés ou ceux signalés par la communauté
• Les plugins et thèmes existants ont été réexaminés dans le nouveau système, ce qui a permis d’identifier d’anciens plugins et thèmes qui ne respectent plus les directives les plus récentes
• Les projets existants qui ne passent pas les critères actuels bénéficieront d’une exemption temporaire, mais tous les plugins et thèmes qui ne passent pas la nouvelle procédure de revue finiront par être progressivement retirés du répertoire officiel
• Le nouveau système a traité plus de 2 300 soumissions en attente au cours des derniers jours, et les développeurs qui attendaient la revue de leur plugin peuvent se connecter au site Community pour vérifier leur statut actuel

• Analyse automatisée

  • Toutes les versions sont automatiquement vérifiées pour la qualité du code et les vulnérabilités de sécurité
  • Cela inclut aussi une analyse anti-malware visant à détecter d’éventuels ajouts malveillants dans les plugins
  • Les développeurs peuvent voir, dans le tableau de bord développeur, les suggestions détaillées, avertissements et indicateurs d’échec pour chaque projet

• Fiche de score

  • Les utilisateurs et les développeurs peuvent consulter l’état des contrôles automatisés dans la fiche de score de chaque projet
  • La fiche de score continuera d’être améliorée en intégrant des informations publiques, des labels de confidentialité, des attestations d’artefacts, les résultats de la revue manuelle et l’adoption de fonctionnalités de l’application

• Divulgation du périmètre d’accès

  • Au cours des prochains mois, la transparence sur les plugins et leurs auteurs va encore augmenter
  • Les plugins devront déclarer à quoi ils accèdent, comme le réseau, le système de fichiers, le presse-papiers et d’autres fonctions
  • Les utilisateurs pourront consulter ces informations avant d’installer un plugin

• Auteurs vérifiés

  • Un label sera ajouté pour les développeurs de confiance qui passent des étapes de vérification supplémentaires et conservent un bon statut
  • Les utilisateurs peuvent à tout moment signaler directement un problème de sécurité à l’équipe Obsidian

Évolutions pour les équipes et au niveau de l’application

• Les équipes utilisant Obsidian peuvent déjà déployer des contrôles de sécurité destinés aux utilisateurs
• Au cours des prochains mois, les équipes pourront gérer plus facilement les plugins communautaires autorisés et distribuer des plugins privés à leurs membres
• Les équipes qui distribuent des plugins Obsidian officiels peuvent demander le badge Official du répertoire Community
• Si un plugin est éligible, il est possible de prendre contact
• En parallèle des améliorations du répertoire Community et du système de revue automatisée, l’application Obsidian et son API recevront aussi des changements visant à renforcer la découvrabilité et la sécurité
• L’écosystème communautaire est l’un des aspects à la fois amusants et puissants d’Obsidian, et l’objectif est de lui fournir les fondations nécessaires pour continuer à grandir
• Des retours seront recueillis sur le nouveau site Obsidian Community

Principaux changements pour les utilisateurs et les développeurs

• Impact pour les utilisateurs

  • Les plugins et thèmes peuvent être explorés sur le nouveau site Community
  • Les délais de revue étant fortement réduits, il pourrait y avoir moins de cas où des plugins en accès anticipé doivent être installés manuellement

• Soumettre un nouveau plugin ou thème

  • Il faut se connecter au site Community pour accéder au nouveau tableau de bord développeur
  • Il faut lier son compte GitHub, choisir le dépôt à soumettre, puis suivre les étapes indiquées dans le tableau de bord
  • La revue du projet commence immédiatement après la soumission, et les résultats sont généralement visibles en quelques minutes
  • Si le projet est validé, il pourra être recherché et téléchargé dans l’application sous 24 heures

• Revendiquer la propriété de plugins et thèmes existants

  • Il faut se connecter au site Community pour accéder au nouveau tableau de bord développeur
  • Une fois le compte GitHub lié, il est possible de revendiquer la propriété du plugin et de mettre à jour son titre, sa description et ses captures d’écran

• Peut-on mettre à jour sans tableau de bord développeur ?

  • Il reste possible de publier de nouvelles versions via GitHub
  • Les nouvelles versions sont automatiquement relues, et si elles échouent à la revue, il faut consulter les détails dans le tableau de bord développeur

• Plugins et thèmes qui échouent à la revue automatisée

  • Les nouveaux plugins et thèmes doivent passer la revue automatisée avant d’être ajoutés au répertoire et rendus découvrables
  • Chaque nouvelle version est analysée, et si elle échoue à la revue, elle est retirée de la recherche sous 24 heures
  • Les plugins et thèmes déjà approuvés pourront continuer à être utilisés pendant un certain temps, même s’ils échouent à la revue automatisée
  • Les anciens plugins devront eux aussi finir par respecter les nouveaux critères, mais aucune échéance n’est encore fixée, et la transition sera définie avec les développeurs de la communauté

• Exécuter la revue automatisée sans soumettre de release

  • Le eslint plugin permet de vérifier localement un plugin Obsidian par rapport aux directives officielles pour les développeurs
  • Le tableau de bord développeur permet d’exécuter une analyse de prévisualisation sur n’importe quelle branche, tag ou commit

• Co-mainteneurs et dépôts d’organisation

  • Actuellement, dans Obsidian Community, seul le propriétaire du dépôt GitHub peut modifier le projet correspondant
  • Les dépôts d’organisation peuvent être revendiqués et modifiés si l’appartenance à l’organisation est publique
  • La prise en charge de plusieurs collaborateurs sera ajoutée dans un futur proche

• Plugins en source fermée

  • Pour l’instant, les nouveaux plugins en source fermée ne sont pas acceptés dans le répertoire
  • Les plugins en source fermée déjà existants peuvent continuer à être utilisés jusqu’à nouvelle annonce
  • À l’avenir, il sera envisagé d’adapter le nouveau système de revue aux plugins en source fermée

• Exigences de compte et GitHub

  • Un compte Obsidian est nécessaire pour accéder au nouveau tableau de bord développeur
  • Pour l’instant, l’usage de GitHub est requis, mais l’ajout d’autres plateformes d’hébergement logiciel pourra être envisagé plus tard
  • La connexion GitHub partage le nom d’utilisateur et la liste des dépôts publics, et ces informations servent uniquement à vérifier la propriété des dépôts

• Labels Paid et Optional payments

  • Obsidian Community n’est pas une boutique et ne fournit pas de solution de paiement intégrée
  • Les développeurs peuvent continuer à utiliser des mécanismes de paiement externes, comme des clés de licence, des clés API ou des accès conditionnés par connexion
  • Les développeurs doivent catégoriser correctement leurs plugins dans l’une des trois catégories
  • Free désigne un plugin sans aucune forme de paiement et sans lien avec un service payant, les liens de don et de soutien restant autorisés
  • Optional payments désigne le cas où l’utilisateur peut payer de manière optionnelle pour débloquer des fonctions supplémentaires, ou lorsque le plugin se connecte à un service payant
  • Si un plugin se connecte à un service ou une API payants, il doit être marqué Optional payments, même si ce service propose un niveau gratuit
  • Paid désigne le cas où l’utilisateur doit obligatoirement payer pour utiliser les fonctionnalités principales, même si un essai gratuit est proposé
  • Ces labels n’indiquent pas si le développeur collecte des paiements, mais quel type de paiement l’utilisateur doit s’attendre à rencontrer

• Erreurs dans la fiche de score et contact

  • La fiche de score étant une nouvelle fonctionnalité, elle peut contenir des erreurs, ainsi que des faux positifs ou des faux négatifs
  • Si un contenu inexact est repéré, il faut contacter le canal #plugin-dev sur le serveur Discord d’Obsidian
  • En cas de question ou de préoccupation, il est aussi possible de contacter le canal #plugin-dev sur le serveur Discord d’Obsidian

[GN⁺]

Avis sur Hacker News

• Je suis le CEO d’Obsidian. Nous travaillons depuis près d’un an au lancement du nouveau site Community et du système d’avis, et même si cette première version m’enthousiasme beaucoup, il reste encore beaucoup à améliorer
  J’ai essayé d’être aussi exhaustif que possible, du billet de blog à la FAQ en passant par les prochaines étapes de la feuille de route, mais j’ai sûrement laissé des zones d’ombre, donc n’hésitez pas à poser des questions
  Avec une équipe de seulement 7 personnes devant gérer des milliers de développeurs de plugins et des millions d’utilisateurs, il a été très difficile d’équilibrer des priorités parfois contradictoires
  Le nouveau système devait être facile à adopter, préserver la rétrocompatibilité, améliorer nettement l’ancien fonctionnement sans casser complètement les flux de travail existants, tout en permettant d’augmenter progressivement la sécurité et la découvrabilité des plugins
  J’aimerais que cela soit vu comme un travail encore en cours ; nous continuerons à écouter les idées et les critiques, puis à itérer
  • J’ai déjà ajouté des plugins à plusieurs projets, et j’ai déjà envisagé d’introduire une structure où le projet signalerait qu’une version donnée a été révisée et jugée fiable
    Une des raisons de mon hésitation, au-delà du temps colossal à investir, c’est la crainte qu’une fois les gens devenus dépendants de ce processus de revue, si un code malveillant obfusqué passait malgré tout, la responsabilité d’une attaque ultérieure retombe sur le projet
    Je serais curieux de savoir comment vous voyez ce point
    Pour moi, cela ressemble à la différence entre le modèle Debian/Ubuntu, qui examine rigoureusement tout ce qui entre dans le dépôt, et le modèle PyPI/npm, qui ne garantit aucune revue
  • J’aime le fait que, dans les informations publiques, lorsqu’on clique sur « le plugin peut faire des requêtes vers 1 domaine externe », on voie le vrai domaine, github.com
    On peut voir un exemple ici : https://community.obsidian.md/plugins/zotlit
  • Je me demande si le système de scan automatique signale l’extension du périmètre des permissions ou les changements d’accès à des domaines réseau pour une revue interne/humaine
    Par exemple, si un plugin de résumé IA commence par accéder à url="api.openai.com"+path avec une clé OpenAI fournie par l’utilisateur, ce sera un cas très courant, et j’ai hâte de voir ce que la communauté va construire là-dessus
    Mais après une mise à jour, si l’utilisateur peut choisir n’importe quel endpoint compatible OpenAI, comment garantir qu’une telle flexibilité ne sert pas à créer un canal d’exfiltration réseau contournant le scan, et qu’il ne s’agit pas d’une mise à jour qui préremplit discrètement un endpoint malveillant ?
  • L’équipe Obsidian a fait un excellent travail. Je compte rester utilisateur d’Obsidian Sync, et j’espère pouvoir utiliser les plugins communautaires avec plus de sérénité
  • Enfin
    Quand j’ai essayé Obsidian, j’ai vu que la fonctionnalité de tableaux de données n’était pas intégrée de base mais fournie par un plugin disposant d’un accès total, et je l’ai désinstallé immédiatement
    Cela dit, je suis surpris que l’équipe ne compte que 7 personnes
• Pour ceux qui ne connaissent pas bien la situation, jusqu’à présent il était presque impossible, en pratique, de soumettre de nouveaux plugins à cause de la revue manuelle. Le fait que l’IA rende l’écriture de plugins plus simple et plus ludique a aussi joué
  La frustration montait dans la communauté des développeurs, et l’équipe commençait à plier sous la charge
  Donc bravo à l’équipe. C’est un énorme goulot d’étranglement de scalabilité qui saute, et c’est assez formidable de les voir construire cela puis le faire monter en charge
  • Vous avez des plugins particulièrement bons à recommander ? Je viens de quitter OneNote et, après avoir aussi configuré la synchro, je commence seulement à être à l’aise
• Je n’utilise pas Obsidian, mais en voyant le titre, j’ai d’abord cru qu’il s’agissait de limiter les plugins à un petit nombre approuvé par l’entreprise
  Quand une société de logiciels publie un titre du genre « l’avenir de XYZ », on s’attend souvent à ce que cela annonce de fortes restrictions sur XYZ, voire sa mise en extinction
  • Je me demandais à quel moment apparaîtrait l’enshittification
• Je ne suis pas convaincu qu’un contrôle automatique puisse déterminer de façon fiable si un plugin est malveillant
  À mon avis, la meilleure, voire la seule vraie manière de traiter la sécurité des plugins, c’est un sandbox avec une API explicite et un système de permissions
  • En plus de « il faut un sandbox avec une API explicite et un système de permissions », j’ajouterais qu’il faut surtout empêcher l’accès à mes données personnelles. Le problème, c’est que l’intérêt même des plugins Obsidian repose sur la lecture et l’écriture des documents
    Cela dit, s’ils ne peuvent pas communiquer avec Internet, cela ne semble plus être un si gros problème
    En regardant davantage, il semble qu’en raison de l’architecture JavaScript et Electron, les plugins Obsidian soient simplement des blocs de JavaScript exécutés dans l’espace global, capables de lire et d’écrire l’ensemble du système de fichiers dans les limites des permissions de l’utilisateur, ainsi que d’émettre des requêtes HTTP ; quelqu’un peut-il confirmer ?
  • Cela n’empêchera évidemment pas le code malveillant en lui-même, mais cela peut être très utile pour vérifier si les dépendances sont à jour et si elles contiennent des CVE connues, dans un esprit proche de ce que fait Trivy ou de ce que met en avant Artifacthub
    Je me demande toutefois dans quelle mesure cela fonctionnera réellement dans cet écosystème. D’expérience, les scans généralisés produisent assez facilement des faux positifs, c’est-à-dire des CVE présentes mais non applicables au contexte réel d’utilisation
    Il faut donc des connaissances pour interpréter correctement les résultats, ce qui peut devenir une charge importante pour les mainteneurs
  • Il suffit de lire le billet de blog. En plus du scan automatique et des contrôles destinés à l’équipe, un système de permissions est aussi prévu
    Les permissions seules ne suffisent pas à empêcher certains comportements malveillants, donc il faut l’ensemble
    Il suffit de regarder quelques tableaux de score sur le site Community pour voir rapidement que certains avertissements ne peuvent être traités ni par un système de permissions ni par du sandboxing
    Le billet de blog donne aussi les détails du mode de déploiement, et comme cela nécessitera des changements dans l’API des plugins, ce sera introduit progressivement
  • Bien sûr, ce ne sera pas compatible avec les plugins existants ; j’imagine donc une séparation entre plugins legacy et nouveaux plugins, avec beaucoup de friction pour installer les plugins legacy, puis leur abandon à terme
  • Podman/Linux a aussi une API et un système de permissions, et pourtant il y a eu Copy Fail : https://garrido.io/notes/podman-rootless-containers-copy-fai...
    La sécurité et la gestion des permissions sont tout simplement difficiles, et quand on conçoit une plateforme, il faut à un moment se demander si le gain de flexibilité vaut le risque
    Concevoir un système parfaitement sûr est une cause perdue
• Très intéressant. C’est une preuve concrète, dans le monde réel, qu’une revue automatique de plugins est possible même avec une petite équipe
  Il faudra que j’apprenne un jour à mettre en place un système similaire dans mon propre projet
  • Il vaudrait peut-être mieux observer comment cela évolue avant de se lancer. C’est un jeu du chat et de la souris, et ici les souris sont bien plus intelligentes
    Les fuites de données se produisent en silence
• Du point de vue d’un consommateur, je ne vois pas comment ni pourquoi je devrais consulter le tableau de score
  S’il y a une longue liste d’erreurs et d’avertissements du linter, qu’est-ce que je suis censé en faire ?
  Je me demande quel est le parcours idéal côté utilisateur. Le tableau de score semble très bien du point de vue développeur
• Ravi de voir arriver ce type de mise à jour
  Gérer ce genre de contributions communautaires est difficile, et cela ressemble à une avancée majeure
• Cela me paraît bien, tant que la disponibilité des plugins ne diminue pas, en particulier selfhosted-livesync dans mon cas
  Je me demande aussi s’il pourrait y avoir un rôle pour l’IA dans ce genre de revue automatique. Cela ressemble à un cas d’usage assez prometteur
• Très sympa. Dommage, en revanche, que le site soit réservé au mode sombre, ce qui le rend juste plus difficile à lire pour les personnes astigmates
  • Le mode lecture de Firefox affiche en un clic du texte sombre sur fond blanc. Les autres navigateurs ont probablement une fonction similaire
  • C’est parce qu’Obsidian est noir. Mais il est prévu d’ajouter un mode clair dans un futur proche
  • Cela veut dire une forme d’astigmatisme très rare ? J’ai de l’astigmatisme depuis plus de 30 ans, mais je peux lire ce site parfaitement, sans aucun effort
• J’aimerais qu’il soit plus simple d’installer des plugins en local. Cela devrait vraiment se limiter à copier-coller un dossier
  Si Obsidian n’était pas un logiciel propriétaire, je l’aurais modifié moi-même
  Il est temps que quelqu’un crée un clone compatible
  • C’est déjà exactement comme ça que cela fonctionne. Un plugin n’est qu’un dossier qu’on peut copier dans .obsidian/plugins à l’intérieur du vault
  • Littéralement, il suffit de le coller dans le répertoire .obsidian/plugins/