Die Version 1.7 der P2P-Plattform Radicle wurde veröffentlicht, die darauf abzielt, einen dezentralen Dienst für die gemeinsame Entwicklung und Speicherung von Code bereitzustellen, ähnlich wie GitHub und GitLab, jedoch nicht an bestimmte Server gebunden, zensurfrei und unter Nutzung der Ressourcen der Teilnehmer des P2P-Netzwerks operierend. Die Plattform unterstützt typische Elemente der sozialen Interaktion von Entwicklern wie Issues, Patches und Code-Reviews. Die Entwicklungen des Projekts sind in Rust geschrieben und unter den Lizenzen Apache 2.0 und MIT verfügbar. Builds sind für Linux und macOS vorbereitet. Darüber hinaus werden ein Desktop-Client, ein Web-Interface und ein Konsolen-Interface entwickelt.
Radicle ermöglicht es, bei der Entwicklung und Verteilung von Code unabhängig von zentralisierten Plattformen und Unternehmen zu sein, deren Bindung zusätzliche Risiken mit sich bringt (wie z.B. einen einzelnen Ausfallpunkt, das Unternehmen könnte schließen oder die Nutzungsbedingungen ändern). Zur Verwaltung des Codes in Radicle wird das gewohnte Git verwendet, ergänzt durch Mittel zur Definition von Repositories in einem P2P-Netzwerk. Alle Daten werden in erster Linie lokal gespeichert (Konzept "local-first") und sind stets auf dem Computer des Entwicklers verfügbar, unabhängig vom Zustand der Netzwerkverbindung.
Die Teilnehmer gewähren Zugang zu ihrem Code und verwandten Artefakten, wie z.B. Patches und Diskussionen über Fehlerbehebungen (Issues), die lokal gespeichert und auf Knoten anderer interessierter Entwickler, die mit dem gemeinsamen dezentralen P2P-Netzwerk verbunden sind, repliziert werden. Dadurch entsteht ein globales, dezentrales Git-Repository, dessen Daten auf verschiedenen Systemen der Teilnehmer repliziert und dupliziert sind.
Für die Identifizierung benachbarter Knoten in einem P2P-Netzwerk wird das Gossip-Protokoll verwendet, während das Heartwood-Protokoll, basierend auf Git, für die Replikation von Daten zwischen den Knoten zuständig ist. Da das Protokoll auf Git basiert, lässt sich die Plattform problemlos in bestehende Git-Entwicklungstools integrieren. Zur Identifikation der Knoten und zur Validierung der Repositories kommt eine kryptographische Methode auf Basis von Public-Key-Kryptographie zum Einsatz, ohne dass Benutzerkonten erforderlich sind. Die Authentifizierung und Autorisierung erfolgt ebenfalls auf Basis von Public Keys, ohne zentrale Zertifizierungsstellen. Server.
Jedes Repository in einem P2P-Netzwerk besitzt eine eindeutige Identifikation und ist selbstzertifizierend, d.h. alle Aktionen im Repository, wie das Hinzufügen von Commits und das Hinterlassen von Kommentaren zu Issues, werden vom Eigentümer mit einer digitalen Signatur versehen. Diese ermöglicht es, die Integrität der Daten auf anderen Knoten zu überprüfen, ohne zentrale Zertifizierungsstellen einzusetzen. Um auf das Repository zuzugreifen, reicht es aus, wenn sich mindestens ein Knoten online befindet, der eine replizierte Kopie davon hat.
Knoten im P2P-Netzwerk können sich für bestimmte Repositories anmelden und Updates erhalten. Es ist möglich, private Repositories zu erstellen, die nur bestimmten Knoten zugänglich sind. Zur Verwaltung und Eigentümerschaft eines Repositories wird das Konzept der 'Delegierten' verwendet. Ein Delegierter kann sowohl ein einzelner Benutzer als auch ein Bot oder eine Gruppe sein, die an eine spezielle Identifikationsnummer gebunden sind. Delegierte können Patches im Repository akzeptieren, Issues schließen und Zugriffsrechte für das Repository festlegen. An jedes Repository können mehrere Delegierte gebunden werden.
Radicle-Repositories werden auf den Systemen der Benutzer als gewöhnliche Git-Repositories gespeichert, in denen zusätzliche Namensräume für die Speicherung von Peer-Daten und Forks vorhanden sind, mit denen aktuell gearbeitet wird. Diskussionen, vorgeschlagene Patches und Komponenten zur Organisation von Reviews werden ebenfalls im Git-Repository als kollaborative Objekte (COB – Collaborative Objects) gespeichert und zwischen den Peers repliziert.
In der neuen Version:
- Die Implementierung der signierten Referenzen (sigrefs) wurde überarbeitet, und es wurde ein Schutz gegen die Wiederverwendung von Signaturen eingeführt. Die alte Repository-Struktur erlaubte es, den Code durch eine ältere Version zu ersetzen, indem eine frühere gültige Signatur erneut verwendet wurde. Um dieses Problem zu beheben, wurde in der neuen Implementierung ein Verweis auf den vorherigen Datensatz hinzugefügt, der von der aktuellen Signatur abgedeckt wird, was eine kontinuierliche Kette von Änderungen bildet, deren Integrität im Verhältnis zur Wurzel verfolgt werden kann.
- Die Möglichkeiten zur Blockierung von Knoten wurden erweitert, die nun auf der Ebene der Verbindungssteuerung blockiert werden. Während zuvor nur der Empfang von Daten blockiert wurde, ohne die Verbindung des Knotens einzuschränken, wird die Blockierung nun bereits beim Aufbau einer Verbindung mit dem blockierten Knoten und beim Empfangen von Verbindungen von diesem angewendet.
- Es ist jetzt erlaubt, beliebige Verweise auf externe Git-Objekte zu verwenden, außer auf temporäre Branches. Zuvor waren nur Verweise auf externe Branches, Tags, Radicle-Metadaten, Notizen und Objekte zur Zusammenarbeit erlaubt.
- Die Informationsgehalte von Fehlermeldungen, die bei dem Versuch auftreten, Operationen auszuführen, für die der Benutzer nicht ausreichend berechtigt ist, wurden verbessert.
- Die Effizienz von Ein- und Ausgaben wurde erhöht. Die Entwickler haben festgestellt, dass bei längeren Laufzeiten der Knoten die Kombination der Einstellungen «journal_mode = WAL» und «synchronous = FULL» in der SQLite-Datenbank, die zur Speicherung des lokalen Zustands verwendet wird, zu einer hohen Anzahl von Ein-/Ausgabeoperationen führt. Um die Last zu verringern, wurde der Parameter «synchronous» nun standardmäßig auf «NORMAL» gesetzt, und in die Radicle-Konfigurationsdatei wurden Optionen hinzugefügt, um die Werte dieser Parameter durch den Benutzer zu ändern.
- Eine Sicherheitsanfälligkeit wurde behoben, deren Informationen am 23. März veröffentlicht werden. Derzeit wird lediglich berichtet, dass das Entwicklerteam alle öffentlich zugänglichen Radicle-Repositorys gescannt hat und keine Hinweise auf die Ausnutzung dieses Problems gefunden wurden.
Quelle: opennet.ru
