La version 1.7 de la plateforme P2P Radicle, visant à créer un service décentralisé pour le développement et le stockage de code similaire à GitHub et GitLab, mais sans attachement à des serveurs spécifiques, sans censure et fonctionnant grâce aux ressources des participants du réseau P2P, est désormais disponible. La plateforme prend en charge des éléments typiques d'interaction sociale entre développeurs, tels que les issues, les patches et les revues de code. Les contributions du projet sont écrites en Rust et sont distribuées sous les licences Apache 2.0 et MIT. Des versions sont disponibles pour Linux et macOS. Un client de bureau, une interface web et une interface en ligne de commande sont également en cours de développement.
Radicle permet de ne pas dépendre des plateformes et des entreprises centralisées pour le développement et la distribution de code, avec les risques additionnels qu'elles impliquent (point de défaillance unique, l'entreprise peut fermer ou changer les conditions d'utilisation). Pour la gestion du code, Radicle utilise Git, enrichi par des outils pour définir des dépôts dans le réseau P2P. Toutes les données sont d'abord sauvegardées localement (concept local-first) et sont toujours disponibles sur l'ordinateur du développeur, quel que soit l'état de la connexion réseau.
Les participants donnent accès à leur code et aux artefacts associés, tels que les patches et les discussions sur les corrections d'erreurs (issues), qui sont sauvegardés localement et répliqués sur les nœuds d'autres développeurs intéressés, connectés au réseau P2P décentralisé commun. Un dépôt Git décentralisé mondial se forme ainsi, dont les données sont répliquées et dupliquées sur différents systèmes des participants.
Pour identifier les nœuds voisins dans le réseau P2P, le protocole Gossip est utilisé, et pour la réplication des données entre les nœuds, le protocole Heartwood, basé sur Git. Étant donné que le protocole repose sur Git, la plateforme s'intègre facilement avec les outils existants pour le développement avec Git. Pour identifier les nœuds et vérifier les dépôts, une cryptographie basée sur des clés publiques est utilisée, sans recourir à des comptes. L'authentification et l'autorisation se font sur la base de clés publiques sans autorité de certification centralisée. serveurs.
Chaque dépôt dans un réseau P2P possède son propre identifiant unique et est auto-certifié, c'est-à-dire que toutes les actions dans le dépôt, telles que l'ajout de commits et les commentaires sur les issues, sont validées par le propriétaire à l'aide d'une signature numérique, permettant ainsi de vérifier l'exactitude des données sur d'autres nœuds sans utiliser de centres de certification centralisés. Pour accéder au dépôt, il suffit qu'au moins un nœud en ligne possède sa copie répliquée.
Les nœuds dans le réseau P2P peuvent s'abonner à des dépôts spécifiques et recevoir des mises à jour. Il est possible de créer des dépôts privés, accessibles uniquement à certains nœuds. La gestion et la propriété d'un dépôt utilisent le concept de « délégués ». Un délégué peut être un utilisateur individuel, un bot ou un groupe, liés à un identifiant spécial. Les délégués peuvent accepter des patchs dans le dépôt, fermer des issues et définir des droits d'accès au dépôt. Plusieurs délégués peuvent être associés à chaque dépôt.
Les dépôts Radicle sont stockés sur les systèmes des utilisateurs sous forme de dépôts git ordinaires, qui contiennent des espaces de noms supplémentaires pour stocker les données des pairs et des forks avec lesquels le travail actuel est effectué. Les discussions, les patchs proposés et les composants pour l'organisation de la révision sont également conservés dans le dépôt git sous forme d'objets collaboratifs (COB - Collaborative Objects) et sont répliqués entre les pairs.
Dans cette nouvelle version :
- La mise en œuvre des références signées (sigrefs - Signed References) a été révisée, introduisant une protection contre la réutilisation des signatures. Anciennement, la structure du dépôt permettait de remplacer le code par une ancienne version en réutilisant une ancienne signature valide. Pour résoudre ce problème, la nouvelle implémentation ajoute un pointeur vers l'entrée précédente, couvert par la signature actuelle, formant une chaîne continue de modifications, dont l'intégrité peut être suivie par rapport à la racine.
- Les capacités de blocage des nœuds ont été étendues, permettant maintenant le blocage au niveau de la gestion des connexions. Auparavant, seul le réception des données était bloqué sans restreindre la connexion du nœud, mais désormais le blocage s'applique lors de l'établissement de la connexion avec un nœud bloqué et lors de la réception d'une connexion d'un nœud bloqué.
- L'utilisation de tout lien vers des objets Git externes est maintenant autorisée, à l'exception des branches temporaires. Auparavant, seuls des liens vers des branches externes, des tags, des métadonnées Radicle, des notes et des objets collaboratifs étaient autorisés.
- Les messages d'erreur lors de l'exécution d'opérations pour lesquelles l'utilisateur n'a pas les droits ont été rendus plus informatifs.
- L'efficacité des entrées/sorties a été améliorée. Les développeurs ont constaté que sur des nœuds fonctionnant depuis longtemps, la combinaison des paramètres « journal_mode = WAL » et « synchronous = FULL » dans la base de données SQLite utilisée pour stocker l'état local entraîne un important volume d'opérations d'entrée/sortie. Pour réduire la charge, la valeur par défaut de « synchronous » est désormais réglée sur « NORMAL », et des options ont été ajoutées au fichier de configuration Radicle pour permettre à l'utilisateur de modifier ces paramètres.
- Une vulnérabilité a été corrigée, dont les informations seront divulguées le 23 mars. Actuellement, il est simplement rapporté que l'équipe de développement a analysé tous les dépôts Radicle accessibles publiquement et n'a trouvé aucune trace d'exploitation de ce problème.
Source : opennet.ru
