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
