dsh-Plugins prüfen: Risiken und sichere Installation

Was ist ein dsh-Plugin, und was kann es tun?

dsh-Plugins sind Node-Pakete, die der DeepSeek Harness in seinen eigenen Prozess lädt. Wenn Sie ein Plugin installieren, wird der Code eines Dritten mit den Berechtigungen Ihres Agenten auf dem Computer ausgeführt, den Ihr Agent bereits erreichen kann. Zwischen einem geladenen Plugin und dem restlichen Harness gibt es keine Schutzschicht. Vor der Installation sollten Sie daher klären, auf welche Ressourcen der Code zugreifen kann und wie Sie diesen Zugriff begrenzen.

dsh (DeepSeek Harness) ist das Open-Source-Agent-Harness von DeepSeek AI. Es basiert auf einem Plugin-Framework namens Cordis. Dieses mittlere Wort ist entscheidend: Ein Agent-Harness ist das Programm, das um das Modell herum ausgeführt wird und die Ausführungsschleife, die Tools und die Berechtigungen verwaltet. Ein Plugin wird genau auf dieser Ebene eingebunden. In der README des Projekts steht, dass alles ein Plugin ist. Der Modelladapter ist ein Plugin. Die Weboberfläche, in die Sie Eingaben schreiben, ist ein Plugin. Alles, was Sie außerhalb des Projekts installieren, landet in derselben Struktur und auf derselben Vertrauensstufe wie die mitgelieferten Komponenten. Wenn Sie noch keine Instanz eingerichtet haben, beginnen Sie mit dem DeepSeek Harness auf einem VPS und kehren Sie hierher zurück, bevor Sie etwas hinzufügen.

Die Erweiterungspunkte, die ein Plugin erreichen kann, sind im AGENTS.md des Repositorys aufgeführt. Im August 2026 umfassen sie:

• LLM (Large Language Model): der Anbieter, für den Ihr API-Schlüssel bezahlt
• Shell: die Bash-Funktion mit lokalen und pwsh-Anbietern
• Filesystem: richtliniengesteuerter Dateizugriff
• Web: Anbieter für Suche und Abruf
• Subprocess: ein Anbieter für Prozessbäume
• Workflow: Worker-Threads
• Subagent: Delegation an weitere Agenten
• Settings and credentials: Ihre gespeicherte Konfiguration und Umgebungsvariablen

Ein Plugin registriert außerdem Tools bei ctx.tools. In der Dokumentation wird ausdrücklich erklärt, dass das Schema eines registrierten Tools in die Prompt-Zusammenstellung aufgenommen wird. Dieser zweite Aspekt wird häufig übersehen. Ein Plugin kann beeinflussen, wofür sich Ihr Agent entscheidet, ohne dass sein eigener Code etwas Ungewöhnliches ausführt. Die Beschreibung, die es bereitstellt, wird zu Text, den das Modell liest. Das Problem ist strukturell mit Prompt Injection gegen Coding-Agenten vergleichbar. Der Unterschied besteht darin, dass dieser Text bei der Installation hinzukommt und erhalten bleibt, bis Sie das Plugin entfernen.

Wie findet und lädt dsh Plugins?

Es gibt kein globales Plugin-Verzeichnis. Ein laufendes dsh ist ein beim Booten aus geordneten Ebenen zusammengesetzter Plugin-Baum. Das Profil enthält Ihre Auswahl. $DSH_HOME verwendet standardmäßig ~/.dsh. Jedes Profil liegt in $DSH_HOME/profiles/<name>. Die Profile web und headless werden bei der ersten Verwendung anhand der mitgelieferten Vorlagen angelegt.

Ein Profilverzeichnis enthält zwei Dateien, die das Verhalten vollständig bestimmen:

• package.json mit den Abhängigkeiten der externen Plugins sowie einem dsh.profile-Manifest mit der geordneten Liste bundles
• cordis.patch.yml, Ihre eigene Patch-Ebene über diesen Bundles

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

Beim Booten werden die Ebenen in dieser Reihenfolge angewendet. Spätere Ebenen haben Vorrang:

