Wtyczki dsh: jak działają i jak bezpiecznie je sprawdzać

Czym jest wtyczka dsh i jakie ma możliwości?

Wtyczki dsh to pakiety Node, które DeepSeek Harness ładuje do własnego procesu. Instalacja wtyczki powoduje uruchomienie cudzego kodu z uprawnieniami Twojego agenta, na maszynie, do której agent ma dostęp. Między załadowaną wtyczką a resztą środowiska harness nie ma żadnych zabezpieczeń. Przed instalacją należy zatem zadać pytanie, do jakich zasobów dany kod ma dostęp i jak ograniczyć ten zakres.

dsh (DeepSeek Harness) to otwartoźródłowe środowisko agentowe DeepSeek AI, zbudowane na frameworku wtyczek o nazwie Cordis. Dokumentacja projektu wskazuje, że każdy element jest wtyczką. Adapter modelu jest wtyczką. Interfejs webowy, w którym wpisujesz polecenia, również jest wtyczką. Każdy element zainstalowany spoza projektu trafia do tego samego drzewa i posiada ten sam poziom zaufania, co komponenty dostarczone w ramach instalacji. Jeśli jeszcze nie uruchomiłeś środowiska, zacznij od DeepSeek Harness na VPS i wróć tutaj przed dodaniem jakichkolwiek rozszerzeń.

Punkty rozszerzeń, do których może uzyskać dostęp wtyczka, zostały wymienione w AGENTS.md repozytorium. Według stanu na sierpień 2026 obejmują one:

• LLM (large language model): dostawca, za którego płacisz kluczem API
• Shell: obsługa bash, z dostawcami lokalnymi oraz pwsh
• Filesystem: dostęp do plików kontrolowany politykami
• Web: dostawcy wyszukiwania i pobierania danych
• Subprocess: dostawca drzewa procesów
• Workflow: wątki robocze
• Subagent: delegowanie zadań do kolejnych agentów
• Settings and credentials: zapisana konfiguracja i zmienne środowiskowe

Wtyczka rejestruje również narzędzia w ctx.tools, a dokumentacja wyraźnie wskazuje, że schemat zarejestrowanego narzędzia jest dołączany do procesu budowania promptu. To drugie zagadnienie jest często pomijane. Wtyczka może wpłynąć na decyzje agenta bez wykonywania nietypowego kodu, ponieważ dostarczony przez nią opis staje się tekstem odczytywanym przez model. Jest to problem o tym samym charakterze, co prompt injection w agentach programistycznych, z jedną różnicą: ten tekst pojawia się w momencie instalacji i pozostaje aktywny do czasu usunięcia wtyczki.

W jaki sposób dsh znajduje i ładuje wtyczki?

Nie istnieje globalny katalog wtyczek. Uruchomiony dsh to drzewo wtyczek tworzone podczas startu z uporządkowanych warstw, a jednostką przechowującą wybory użytkownika jest profil. $DSH_HOME domyślnie wskazuje na ~/.dsh, a każdy profil znajduje się w $DSH_HOME/profiles/<name>. Profile web oraz headless tworzą się automatycznie przy pierwszym użyciu na podstawie dostarczonych szablonów.

Katalog profilu zawiera dwa pliki, które decydują o całości konfiguracji:

• package.json, zawierający zależności wtyczek spoza drzewa oraz manifest dsh.profile z uporządkowaną listą bundles
• cordis.patch.yml, własna warstwa poprawek nakładana na te pakiety

ls ~/.dsh
ls ~/.dsh/profiles/web

Proces startu nakłada warstwy w następującej kolejności, przy czym późniejsze warstwy mają pierwszeństwo:

1. pusty katalog główny
2. pakiety profilu, w kolejności określonej w manifeście
3. cordis.patch.yml profilu
4. $DSH_HOME/cordis.patch.yml
5. wszelkie nakładki --patch <path> przekazane w wierszu poleceń

Dwie flagi pozwalają wyświetlić wynik tego złożenia bez uruchamiania jakichkolwiek procesów:

dsh --profile web --dump-default-config
dsh --profile web --dump-config

