Sécurité

Les éléments sont des instructions et du code qui s'exécutent sur les machines des développeurs, avec leurs permissions; la revue est donc la frontière : rien en dehors d'un espace de travail personnel n'est publié tant qu'un modérateur, admin de l'espace de travail ou root qui n'en est pas l'auteur ne l'a pas approuvé, et root qui approuve son propre travail est enregistré comme une dérogation (override). Les signaux de risque (hooks, serveurs MCP, politiques de permissions, lignes d'état, exécutables, scripts shell, adresses réseau) montrent aux réviseurs ce qu'il faut lire de près; ils ne bloquent jamais. Les skills, les commandes et les agents sont du texte qui peut tout de même demander à un outil d'IA d'exécuter des commandes, et aucun signal ne repère chaque ligne de ce genre : c'est le réviseur qui les lit.

• Installer n'exécute rien. rmk écrit des fichiers et vérifie le sha256 de chaque téléchargement par rapport au registre et à rmk.lock; c'est l'outil d'IA qui exécute ce qui est écrit.
• Où sont les secrets. Le fichier de réglages contient AUTH_SECRET, qui signe les témoins (cookies) de connexion, et DATABASE_URL, avec le mot de passe de la base de données; l'installation l'écrit lisible seulement par son propriétaire. Les jetons d'accès sont stockés sous forme de hachages, les mots de passe avec argon2. Quiconque lit le fichier de réglages peut se connecter sous l'identité de n'importe qui jusqu'à ce que le secret soit remplacé (plus bas).
• La connexion. Cinq tentatives par minute par courriel; avec la connexion à deux facteurs, un code tiré d'une application après le mot de passe, que root peut exiger des réviseurs ou de tout le monde (Réglages). Un mot de passe seul n'obtient aucun jeton rmk pour un compte qui a la connexion à deux facteurs. Ses secrets sont chiffrés avec une clé tirée d'AUTH_SECRET, le seul secret : le serveur refuse de démarrer tant que BETTER_AUTH_SECRETS est défini.
• Fournisseurs d'identité. Seul root les configure, et chacun est testé avant de pouvoir être activé. Leurs secrets client sont chiffrés avec une clé tirée d'AUTH_SECRET, liée au fournisseur, et ne sont plus jamais affichés. Chaque connexion vérifie la signature du fournisseur sur sa réponse, que la réponse appartient à cette connexion et que le courriel est vérifié; un émetteur doit être en https://. Ronne ne connecte les gens que par ses propres routes : la bibliothèque de connexion ne répond à rien d'autre venant du navigateur. Root peut toujours se connecter avec un mot de passe, et disable-sso désactive tous les fournisseurs (Verrouillage et fournisseurs en panne).
• Ce que Ronne ne chiffre pas. La base de données, les éléments stockés et les sauvegardes sont aussi sûrs que le disque et le serveur de base de données où ils se trouvent : chiffrez-les là où vous les exploitez.
• Privé ne veut pas dire chiffré. Un espace de travail privé est invisible partout pour les non-membres, mais root voit tous les espaces de travail, et quiconque exploite le serveur peut tout lire (Public et privé).

Le modèle de menaces passe en revue chaque frontière : qui pourrait l'attaquer, ce qui arrête chaque menace, et les lacunes connues avec ce qui les comblera. Pour signaler une vulnérabilité dans Ronne lui-même, suivez la politique de sécurité : en privé, jamais dans un ticket public. Seule la dernière version reçoit des correctifs (Mettre à jour).

Ronne ne chiffre pas ses propres fichiers : la plateforme le fait mieux, et une clé dans l'application serait un secret de plus à perdre.

• Le disque du serveur pour SQLite, les éléments stockés et les sauvegardes : LUKS sous Linux, FileVault sous macOS, ou les volumes chiffrés de votre fournisseur cloud.
• Celui de la base pour PostgreSQL et MySQL : le chiffrement du service géré, ou le disque du serveur de base de données.
• Les archives qui quittent la machine : backup --encrypt (AES-256-GCM, avec une clé tirée de votre phrase secrète).