1. ein leerer Root
2. die Bundles des Profils in der Reihenfolge, in der sie im Manifest aufgeführt sind
3. cordis.patch.yml des Profils
4. $DSH_HOME/cordis.patch.yml
5. alle über die Befehlszeile übergebenen --patch <path>-Overlays

Mit zwei Flags lässt sich das Ergebnis dieser Zusammensetzung ausgeben, ohne etwas zu starten:

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

--dump-default-config gibt den zusammengesetzten Baum allein aus. --dump-config fügt die Profil- und Home-Patch-Ebenen hinzu. Damit ist es einer vollständigen Bestandsaufnahme dessen, was beim nächsten Boot geladen wird, am nächsten. Lesen Sie die Ausgabe, bevor Sie einem übernommenen System vertrauen.

Beachten Sie eine Warnung zu diesen Patch-Dateien. Die Konfiguration ist hier keine passiven Daten, weil das Format !!js-markierte Werte unter dem config-Block eines Plugins erlaubt. Ein aus einem Forum kopierter cordis.patch.yml-Abschnitt ist Code. Behandeln Sie ihn daher wie ein Shell-Skript aus derselben Quelle.

Was führt dsh plugin add tatsächlich aus?

dsh plugin --profile <name> <args> leitet seine Argumente innerhalb des Verzeichnisses des jeweiligen Profils an pnpm weiter. Deshalb muss pnpm in PATH enthalten sein. Die Verben stammen von 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

Das Sicherheitsmodell bei der Installation eines dsh-Plugins entspricht daher dem Sicherheitsmodell bei der Installation jeder npm-ähnlichen Abhängigkeit, ergänzt um einen weiteren Schritt: Das Ergebnis wird in Ihren Agenten geladen. Das Paket bringt seinen eigenen Abhängigkeitsbaum mit. Jedes Paket in diesem Baum läuft im selben Prozess. Alles unter wie npm-Lieferkettenangriffe einen Server erreichen gilt hier unverändert.

pnpm 10 und höher führen die Build-Skripte einer Abhängigkeit standardmäßig nicht aus. Die Freigabe erfolgt pro Paket über onlyBuiltDependencies oder pnpm approve-builds. Prüfen Sie, welche pnpm-Version installiert ist:

pnpm --version

Diese Standardeinstellung ist sinnvoll. Sie ist zugleich die Sicherheitsfunktion im Ökosystem, die am häufigsten überschätzt wird. Blockierte Build-Skripte verhindern die Codeausführung während der Installation. Gegen das Plugin selbst bewirken sie nichts. Denn der Zweck eines Plugins besteht darin, dass der Harness es importiert und beim nächsten Start aufruft. Ein Plugin benötigt keinen postinstall-Hook. Es wurde ausdrücklich eingebunden.

Lesen Sie dies, bevor Sie ein dsh-Plugin installieren

Laden Sie das veröffentlichte Tarball herunter und lesen Sie es. Beim Entpacken eines Archivs wird nichts ausgeführt.

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

Die vier Felder in diesem package.json liefern Ihnen fast alle benötigten Informationen. Lesen Sie scripts für preinstall-, install- und postinstall-Einträge. Lesen Sie dependencies bei Namen, die Sie nicht erkennen, oder bei Namen, die sich nur durch ein Zeichen von bekannten Namen unterscheiden. Lesen Sie bin für alles, was das Paket in Ihrem PATH erwartet. Lesen Sie main oder exports für die Einstiegsdatei. Öffnen Sie diese Datei anschließend und gehen Sie den darin beschriebenen Ablauf durch.

Lesen Sie danach den Code, der tatsächlich geladen wird. Ein Plugin, das ein Benachrichtigungswerkzeug bereitstellt, muss keinen ~/.ssh lesen, keinen Ihnen unbekannten Host kontaktieren und keine Shell starten. Wenn das Paket ausschließlich gebündeltes oder minimiertes JavaScript enthält und kein passender Quellcode in einem öffentlichen Repository vorhanden ist, ist das bereits eine klare Aussage. Bevorzugen Sie Plugins, deren Quellcode Sie lesen können, und bevorzugen Sie kleine Plugins.