--dump-default-config wyświetla samo złożone drzewo. --dump-config dodaje warstwy profilu oraz lokalne poprawki, dzięki czemu jest to najbardziej wiarygodne zestawienie tego, co zostanie załadowane przy następnym starcie. Należy zapoznać się z tym wynikiem przed zaufaniem maszynie przejętej po innym administratorze.

Jedno ostrzeżenie dotyczące plików poprawek. Konfiguracja nie jest tutaj danymi biernymi, ponieważ format pozwala na użycie wartości oznaczonych !!js w bloku config danej wtyczki. Fragment cordis.patch.yml skopiowany z forum jest kodem, więc należy traktować go tak samo, jak skrypt powłoki pochodzący z tego samego źródła.

Co faktycznie uruchamia dsh plugin add?

dsh plugin --profile <name> <args> przekazuje swoje argumenty do pnpm wewnątrz katalogu danego profilu, dlatego pnpm musi znajdować się w zmiennej PATH. Czasowniki są czasownikami pnpm:

dsh plugin --profile web add '<package-or-git-spec>'
dsh plugin --profile web remove '<package-name>'
dsh plugin --profile web why '<package-name>'
dsh plugin --profile web update

Model bezpieczeństwa instalacji wtyczki dsh jest zatem tożsamy z modelem bezpieczeństwa instalacji dowolnej zależności w stylu npm, z jednym dodatkowym krokiem, w którym wynik jest ładowany do agenta. Pakiet dostarcza własne drzewo zależności, a każdy pakiet w tym drzewie trafia do tego samego procesu. Wszystko, co opisano w jak ataki na łańcuch dostaw npm docierają do serwera, ma tutaj zastosowanie bez żadnych modyfikacji.

pnpm w wersji 10 i nowszych domyślnie nie uruchamia skryptów budowania zależności, a zatwierdzenie odbywa się dla każdego pakietu z osobna poprzez onlyBuiltDependencies lub pnpm approve-builds. Sprawdź posiadaną wersję pnpm:

pnpm --version

To ustawienie domyślne jest wartościowe i stanowi jednocześnie najczęściej pomijaną funkcję bezpieczeństwa w tym ekosystemie. Zablokowane skrypty budowania powstrzymują kod przed uruchomieniem w trakcie instalacji. Nie mają one jednak wpływu na samą wtyczkę, ponieważ istotą wtyczki jest to, że mechanizm sterujący importuje ją i wywołuje przy następnym uruchomieniu. Wtyczka nie potrzebuje haka postinstall. Została ona zaproszona do środka.

Co należy przeczytać przed instalacją wtyczki dsh

Pobierz opublikowane archiwum tarball i zapoznaj się z jego zawartością. Rozpakowanie archiwum nie powoduje wykonania żadnego kodu.

npm pack '<package-name>@<version>'
tar -tzf '<package-name>-<version>.tgz'
tar -xzf '<package-name>-<version>.tgz'
less package/package.json

Cztery pola w pliku package.json dostarczają większości niezbędnych informacji. Przeczytaj scripts, aby sprawdzić wpisy preinstall, install oraz postinstall. Przeczytaj dependencies w poszukiwaniu nazw, których nie rozpoznajesz lub które różnią się tylko jednym znakiem od znanych Ci nazw. Przeczytaj bin, aby sprawdzić, czy pakiet wymaga dodania czegokolwiek do zmiennej PATH. Przeczytaj main lub exports, aby zidentyfikować plik wejściowy, a następnie otwórz go i przeanalizuj jego treść.

Następnie przejrzyj kod, który zostanie faktycznie załadowany. Wtyczka reklamująca narzędzie do powiadomień nie ma powodu, aby odczytywać ~/.ssh, łączyć się z nieznanym hostem lub uruchamiać powłokę. Jeśli pakiet zawiera tylko spakowany lub zminimalizowany kod JavaScript, a w publicznym repozytorium nie ma odpowiadającego mu kodu źródłowego, jest to wystarczający powód do rezygnacji. Wybieraj wtyczki, których kod źródłowy możesz przeczytać, i preferuj rozwiązania o niewielkich rozmiarach.

