Wydano wersję 1.7 platformy P2P Radicle, mającej na celu stworzenie zdecentralizowanej usługi współpracy i przechowywania kodu, podobnej do GitHub i GitLab, lecz niezwiązanej z konkretnymi serwerami, nietkniętej cenzurą i działającej z wykorzystaniem zasobów uczestników sieci P2P. Platforma wspiera typowe elementy interakcji społeczności deweloperów, takie jak zgłoszenia (issue), poprawki (patches) i przeglądy kodu. Rozwój projektu napisany jest w języku Rust i jest dystrybuowany na licencjach Apache 2.0 oraz MIT. Przygotowane są wersje na Linux i macOS. Dodatkowo rozwijane są klient desktopowy, interfejs webowy oraz interfejs konsolowy.
Radicle pozwala na niezależność w rozwijaniu i dystrybucji kodu od scentralizowanych platform i korporacji, których powiązania wprowadzają dodatkowe ryzyka (pojedynczy punkt awarii, firma może zniknąć lub zmienić warunki współpracy). Do zarządzania kodem w Radicle wykorzystywany jest znany Git, rozszerzony o mechanizmy określania repozytoriów w sieci P2P. Wszystkie dane są przede wszystkim przechowywane lokalnie (koncepcja local-first) i zawsze dostępne na komputerze dewelopera, niezależnie od stanu połączenia sieciowego.
Uczestnicy udostępniają dostęp do swojego kodu oraz powiązanych z kodem artefaktów, takich jak poprawki oraz dyskusje dotyczące błędów (issues), które są przechowywane lokalnie i replikowane na węzły innych zainteresowanych deweloperów podłączonych do wspólnej zdecentralizowanej sieci P2P. W efekcie tworzy się globalne, zdecentralizowane repozytorium Git, którego dane są replikowane i duplikowane na różnych systemach uczestników.
Do określania sąsiednich węzłów w sieci P2P stosowany jest protokół Gossip, a do replikacji danych między węzłami protokół Heartwood, oparty na Git. Ponieważ protokół jest oparty na Git, platformę łatwo zintegrować z istniejącymi narzędziami do rozwoju wykorzystującymi Git. Do identyfikacji węzłów oraz weryfikacji repozytoriów stosuje się kryptografię opartą na kluczach publicznych, bez użycia kont. Uwierzytelnianie i autoryzacja odbywają się na podstawie kluczy publicznych bez scentralizowanego systemu uwierzytelniania. serwerów.
Każde repozytorium w sieci P2P ma swój unikalny identyfikator i jest samoświadome (self-certifying), co oznacza, że wszystkie działania w repozytorium, takie jak dodawanie commitów i pozostawianie komentarzy do problemów, są poświadczane przez właściciela podpisem cyfrowym, co pozwala na upewnienie się o poprawności danych na innych węzłach bez użycia scentralizowanych centrów certyfikacji. Aby uzyskać dostęp do repozytorium, wystarczy, że w trybie online będzie przynajmniej jeden węzeł, na którym znajduje się jego zreplikowana kopia.
Węzły w sieci P2P mogą subskrybować określone repozytoria i otrzymywać aktualizacje. Możliwe jest tworzenie prywatnych repozytoriów, które są dostępne tylko dla określonych węzłów. Do zarządzania i posiadania repozytorium stosuje się koncepcję „delegatów” (delegates). Delegatem może być zarówno pojedynczy użytkownik, jak i bot lub grupa przypięta do specjalnego identyfikatora. Delegaci mogą przyjmować poprawki do repozytorium, zamykać problemy i ustalać prawa dostępu do repozytorium. Do każdego repozytorium może być przypisanych kilku delegatów.
Repozytoria Radicle są przechowywane na systemach użytkowników jako standardowe repozytoria git, które zawierają dodatkowe przestrzenie nazw do przechowywania danych węzłów i forków, z którymi prowadzone są bieżące prace. Dyskusje, proponowane poprawki i komponenty do organizacji recenzji również są przechowywane w repozytorium git w postaci wspólnych obiektów (COB — Collaborative Objects) i replikowane między węzłami.
W nowym wydaniu:
- Przeprojektowano realizację podpisanych referencji (sigrefs — Signed References), w której dodano zabezpieczenia przed ponownym użyciem podpisów. Stara struktura repozytorium umożliwiała zastąpienie kodu jego wcześniejszą wersją, ponownie wykorzystując starą, poprawną sygnaturę. Aby zablokować ten problem, w nowej realizacji dodano wskaźnik do poprzedniego wpisu, obejmującego bieżący podpis, co tworzy ciągłą historię zmian, której integralność można śledzić względem korzenia.
- Rozszerzono możliwości blokowania węzłów, które teraz są blokowane na poziomie zarządzania połączeniami. Wcześniej blokowano tylko odbiór danych, a połączenie węzła nie było ograniczane; teraz blokada ma zastosowanie na etapie nawiązywania połączenia z zablokowanym węzłem oraz przy odbiorze połączenia od zablokowanego węzła.
- Zezwolono na korzystanie z dowolnych linków do zewnętrznych obiektów Git, z wyjątkiem tymczasowych gałęzi. Wcześniej dozwolone były tylko linki do zewnętrznych gałęzi, tagów, metadanych Radicle, notatek oraz obiektów do współpracy.
- Podniesiono informacyjność komunikatów o błędach, które występują podczas próby wykonania operacji, do których użytkownik nie ma wystarczających uprawnień.
- Zwiększono efektywność operacji we/wy. Programiści odkryli, że w długo działających węzłach połączenie ustawień „journal_mode = WAL” i „synchronous = FULL” w bazie danych SQLite, stosowanej do przechowywania lokalnego stanu, prowadzi do dużego obciążenia operacjami we/wy. Aby zmniejszyć obciążenie, domyślna wartość parametru „synchronous” została ustawiona na „NORMAL”, a plik konfiguracyjny Radicle zawiera teraz ustawienia umożliwiające użytkownikowi zmianę tych parametrów.
- Usunięto lukę w zabezpieczeniach, której informacje zostaną ujawnione 23 marca. Obecnie informuje się jedynie, że zespół deweloperów przeprowadził skanowanie wszystkich publicznie dostępnych repozytoriów Radicle i nie znaleziono śladów wykorzystania tego problemu.
Źródło: opennet.ru
