Sécurité de RunAlexDB

État

RunAlexDB est en développement actif et n’a pas encore fait l’objet d’un audit de sécurité humain externe. Il n’est pas non plus encore public. Tant qu’un audit externe n’a pas eu lieu, RunAlexDB n’est pas recommandé pour des déploiements en production traitant du trafic sensible.

Ce qui a été fait

RunAlexDB est passé par plusieurs cycles de revue de sécurité interne et adversariale assistée par IA, couvrant la correction MVCC/concurrence, la durabilité et la crash-safety du WAL, la réplication et la HA (réplication semi-synchrone, commit à deux phases, élection de leader et fencing par bail), et la surface réseau/authentification/injection. Chaque finding de ces cycles est suivi avec une sévérité et un statut explicites — corrigé, accepté, ouvert, ou contesté — jamais abandonné en silence. Exemples concrets de ce que ce processus a effectivement détecté et corrigé : un contournement d’autorisation sur un chemin de code général, des prepared statements qui n’atteignaient pas le WAL, une vérification de self-fencing manquante lors d’une élection de leader pair-à-pair, une perte de durabilité silencieuse durant la finalisation d’un commit à deux phases, et une collision d’AUTO_INCREMENT sous la concurrence à granularité ligne. La re-vérification d’un correctif se fait dans une session ou un modèle différent de celui qui l’a produit.

Vérifier une release

Signée de la même façon que Runbound, avec la même clé :

minisign -Vm runalexdb-x86_64-linux-gnu -P RWSBM9HzDiZpfCD82uTnkeP1Ui30LfWE96C8EtFyI4/WVyLAVxpLzYy/
minisign -Vm SHA256SUMS -P RWSBM9HzDiZpfCD82uTnkeP1Ui30LfWE96C8EtFyI4/WVyLAVxpLzYy/
sha256sum -c SHA256SUMS --ignore-missing

Signaler une vulnérabilité

Écrivez à security@runasm.com avec les détails et, si possible, une reproduction, plutôt que d’ouvrir une issue publique en premier.