Możesz również odpytać rejestr bez instalowania czegokolwiek:

pnpm view '<package-name>' dependencies
pnpm view '<package-name>' versions

Pakiet opublikowany w zeszłym tygodniu, posiadający tylko jedną wersję, brak pola z adresem repozytorium oraz nazwę podszywającą się pod popularne narzędzie, to najstarsza sztuczka stosowana w każdym rejestrze. Weryfikacja pobranych plików za pomocą sum kontrolnych to nawyk, który warto wyrobić: zawsze sprawdzaj, co dokładnie pobrałeś, zanim zezwolisz na uruchomienie kodu.

Przypnij wersję i zachowaj plik blokady

Pływający zakres wersji oznacza, że kod wewnątrz procesu agenta może zmienić się przy każdej instalacji lub aktualizacji bez Twojej decyzji. Przypnij go.

dsh plugin --profile web add --save-exact '<package-name>@<version>'

Umiejscowienie flagi różni się w zależności od wersji pnpm, dlatego sprawdź wynik zamiast polegać wyłącznie na poleceniu. Otwórz plik package.json profilu i upewnij się, że zależność jest zapisana jako konkretna wersja, bez znaków ^ lub ~ przed nią. To ten plik decyduje o tym, co zostanie zainstalowane.

Następnie zachowaj plik blokady, który przypina całe drzewo zależności przechodnich, a nie tylko nazwę najwyższego poziomu:

find ~/.dsh -maxdepth 3 -name 'pnpm-lock.yaml'

Skopiuj go w miejsce, które podlega kopiom zapasowym, wraz z plikiem package.json profilu. Te dwa pliki pozwalają odtworzyć to samo drzewo na nowej maszynie. Uruchom dsh plugin --profile web update tylko wtedy, gdy zdecydujesz się na zmianę wersji; nigdy nie traktuj tego jako rutynowego porządkowania. Po wykonaniu operacji sprawdź różnice w pliku blokady.

W przypadku wtyczki instalowanej z git, a nie z rejestru, przypnij commit zamiast gałęzi. Specyfikacja w formacie github:owner/repo#<full commit sha> zapewnia stałe drzewo. Nazwa gałęzi sprawia, że przy następnym rozwiązaniu zależności przez pnpm otrzymasz to, co w danej chwili zawiera ta gałąź – jest to decyzja, którą przekazujesz komuś innemu. Sam mechanizm wymaga tej samej dyscypliny, ponieważ każda opublikowana kompilacja dsh jest kandydatem do wydania, a nieprzypięta instalacja może w dowolnym dniu wskazać na inną wersję. Jest to najczęstsza przyczyna problemów opisanych w błędy instalacji i wersji dsh.

Rynek wtyczek i wartość „selekcji”

dsh posiada rynek wtyczek, który instaluje się jako wtyczka, co wiele mówi o samej architekturze:

dsh plugin --profile web add dshmarket

Po restarcie opcja ta pojawia się w sekcji Settings, a następnie Plugin Market. Plik README jasno określa ograniczenia. Instalacje są ograniczone do źródeł wymienionych w wyselekcjonowanym rejestrze, a każda inna próba jest odrzucana. Skrypty budowania są domyślnie blokowane, a włączenie każdego z nich wymaga zatwierdzenia dla konkretnego pakietu. Wtyczki terminalowe są oznaczane przed dodaniem do profilu webowego. Najważniejsze zdanie mówi o tym, że umieszczenie na liście nie jest równoznaczne z rekomendacją, ponieważ wtyczki są kodem stron trzecich.

Wyselekcjonowana lista podnosi standard bezpieczeństwa. Nie oznacza to jednak, że kod jest sprawdzany za użytkownika, ani że system przewidzi, co zrobi kolejna wersja wtyczki po przejęciu konta przez nowego opiekuna. Instalację jednym kliknięciem należy traktować tak samo, jak traktuje się curl | bash od tego samego autora. Warto powtórzyć jeszcze jeden wiersz z tego pliku README: wyeksportowana kopia zapasowa może zawierać dane uwierzytelniające z konfiguracji profilu, dlatego nigdy nie należy dołączać jej do publicznych zgłoszeń błędów ani wklejać na serwisy typu paste site. Jeśli zamiast metody szukasz gotowej listy na start, wtyczki dsh warte zainstalowania to artykuł uzupełniający do niniejszego wpisu.

