Die Ausgabe 1.7 der P2P-Plattform Radicle wurde veröffentlicht. Sie zielt darauf ab, einen dezentralen Dienst fĂŒr die gemeinsame Entwicklung und Speicherung von Code zu schaffen, der Ă€hnlich wie GitHub und GitLab ist, jedoch nicht an spezifische Server gebunden ist, zensurfrei arbeitet und die Ressourcen der Teilnehmer des P2P-Netzwerks nutzt. 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 veröffentlicht. Builds sind fĂŒr Linux und macOS vorbereitet. ZusĂ€tzlich werden ein Desktop-Client, ein Web-Interface und ein Konsolen-Interface entwickelt.
Radicle ermöglicht es, bei der Entwicklung und Verbreitung von Code unabhĂ€ngig von zentralisierten Plattformen und Unternehmen zu bleiben, deren Bindung zusĂ€tzliche Risiken mit sich bringt (Single Point of Failure, das Unternehmen kann schlieĂen oder die Nutzungsbedingungen Ă€ndern). Zur Verwaltung des Codes in Radicle wird das vertraute Git verwendet, ergĂ€nzt durch Tools zur Bestimmung von Repositories im P2P-Netzwerk. Alle Daten werden zunĂ€chst lokal gespeichert (Local-First-Konzept) und sind immer auf dem Computer des Entwicklers verfĂŒgbar, unabhĂ€ngig vom Status der Netzwerkverbindung.
Teilnehmer gewÀhren Zugang zu ihrem Code und zu den damit verbundenen Artefakten wie Patches und Diskussionen von Fehlerberichten (Issues), die lokal gespeichert und auf die 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.
Zur Bestimmung benachbarter Knoten im P2P-Netzwerk wird das Gossip-Protokoll verwendet, und zur Replikation von Daten zwischen den Knoten das Heartwood-Protokoll, das auf Git basiert. Da das Protokoll auf Git basiert, lĂ€sst sich die Plattform leicht mit bestehenden Werkzeugen fĂŒr die Git-Entwicklung integrieren. Zur Identifizierung der Knoten und zur Verifizierung der Repositories wird eine auf öffentlicher SchlĂŒssel-Kryptographie basierende Methode verwendet, ohne dass Benutzerkonten erforderlich sind. Die Authentifizierung und Autorisierung erfolgt auf Basis öffentlicher SchlĂŒssel ohne zentrale Zertifizierungsstellen. Server.
Jedes Repository im P2P-Netzwerk hat eine einzigartige Kennung 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 bestĂ€tigt, die es ermöglicht, die Richtigkeit der Daten auf anderen Knoten ohne die Nutzung zentraler Zertifizierungsstellen zu ĂŒberprĂŒfen. Um auf das Repository zuzugreifen, genĂŒgt es, dass sich mindestens ein Knoten online befindet, auf dem eine replizierte Kopie vorhanden ist.
Knoten im P2P-Netzwerk können sich auf bestimmte Repositories abonnieren und Updates erhalten. Es ist möglich, private Repositories zu erstellen, die nur bestimmten Knoten zugĂ€nglich sind. Zur Verwaltung und zum Eigentum am Repository 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 Kennung gebunden sind. Delegierte können Patches im Repository annehmen, Issues schlieĂen und Zugriffsrechte fĂŒr das Repository festlegen. An jedes Repository können mehrere Delegierte gebunden sein.
Radicle-Repositories werden auf den Systemen der Benutzer als gewöhnliche Git-Repositories gespeichert, die zusĂ€tzliche NamensrĂ€ume zur Speicherung von Peer- und Fork-Daten enthalten, mit denen derzeit gearbeitet wird. Diskussionen, vorgeschlagene Patches und Komponenten zur Organisation von ĂberprĂŒfungen werden ebenfalls im Git-Repository als kollaborative Objekte (COB â Collaborative Objects) gespeichert und zwischen den Peers repliziert.
In der neuen Version:
- Die Implementierung von signierten Verweisen (sigrefs â Signed References) wurde ĂŒberarbeitet, wobei ein Schutz gegen die Wiederverwendung von Signaturen hinzugefĂŒgt wurde. Die alte Repository-Struktur erlaubte es, den Code durch eine Ă€ltere Version zu ersetzen, indem die alte gĂŒltige Signatur erneut verwendet wurde. Um dieses Problem zu lösen, wurde in der neuen Implementierung ein Zeiger auf den vorherigen Eintrag hinzugefĂŒgt, der von der aktuellen Signatur abgedeckt wird. Dies bildet eine kontinuierliche Kette von Ănderungen, deren IntegritĂ€t in Bezug auf die Wurzel nachverfolgt werden kann.
- Die Möglichkeiten zum Blockieren von Knoten wurden erweitert, die jetzt auf Verbindungsmanagement-Ebene blockiert werden. Wenn zuvor nur der Empfang von Daten blockiert wurde, ohne die Verbindung des Knotens einzuschrÀnken, so wird die Blockade jetzt bereits bei der Herstellung einer Verbindung zu einem blockierten Knoten und beim Empfang einer Verbindung von einem blockierten Knoten angewendet.
- Es ist erlaubt, beliebige Verweise auf externe Git-Objekte zu verwenden, mit Ausnahme temporĂ€rer Zweige. FrĂŒher waren nur Verweise auf externe Zweige, Tags, Radicle-Metadaten, Notizen und Objekte zur Zusammenarbeit erlaubt.
- Die Informationsgehalte der Fehlermeldungen wurden erhöht, die auftreten, wenn Benutzer versuchen, Operationen durchzufĂŒhren, fĂŒr die sie nicht ĂŒber ausreichende Berechtigungen verfĂŒgen.
- Die Effizienz von Ein- und Ausgabe wurde erhöht. Die Entwickler haben festgestellt, dass bei lange laufenden 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- und Ausgabeoperationen fĂŒhrt. Um die Belastung zu verringern, ist der Parameter âsynchronousâ nun standardmĂ€Ăig auf âNORMALâ gesetzt, und im Radicle-Konfigurationsdatei wurden Einstellungen hinzugefĂŒgt, um es dem Benutzer zu ermöglichen, diese Parameter anzupassen.
- Eine Schwachstelle wurde behoben, deren Details am 23. MÀrz veröffentlicht werden. Derzeit wird nur berichtet, dass das Entwicklerteam alle öffentlich zugÀnglichen Radicle-Repositories gescannt hat und keine Hinweise auf die Ausnutzung dieses Problems gefunden hat.
Quelle: opennet.ru
