Plan wygaszania C tor: daty wyłączeń, stan Arti i na co powinni uważać operatorzy
Wygaszanie pierwotnej implementacji Tor w języku C przeszło od zasady do harmonogramu. 23 czerwca 2026 r. Tor Project zapowiedział zamiar zakończenia zgodności sieciowej dla Tor 0.4.8 i wszystkich starszych wersji: po 1 września 2026 r. wersje te „przestaną w ogóle działać w sieci”. Ogłoszenie, zakotwiczone w prowadzonym projekcie Arti Relay, to jak dotąd najczytelniejszy publiczny punkt odniesienia dla etapowania przejścia z C tor na Rust.
Dlaczego Tor jest przepisywany na Rust
Arti to nowej generacji implementacja protokołów Tor w Rust, opisana w README projektu jako wysiłek budowy osadzalnej bazy kodu o jakości produkcyjnej. Podane powody są praktyczne, nie kosmetyczne. Zespół szacuje, że co najmniej połowa śledzonych luk bezpieczeństwa byłaby niemożliwa w języku bezpiecznym pamięciowo. Baza w C, rozwijana nieprzerwanie od 2002 r., nazbierała to, co ten sam dokument nazywa zbytecznymi relacjami-spaghetti między komponentami. A bibliotekę w Rust można osadzać w aplikacjach w sposób, jakiego pierwotny projekt proxy SOCKS nigdy nie przewidywał — co, jak liczą deweloperzy, przyspieszy przyszłą pracę. Harmonogram migracji naszkicował w lutym 2023 r. Nick Mathewson, współzałożyciel Tora i jeden z głównych architektów Arti, w dyskusji na tor-dev:W średnim okresie wycofamy implementację klienta Tor w C. Nie stanie się to wcześniej niż pewien czas po tym, jak Arti stanie się pełnym klientem tor z obsługą serwisów onion i z kompletnym rozwiązaniem embedding/FFI/RPC.W długim okresie, napisał Mathewson, Arti ma całkowicie zastąpić C tor, co wymaga także przekaźników i autorytetów katalogowych w Rust. Podkreślił, że nie ustalono żadnego harmonogramu i że każda przyszła oś czasu będzie z niektórych punktów widzenia irytująco długa, a z innych irytująco krótka. Trzy lata później sekwencja toczy się w zasadzie jak opisano: najpierw gotowy klient, centralne role sieci na końcu.
Co Arti potrafi dziś, a czego nie
Jako klient Arti ma się dobrze. README, zaktualizowane w sierpniu 2026 r., nazywa go pełnowartościowym klientem Tor nadającym się do ogólnego użytku klienckiego: działa jako proxy SOCKS, łączy się z serwisami onion i obsługuje mostki z transportami podpinanymi, w tym obfs4 i Snowflake. Wydania przychodzą równo. Arti 2.0.0 pojawiło się w lutym 2026 r., a obecne wydanie, Arti 2.7.0, ukazało się 1 października 2026 r. z dalszą pracą fundamentową dla przekaźników i autorytetów katalogowych oraz pakietem poprawek bezpieczeństwa. Ten postęp po stronie klienckiej omawialiśmy szerzej w naszej wcześniejszej relacji o Arti. Poza klientem uczciwy obraz jest skromniejszy. Uruchamianie Arti jako przekaźnika czy autorytetu katalogowego nie jest jeszcze wspierane, jak wprost stwierdzają notki wydania 2.0.0, a README przekaźnika nosi stałe ostrzeżenie: obsługa przekaźników jest eksperymentalna i "w ogóle nie jest gotowa do ogólnego wdrożenia", z prośbą, by nie uruchamiać przekaźnika Arti w sieci publicznej. Wewnętrzna checklista projektu pokazuje realny postęp — kanały przychodzące, obsługę CREATE2 i EXTEND2, nasłuch na ORPort — podczas gdy kontrola przeciążenia, publikacja deskryptorów, polityki wyjściowe i obrona przed denial-of-service wciąż czekają. Serwisy onion mają podobną pozycję po stronie serwisowej. Własna dokumentacja projektu mówi, że serwis uruchomiony na Arti nadaje się wyłącznie do testów i eksperymentów: brakuje mu autoryzacji klientów, przekaźników vanguard, sensownej ochrony przed denial-of-service i wypełniania obwodów, z ostrzeżeniem, że jego prowadzenie mogłoby wręcz naruszyć prywatność innych użyć tej samej instancji Arti. Łączenie się z serwisami onion z Arti jako klient to natomiast część normalnej pracy klienta.Wygaszenie we wrześniu, wyjaśnione
Granica z 1 września to ruch kompatybilnościowy, nie termin bezpieczeństwa. Tor 0.4.8 osiągnął już koniec życia 1 czerwca 2026 r. wedle kalendarza wydań projektu i nie otrzymuje już aktualizacji. Po wrześniu zmienia się zachowanie protokołu katalogowego: seria 0.4.9 usuwa z danych katalogowych stare klucze onion TAP i wpisy family przekaźników, zgodnie z propozycjami 350 i 321, co oszczędza pasmo klientów i przyspiesza start wszystkim. Ponieważ klienci i przekaźniki na 0.4.8 i starszych oczekują obecności kluczy TAP, przestają działać, gdy te pola znikają. Druga motywacja jest nazywana otwarcie: implementacja autorytetu katalogowego w Arti wkrótce będzie potrzebować integracji z siecią, a łatwiej ją pisać bez przestarzałych pól. To też nie jest koniec samego C tor. Ten sam kalendarz wymienia 0.4.9, ogłoszoną stabilną w lutym 2026 r., z własnym końcem życia jeszcze nierozstrzygniętym, oraz serię 0.5.0, której okno scalania otworzyło się w marcu 2026 r. Zespół opisuje bieżące utrzymanie C tor jako obejmujące funkcje dobrane po to, by ułatwić przejście na Arti. Projekty podrzędne, które wciąż dostarczają stare wersje, są kontaktowane bezpośrednio, a praca dotarcia jest śledzona w zgłoszeniu network-health, które przyjmuje też prośby operatorów potrzebujących więcej czasu.Na co operatorzy powinni uważać
- Operatorzy przekaźników: przejdźcie na 0.4.9.x przed 1 września 2026 r.; cokolwiek starszego wypadnie z sieci. Nie ma jeszcze przekaźnika Arti, na który można migrować — traktujcie twierdzenia odwrotne z nieufnością i śledźcie changelog Arti.
- Operatorzy serwisów onion: C tor pozostaje wspieranym sposobem prowadzenia serwisu. Znacznikami, które zasygnalizują dojrzałość Arti jako platformy serwisowej, będą wymienione wyżej brakujące elementy: restricted discovery, obsługa vanguard, obrona przed denial-of-service i wypełnianie obwodów.
- Deweloperzy aplikacji: docelowym stanem jest osadzanie i RPC, a nie doklejany demon SOCKS. Arti 2.0.0 oznaczyło API skrzynki arti najwyższego poziomu jako eksperymentalne, podczas gdy arti-client pozostaje wspieranym interfejsem, a 2.7.0 dodało sterowanie konfiguracją po RPC.