Uruchamianie dsh na dedykowanym koncie użytkownika, a nie jako root

Weryfikacja ogranicza częstotliwość występowania incydentów. Zasada najmniejszych uprawnień określa zakres szkód w przypadku naruszenia. Na serwerze VPS wdrożenie tego mechanizmu jest proste.

Utwórz dla narzędzia dedykowane konto użytkownika z własnym katalogiem domowym i nigdy nie uruchamiaj go z uprawnieniami roota:

sudo adduser --disabled-password --gecos "" dshrun
sudo -iu dshrun

W ramach tej sesji uruchom narzędzie, aby zapisywało dane w katalogu domowym tego konta:

npx @deepseek-ai/dsh web

Interfejs webowy domyślnie nasłuchuje na http://127.0.0.1:3080. Pozostaw to ustawienie. Każdy podmiot, który uzyska dostęp do tego portu, może sterować agentem posiadającym dostęp do powłoki, więc wystawienie portu 3080 jest równoznaczne z udostępnieniem zdalnej powłoki bez uprawnień roota z przyjaznym interfejsem. Uzyskaj dostęp z laptopa za pośrednictwem tunelu SSH:

ssh -L 3080:127.0.0.1:3080 you@your-vps

Następnie upewnij się, że żadna usługa nie nasłuchuje na publicznym adresie IP:

ss -lnt | grep 3080

Adres lokalny powinien wskazywać na 127.0.0.1:3080. Jeśli widoczny jest 0.0.0.0:3080, jedyną barierą między niepowołanymi osobami a agentem jest firewall. Argumentacja przedstawiona w bezpiecznym uruchamianiu Claude Code na VPS ma pełne zastosowanie do dsh. Przydziel agentowi jeden katalog roboczy, który może zostać uszkodzony, i przechowuj poza tą maszyną wszelkie dane, których nie można łatwo odtworzyć. Co więcej, traktuj tę maszynę jako jednorazową maszynę wirtualną dla agentów programistycznych, ponieważ ponowna konfiguracja VPS zajmuje godzinę, podczas gdy audyt bezpieczeństwa może trwać tydzień.

Gdzie przechowywane są klucze i dlaczego uprawnienia plików mają ograniczone zastosowanie

dsh przechowuje klucze API w $DSH_HOME/.credentials.yaml, a zmienne środowiskowe w $DSH_HOME/.env, natomiast ustawienia modeli znajdują się w $DSH_HOME/settings.yaml, a historia sesji w $DSH_HOME/storages. Informacje o tym, który klucz należy umieścić w danym pliku oraz jakie dane opuszczają serwer w poszczególnych trybach, zawiera konfiguracja kluczy API, modeli i punktów końcowych dsh. Warto ustalić to przed dodaniem wtyczki, ponieważ każdy skonfigurowany klucz może zostać odczytany przez wtyczkę. Należy zabezpieczyć dwa wrażliwe pliki:

chmod 600 ~/.dsh/.credentials.yaml ~/.dsh/.env
ls -l ~/.dsh

Tryb 600 nadaje właścicielowi uprawnienia do odczytu i zapisu, nie dając nikomu innemu żadnych dostępów, co warto znać w obu notacjach (numeryczne i symboliczne tryby chmod). Należy mieć świadomość realnej ochrony, jaką to zapewnia. Uprawnienia plików chronią je przed innymi kontami na serwerze. Nie stanowią one jednak żadnej ochrony przed wtyczką, ponieważ wtyczka działa jako użytkownik będący właścicielem tych plików, wewnątrz procesu, który je odczytuje. Dlatego utrzymywanie sekretów poza zasięgiem agenta AI oznacza, że w ogóle nie powinno się ich przechowywać na danej maszynie. Serwer z dsh powinien zawierać tylko jeden klucz modelu, którego faktycznie potrzebuje. Poświadczenia chmurowe oraz klucze podpisywania powinny znajdować się w innym miejscu.

