Radicle 1.7 : mises à jour de la plateforme Git P2P

# # Radicle 1.7 : Améliorations clés dans la plateforme P2P pour le développement décentralisé

Le 18 mars 2026, la version 1.7 de la plateforme P2P Radicle a été publiée — une alternative décentralisée à GitHub et GitLab. La plateforme fonctionne sans serveurs centraux, exploite les ressources des nœuds du réseau et est résistante à la censure. Radicle 1.0 a été lancé en septembre 2024. Les composants sont implémentés en Rust sous les licences Apache 2.0 et MIT, avec des builds disponibles pour Linux et macOS. Un client de bureau, une interface web et une CLI sont en développement.

La découverte des voisins utilise le protocole Gossip, tandis que la réplication des données repose sur Heartwood, construit sur Git. L'identification des nœuds et la vérification des dépôts sont basées sur la cryptographie à clé publique sans comptes utilisateurs. L'authentification et l'autorisation sont décentralisées.

Les dépôts sont auto-certifiants : chacun possède un ID unique, et les commits ainsi que les commentaires d'issue sont signés par le propriétaire. L'accès est possible s'il existe au moins une réplique dans le réseau. Les nœuds s'abonnent aux dépôts pour recevoir les mises à jour, et les dépôts privés sont pris en charge.

Gestion des données et mécanismes de stockage

La gestion est assurée par des délégués — utilisateurs, bots ou groupes liés à des ID. Les délégués acceptent les correctifs, ferment les issues et configurent les accès. Plusieurs délégués peuvent être assignés à un dépôt.

Les données sont stockées dans des dépôts git standards avec des espaces de noms supplémentaires pour les pairs et les forks. Les discussions, correctifs et revues sont des Objets Collaboratifs (COB), répliqués entre les nœuds.

L'intégration avec les outils Git est simplifiée : la plateforme utilise les objets Git et prend en charge les références vers des branches externes, tags, étiquettes et notes.

Principales mises à jour de la version 1.7

La version 1.7 met l'accent sur la sécurité, les performances et l'utilisabilité. Voici les changements principaux :

• Sigrefs (Références signées) : Implémentation repensée pour se protéger contre les attaques de relecture. Ajout d'un pointeur vers l'entrée précédente de la chaîne, qui est signée intégralement. Cela empêche la substitution de code ancien par une nouvelle signature, garantissant un historique vérifiable depuis la racine.

• Blocage des nœuds : Étendu au niveau de la connexion. Le blocage se déclenche lors de l'établissement de la connexion ou de la réception de données d'un nœud bloqué, et pas seulement pendant le transfert de données.

• Références vers des objets Git externes : Toutes sont désormais autorisées sauf les branches temporaires (précédemment limitées aux branches, tags et métadonnées Radicle).

• Messages d'erreur : Amélioration de l'informativité pour les opérations manquant de permissions d'accès.

• Optimisation E/S : synchronous = NORMAL par défaut dans SQLite (précédemment FULL), réduisant la charge sur les nœuds à longue durée de vie. Ajout des paramètres journal_mode et synchronous dans la configuration.

• Correction de vulnérabilité : Problème résolu ; détails à divulguer le 23 mars. L'analyse des dépôts publics n'a révélé aucune trace d'exploitation.

Points importants

• Les sigrefs forment désormais une chaîne de signatures, bloquant les attaques de relecture et les altérations d'historique.
• Le blocage des nœuds au niveau de la connexion renforce la protection contre les pairs indésirables.
• L'optimisation SQLite réduit la charge E/S sans sacrifier l'intégrité.
• Le support de toutes les références Git externes simplifie la migration et l'intégration.
• La plateforme reste entièrement décentralisée avec un stockage compatible Git.

Recommandations d'implémentation

Pour les développeurs intermédiaires et seniors : Testez Radicle 1.7 dans un réseau P2P isolé. Configurez des délégués pour les bots CI/CD. Surveillez les E/S via les paramètres SQLite sur les nœuds à longue durée de vie. Utilisez les sigrefs pour les dépôts critiques nécessitant une forte résistance à la censure.

— Editorial Team