Sie können die Registry auch ohne Installation prüfen:

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

Ein Paket, das letzte Woche veröffentlicht wurde, nur eine Version hat, kein Repository-Feld enthält und dessen Name einen bekannten Namen nachahmt, folgt dem ältesten Trick jeder Registry. Downloads mit Prüfsummen verifizieren gehört zur gleichen Vorgehensweise: Sie müssen genau wissen, was Sie heruntergeladen haben, bevor Sie es ausführen lassen.

Version festlegen und Lockfile beibehalten

Ein freier Versionsbereich bedeutet, dass sich der Code im Prozess Ihres Agents bei jeder Installation oder Aktualisierung ändern kann, ohne dass Sie dies entscheiden. Legen Sie die Version fest.

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

Die Position der Flags unterscheidet sich zwischen pnpm-Versionen. Prüfen Sie daher das Ergebnis, statt dem Befehl zu vertrauen. Öffnen Sie anschließend das package.json-Profil und stellen Sie sicher, dass die Abhängigkeit als reine Version ohne vorangestelltes ^ oder ~ eingetragen ist. Diese Datei bestimmt, was installiert wird.

Behalten Sie anschließend das Lockfile bei. Es legt den gesamten transitiven Abhängigkeitsbaum fest, nicht nur den Namen der obersten Abhängigkeit:

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

Kopieren Sie die Datei an einen Ort, den Sie sichern, zusammen mit dem package.json des Profils. Mit diesen beiden Dateien können Sie auf einem neuen System denselben Abhängigkeitsbaum wiederherstellen. Führen Sie dsh plugin --profile web update nur aus, wenn Sie Versionen ändern möchten, nicht zur routinemäßigen Bereinigung. Lesen Sie danach den Diff des Lockfiles.

Bei einem Plugin, das aus Git statt aus einer Registry installiert wird, legen Sie den Commit anstelle des Branches fest. Eine Spezifikation der Form github:owner/repo#<full commit sha> ergibt einen festen Abhängigkeitsbaum. Ein Branchname verwendet beim nächsten Auflösen durch pnpm den Inhalt dieses Branches. Damit überlassen Sie diese Entscheidung einer anderen Person. Für das Harness gilt dieselbe Disziplin. Jeder veröffentlichte dsh-Build ist ein Release Candidate. Eine nicht festgelegte Installation kann an jedem Tag einen anderen Build auflösen. Das ist die häufigste Ursache für Installations- und Versionsfehler bei dsh.

Der Plugin-Markt und der Wert von „kuratiert“

dsh verfügt über einen Plugin-Markt und wird als Plugin installiert. Das sagt etwas über die Architektur aus:

dsh plugin --profile web add dshmarket

Nach einem Neustart erscheint der Eintrag unter Settings und anschließend unter Plugin Market. Die README beschreibt die Einschränkungen eindeutig. Installationen sind auf Quellen beschränkt, die in einer kuratierten Registry aufgeführt sind. Alles andere wird abgelehnt. Build-Skripte sind standardmäßig blockiert. Ihre Aktivierung erfordert eine Freigabe pro Paket. Terminal-Plugins werden geprüft, bevor sie in ein Webprofil übernommen werden. Der wichtigste Satz lautet, dass eine Aufnahme keine Empfehlung darstellt, weil es sich bei den Plugins um Code von Drittanbietern handelt.

Eine kuratierte Liste erhöht das Mindestsicherheitsniveau. Sie prüft den Code jedoch nicht für Sie. Außerdem kann sie nicht vorhersagen, was die nächste Version eines Plugins tut, nachdem der Maintainer-Account den Besitzer gewechselt hat. Behandeln Sie eine Installation per Mausklick genauso wie curl | bash desselben Autors. Ein weiterer Satz aus dieser README verdient Wiederholung: Ein exportiertes Backup kann Zugangsdaten aus Ihrer Profilkonfiguration enthalten. Hängen Sie es daher niemals an ein öffentliches Issue an und fügen Sie es nicht auf einer Paste-Site ein. Wenn Sie statt einer Methode eine Einstiegsliste suchen, ist dsh-Plugins, die sich zur Installation lohnen der ergänzende Beitrag zu diesem Thema.