Dlaczego wtyczka odczytująca sieć zmienia model zagrożeń

Warstwa sieciowa (Web seam) udostępnia wtyczkom dostawców wyszukiwania i pobierania danych. Wtyczka, która pobiera stronę do sesji, sprowadza tekst, który może zostać napisany przez atakującego. Model promptu nie rozdziela instrukcji od danych, więc pobrana strona może zawierać polecenie skierowane do agenta, a środowisko uruchomieniowe (harness) posiadające uprawnienia powłoki znajduje się o jeden posłuszny krok od jego wykonania.

Kontrola istnieje już wewnątrz środowiska uruchomieniowego. dsh-base, pierwszy pakiet w każdym profilu, dostarcza piaskownicę (sandbox) oraz politykę zatwierdzania. Należy z nich korzystać. Sesja, która może pobierać niezaufane strony, powinna wymagać zatwierdzenia dla każdej operacji zapisu lub wykonania, aby pobrana instrukcja nie mogła samodzielnie stać się działaniem. Blokowanie działań agenta poprzez zatwierdzenia opisuje, jak wyznaczyć granicę tych uprawnień. Relacja działa w obie strony, ponieważ własny serwer jest stroną, którą może pobrać cudzy agent, co jest omawiane w blokowaniu crawlerów AI na własnym serwerze.

Jak sprawdzić, co zmieniła wtyczka?

Należy wykonać migawkę przed instalacją, zainstalować wtyczkę, wykonać migawkę po instalacji, a następnie porównać różnice.

dsh --profile web --dump-config > /tmp/dsh-before.txt
dsh plugin --profile web add '<package-name>@<version>'
dsh --profile web --dump-config > /tmp/dsh-after.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after.txt

Polecenie diff wskazuje, które wpisy wtyczki zostały dodane do drzewa konfiguracji podczas instalacji. Jeśli wtyczka zainstalowana dla jednej drobnej funkcji dodaje wiele wpisów, których przeznaczenia nie można ustalić, należy przerwać proces i przejrzeć kod źródłowy przed uruchomieniem systemu. dsh plugin --profile web why <package-name> odpowiada na drugie pytanie: która z bezpośrednich zależności pobrała dany pakiet.

Zainstalowane pakiety znajdują się w $DSH_HOME/profiles/node_modules, więc można również sprawdzić strukturę drzewa na dysku:

ls ~/.dsh/profiles/node_modules

Należy utrzymywać drugi profil, w którym nie przeprowadza się żadnych eksperymentów. Jeśli instalacja uszkodzi środowisko, uruchomienie dsh --profile <clean-name> w ciągu kilku sekund pozwoli ustalić, czy przyczyną była wtyczka.

Jak usunąć wtyczkę dsh?

dsh plugin --profile web remove '<package-name>'
dsh --profile web --dump-config > /tmp/dsh-after-removal.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after-removal.txt

Usunięcie zależności nie zawsze usuwa konfigurację. Wpisy dodane do pliku cordis.patch.yml profilu pozostają w nim, ponieważ jest to plik użytkownika, a środowisko nie modyfikuje go automatycznie. Należy otworzyć ten plik i usunąć blok wskazujący na usunięty pakiet.

less ~/.dsh/profiles/web/cordis.patch.yml

Następnie należy zająć się kwestią, której nie rozwiąże żadne polecenie odinstalowania. Jeśli wtyczka została usunięta z powodu utraty zaufania, należy założyć, że wszystkie dane, do których miała dostęp, zostały odczytane. Należy wygenerować nowy klucz API DeepSeek w konsoli dostawcy oraz zaktualizować wszelkie inne dane uwierzytelniające przechowywane w $DSH_HOME. Następnie należy zweryfikować, do jakich zasobów w sieci miało dostęp konto użytkownika systemu Unix, na którym uruchomiono wtyczkę.

Skrócona wersja

• Przed instalacją zapoznaj się z opublikowanym archiwum tar, zaczynając od scripts oraz pliku wejściowego.
• Przypnij dokładną wersję lub konkretny commit w przypadku specyfikacji git i zachowaj plik blokady (lockfile).
• Instaluj w ramach jednego profilu i utrzymuj czysty profil, do którego można powrócić w razie awarii.
• Porównuj --dump-config przed i po każdej instalacji.
• Uruchamiaj środowisko testowe (harness) jako osobny użytkownik unix, na interfejsie loopback, z dostępem przez SSH.
• Przechowuj jeden klucz API na serwerze i wymieniaj go w dniu usunięcia wtyczki, której nie ufasz.

Powyższe zalecenia nie stanowią powodu do unikania wtyczek. Model wtyczek sprawia, że dsh jest użyteczny, a środowiska, którego nie można rozszerzyć, nie da się utrzymać w dłuższej perspektywie. Są to powody, dla których należy wiedzieć, co zostało zainstalowane, od kogo, w jakiej wersji oraz uruchamiać całość w środowisku, które można odtworzyć.

FAQ

Czy dsh izoluje wtyczki od siebie w piaskownicy?

Nie. Wtyczka jest ładowana do procesu głównego przez Cordis i uzyskuje dostęp do udokumentowanych interfejsów, w tym powłoki, systemu plików, sieci, podprocesów, podagentów oraz poświadczeń. dsh-base, pierwszy pakiet w każdym profilu, dostarcza piaskownicę oraz politykę zatwierdzania, która określa zakres działań narzędzi agenta; to właśnie ta polityka zapewnia ochronę. Nie istnieje granica uprawnień dla poszczególnych wtyczek, dlatego uczciwym modelem jest założenie, że instalacja wtyczki rozszerza zaufanie na jej autora oraz na każdy pakiet w drzewie zależności.

Czy można zainstalować wtyczkę dsh bez uruchamiania jej skryptów instalacyjnych?

pnpm 10 i nowsze wersje domyślnie blokują skrypty budowania zależności, a dsh plugin ... add przekazuje polecenia do pnpm, więc w aktualnej wersji pnpm instalacja nie uruchamia skryptów pakietu, chyba że użytkownik zatwierdzi dany pakiet. Wersję można potwierdzić za pomocą pnpm --version. Nie czyni to nieprzejrzanej wtyczki bezpieczną. Własny kod wtyczki uruchamia się przy następnym starcie, ponieważ proces główny ładuje ją celowo, na co nie wpływają żadne ograniczenia czasu instalacji.

Gdzie fizycznie znajdują się wtyczki dsh i ich konfiguracja?

$DSH_HOME domyślnie wskazuje na ~/.dsh. Profile znajdują się w $DSH_HOME/profiles/<name>, z których każdy zawiera package.json z zależnościami wtyczek oraz manifest dsh.profile uporządkowanych pakietów, a także warstwę poprawek cordis.patch.yml. Zainstalowane pakiety trafiają do $DSH_HOME/profiles/node_modules. Klucze znajdują się w $DSH_HOME/.credentials.yaml, wartości środowiskowe w $DSH_HOME/.env, a plik $DSH_HOME/cordis.patch.yml na poziomie użytkownika ma zastosowanie do każdego profilu. Uruchom dsh --profile web --dump-config, aby zobaczyć wynik końcowy bez uruchamiania systemu.

Czy instalacja z rynku wtyczek dsh jest bezpieczna?

Rynek ogranicza instalacje do źródeł z wyselekcjonowanego rejestru i blokuje skrypty budowania, chyba że zostaną zatwierdzone dla każdego pakietu z osobna, co stanowi realną poprawę w stosunku do wklejania nazwy pakietu z okna czatu. Własny plik README rynku nadal informuje, że umieszczenie na liście nie jest równoznaczne z rekomendacją, ponieważ wtyczki są kodem stron trzecich stworzonym przez inne osoby. Należy czytać kod źródłowy i przypinać wersje. Proces główny należy utrzymywać na koncie użytkownika, a najlepiej na maszynie, której utrata nie będzie krytyczna.