dsh unter einem eigenen Benutzer ausführen, nicht als root

Die Prüfung verringert, wie häufig etwas Schädliches eindringt. Das Prinzip der geringsten Rechte legt fest, worauf es zugreifen kann, wenn es dennoch gelingt. Auf einem VPS ist dieser zweite Teil mit wenig Aufwand eingerichtet.

Geben Sie dem Harness ein eigenes Unix-Konto mit einem eigenen Home-Verzeichnis. Führen Sie ihn niemals als root aus:

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

Starten Sie den Harness innerhalb dieser Sitzung, damit er sein Home-Verzeichnis unter diesem Konto verwendet:

npx @deepseek-ai/dsh web

Die Weboberfläche ist standardmäßig unter http://127.0.0.1:3080 erreichbar. Belassen Sie es dabei. Wenn Sie den ausgegebenen Link schon einmal von einem anderen Rechner aus angeklickt haben und keine Antwort erhalten haben, erklärt was dsh mit der Ausgabe dieser Adresse meint den Grund. Jeder, der diesen Port erreicht, kann einen Agenten mit Shell-Zugriff steuern. Die Veröffentlichung von Port 3080 entspricht daher der Veröffentlichung einer Root-losen Remote-Shell mit einer benutzerfreundlichen Oberfläche. Greifen Sie stattdessen über einen SSH-Tunnel von Ihrem Laptop darauf zu:

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

Bestätigen Sie anschließend, dass kein Dienst an einer öffentlichen Adresse lauscht:

ss -lnt | grep 3080

Die lokale Adresse sollte 127.0.0.1:3080 lauten. Wenn dort 0.0.0.0:3080 steht, ist Ihre Firewall das Einzige, was einen Fremden von Ihrem Agenten trennt. Die Überlegungen hinter Claude Code sicher auf einem VPS ausführen gelten unverändert für dsh. Geben Sie dem Agenten ein einziges Arbeitsverzeichnis, das er beschädigen darf, und bewahren Sie alles, was Sie nicht neu erstellen können, außerhalb dieses Rechners auf. Noch besser ist es, den Rechner als wegwerfbare VM für Coding-Agenten zu behandeln, denn das Neuerstellen eines VPS kostet eine Stunde, während die Prüfung eines solchen Systems eine Woche dauert.

Wo Ihre Schlüssel liegen und warum Dateiberechtigungen allein nicht ausreichen

dsh speichert API-Schlüssel in $DSH_HOME/.credentials.yaml und Umgebungsvariablen in $DSH_HOME/.env. Modelleinstellungen liegen in $DSH_HOME/settings.yaml und der Sitzungsverlauf unter $DSH_HOME/storages. Welche Schlüssel in welche dieser Dateien gehören und welche Daten in den einzelnen Modi tatsächlich den Rechner verlassen, wird unter API-Schlüssel, Modelle und Endpunkte in dsh konfigurieren beschrieben. Das sollten Sie klären, bevor Sie ein Plugin hinzufügen. Jeder Schlüssel, den Sie einbinden, ist eine weitere Information, die ein Plugin lesen kann. Schränken Sie den Zugriff auf die beiden sensiblen Dateien ein:

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

Der Modus 600 erlaubt dem Besitzer das Lesen und Schreiben und allen anderen den Zugriff. Das ist sowohl in numerischer als auch in symbolischer Schreibweise wichtig (Numerische und symbolische chmod-Modi). Sie sollten den Schutz realistisch bewerten. Dateimodi schützen diese Dateien vor anderen Konten auf dem Rechner. Gegen ein Plugin schützen sie nicht, weil das Plugin als derselbe Benutzer wie der Besitzer der Dateien und innerhalb des Prozesses ausgeführt wird, der die Dateien liest. Deshalb bedeutet Geheimnisse außerhalb der Reichweite eines KI-Agenten halten, dass Sie die Geheimnisse überhaupt nicht auf dem Rechner speichern. Auf einem dsh-Rechner sollte nur der eine benötigte Modellschlüssel liegen. Ihre Cloud-Zugangsdaten und Ihre Signaturschlüssel gehören an einen anderen Ort.

Warum ein Plugin, das das Web liest, das Bedrohungsmodell verändert

Die Web-Schnittstelle stellt Plugins Such- und Abrufanbieter bereit. Ein Plugin, das eine Seite in Ihre Sitzung lädt, lädt Text, den ein Angreifer schreiben kann. Ein Modell-Prompt trennt Anweisungen nicht von Daten. Eine abgerufene Seite kann daher eine Zeile enthalten, die an Ihren Agenten gerichtet ist. Ein Harness mit Shell-Berechtigung ist dann nur noch einen folgsamen Schritt davon entfernt, diese Zeile auszuführen.

Die Steuerung ist im Harness bereits vorhanden. dsh-base, das erste Bundle in jedem Profil, liefert die Sandbox und die Genehmigungsrichtlinie. Verwenden Sie sie. Eine Sitzung, die nicht vertrauenswürdige Seiten abrufen kann, sollte für alle Aktionen, die Daten schreiben oder Befehle ausführen, eine Genehmigung verlangen. So kann eine abgerufene Anweisung nicht selbstständig zu einer Aktion werden. Agentenaktionen hinter Genehmigungen absichern erläutert, wie Sie festlegen, an welcher Stelle diese Grenze verläuft. Die Beziehung gilt auch in die andere Richtung: Ihr eigener Server ist eine Seite, die der Agent einer anderen Person abruft. Das ist der Anwendungsfall für KI-Crawler auf Ihrem Server blockieren.

Wie prüfe ich, was ein Plugin geändert hat?

Erstellen Sie einen Snapshot vor der Installation, installieren Sie das Plugin, erstellen Sie einen zweiten Snapshot und lesen Sie anschließend den Unterschied.

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

Der Diff zeigt, welche Plugin-Einträge die Installation zum zusammengesetzten Baum hinzugefügt hat. Wenn ein Plugin, das Sie für eine kleine Funktion installiert haben, mehrere Einträge hinzufügt, die Sie nicht erklären können, sollten Sie den Vorgang stoppen und den Quellcode lesen, bevor Sie das Plugin starten. dsh plugin --profile web why <package-name> beantwortet die andere Frage: Welche Ihrer direkten Abhängigkeiten hat ein bestimmtes Paket eingebunden?

Installierte Pakete werden unter $DSH_HOME/profiles/node_modules abgelegt. Sie können den Baum daher auch auf dem Datenträger prüfen:

ls ~/.dsh/profiles/node_modules

Verwenden Sie ein zweites Profil, in dem Sie nie experimentieren. Wenn eine Installation das Harness beschädigt, zeigt der Start von dsh --profile <clean-name> innerhalb weniger Sekunden, ob das Plugin die Ursache war.

Wie entferne ich ein dsh-Plugin?

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

Durch das Entfernen der Abhängigkeit wird die Konfiguration nicht immer entfernt. Einträge in cordis.patch.yml des Profils bleiben bestehen, weil diese Datei Ihnen gehört und das Harness sie nicht für Sie neu schreibt. Öffnen Sie die Datei und löschen Sie jeden Block, in dem das entfernte Paket genannt wird.

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

Danach müssen Sie sich mit dem Teil befassen, den kein Deinstallationsbefehl beheben kann. Wenn Sie ein Plugin entfernt haben, weil Sie ihm nicht mehr vertrauen, hat es bereits alles gelesen, worauf es zugreifen konnte. Ersetzen Sie den DeepSeek API-Schlüssel in der Provider-Konsole und erneuern Sie alle anderen Schlüssel oder Zugangsdaten, die in $DSH_HOME gespeichert waren. Ermitteln Sie anschließend, worauf das Unix-Konto, unter dem das Plugin ausgeführt wurde, im restlichen Netzwerk zugreifen konnte.

Die Kurzfassung

• Lesen Sie das veröffentlichte Tarball vor der Installation, beginnend bei scripts und der Einstiegsdatei
• Fixieren Sie die genaue Version oder bei einer git-Spezifikation den genauen Commit und behalten Sie die Lockdatei
• Installieren Sie in einem Profil und halten Sie ein sauberes Profil bereit, das Sie starten können, wenn etwas ausfällt
• Vergleichen Sie --dump-config vor und nach jeder Installation
• Führen Sie den Harness als eigenen Unix-Benutzer auf dem Loopback-Interface aus und greifen Sie über SSH darauf zu
• Bewahren Sie einen API-Schlüssel auf dem System auf und rotieren Sie ihn an dem Tag, an dem Sie ein Plugin entfernen, dem Sie nicht mehr vertrauen

Nichts davon ist ein Grund, Plugins zu vermeiden. Das Plugin-Modell macht dsh nützlich, und ein Harness, den Sie nicht erweitern können, werden Sie ersetzen. Es ist ein Grund, zu wissen, was Sie installiert haben, von wem es stammt und in welcher Version, und alles an einem Ort auszuführen, den Sie neu erstellen können.

FAQ

Isoliert dsh Plugins voneinander?

Nein. Ein Plugin wird über Cordis in den Harness-Prozess geladen und kann die dokumentierten Zugriffsschnittstellen erreichen, darunter Shell, Dateisystem, Web, Subprozesse, Subagenten und Zugangsdaten. dsh-base, das erste Bundle in jedem Profil, liefert die Sandbox- und Genehmigungsrichtlinie, die festlegt, was die Tools des Agenten tun dürfen. Diese Richtlinie bietet den eigentlichen Schutz. Es gibt keine Berechtigungsgrenze zwischen einzelnen Plugins. Das korrekte Sicherheitsmodell lautet daher, dass die Installation eines Plugins Ihr Vertrauen auf dessen Autor und auf jedes Paket in seinem Abhängigkeitsbaum ausdehnt.

Kann ich ein dsh Plugin installieren, ohne dessen Installationsskripte auszuführen?

pnpm 10 und spätere Versionen blockieren Build-Skripte von Abhängigkeiten standardmäßig. dsh plugin ... add verwendet pnpm, daher führt eine aktuelle pnpm-Version bei der Installation keine Paketskripte aus, sofern Sie das jeweilige Paket nicht genehmigen. Prüfen Sie Ihre Version mit pnpm --version. Dadurch wird ein ungeprüftes Plugin nicht sicher. Der eigene Code des Plugins wird beim nächsten Boot ausgeführt, weil der Harness ihn bewusst lädt. Keine Einschränkung während der Installation verhindert das.

Wo befinden sich dsh Plugins und ihre Konfiguration tatsächlich?

$DSH_HOME verwendet standardmäßig ~/.dsh. Profile befinden sich in $DSH_HOME/profiles/<name>. Jedes Profil enthält ein package.json mit seinen Plugin-Abhängigkeiten sowie das dsh.profile-Manifest der geordneten Bundles und eine cordis.patch.yml-Patch-Ebene. Installierte Pakete werden unter $DSH_HOME/profiles/node_modules abgelegt. Schlüssel befinden sich in $DSH_HOME/.credentials.yaml, Umgebungswerte in $DSH_HOME/.env. Ein $DSH_HOME/cordis.patch.yml auf Benutzerebene gilt für jedes Profil. Führen Sie dsh --profile web --dump-config aus, um das zusammengeführte Ergebnis ohne Boot anzuzeigen.

Ist die Installation aus dem dsh-Plugin-Markt sicher?

Der Markt beschränkt Installationen auf Quellen in einer kuratierten Registry und blockiert Build-Skripte, sofern Sie sie nicht für das jeweilige Paket genehmigen. Das ist eine deutliche Verbesserung gegenüber dem Einfügen eines Paketnamens aus einem Chatfenster. In der README des Markts steht weiterhin, dass eine Aufnahme keine Empfehlung darstellt, weil die Plugins Drittanbietercode von anderen Personen enthalten. Lesen Sie den Quellcode und fixieren Sie die Version. Betreiben Sie den Harness unter einem Benutzerkonto und idealerweise auf einer Maschine, deren Verlust Sie verkraften können.