راهنمای بررسی امنیت پلاگین‌های dsh در DeepSeek Harness

پلاگین dsh چیست و چه کاری انجام می‌دهد؟

پلاگین‌های dsh بسته‌های Node هستند که DeepSeek Harness آن‌ها را در پردازش خود بارگذاری می‌کند. نصب یک پلاگین به معنای اجرای کد شخص ثالث با مجوزهای agent شما و روی ماشینی است که agent شما به آن دسترسی دارد. هیچ مانعی بین یک پلاگین بارگذاری‌شده و سایر بخش‌های harness وجود ندارد. بنابراین، پیش از نصب هر پلاگین، باید بپرسید که آن کد به چه منابعی دسترسی دارد و چگونه می‌توانید این سطح دسترسی را محدود نگه دارید.

dsh (مخفف DeepSeek Harness) یک harness متن‌باز برای agentهای DeepSeek AI است که بر پایه یک چارچوب پلاگین به نام Cordis ساخته شده است. در فایل README خود پروژه ذکر شده که همه‌چیز یک پلاگین است. آداپتور مدل یک پلاگین است. رابط وب که در آن تایپ می‌کنید نیز یک پلاگین است. هر چیزی که از خارج از پروژه نصب می‌کنید، در همان ساختار درختی و با همان سطح اعتمادِ بخش‌های پیش‌فرض پروژه قرار می‌گیرد. اگر هنوز آن را راه‌اندازی نکرده‌اید، ابتدا با DeepSeek Harness روی یک VPS شروع کنید و پیش از افزودن هرگونه افزونه، به اینجا بازگردید.

نقاط توسعه (extension points) که یک پلاگین می‌تواند به آن‌ها دسترسی داشته باشد، در AGENTS.md مخزن فهرست شده‌اند. تا اوت 2026، این موارد شامل موارد زیر هستند:

• LLM (مدل زبانی بزرگ): ارائه‌دهنده‌ای که هزینه آن را با API key خود پرداخت می‌کنید
• Shell: قابلیت bash، با ارائه‌دهنده‌های local و pwsh
• Filesystem: دسترسی به فایل‌ها با کنترل سیاست‌گذاری (policy-controlled)
• Web: ارائه‌دهنده‌های جستجو و دریافت محتوا
• Subprocess: ارائه‌دهنده درخت پردازش (process-tree)
• Workflow: ترد‌های کاری (worker threads)
• Subagent: تفویض وظایف به agentهای دیگر
• Settings and credentials: پیکربندی ذخیره‌شده و متغیرهای محیطی شما

یک پلاگین همچنین ابزارهایی را در ctx.tools ثبت می‌کند و مستندات به‌صراحت بیان می‌کنند که طرحواره (schema) یک ابزار ثبت‌شده به فرآیند جمع‌آوری پرامپت (prompt assembly) اضافه می‌شود. این بخش دوم همان نکته‌ای است که بسیاری از کاربران نادیده می‌گیرند. یک پلاگین می‌تواند تصمیمات agent شما را تغییر دهد، بدون اینکه کد آن کار غیرعادی انجام دهد؛ زیرا توضیحی که پلاگین ارائه می‌دهد، به متنی تبدیل می‌شود که مدل آن را می‌خواند. این دقیقاً همان نوع مشکلی است که در تزریق پرامپت علیه agentهای کدنویس وجود دارد، با یک تفاوت: این متن هنگام نصب وارد می‌شود و تا زمانی که پلاگین را حذف نکنید، باقی می‌ماند.

dsh چگونه پلاگین‌ها را پیدا و بارگذاری می‌کند؟

هیچ دایرکتوری سراسری برای پلاگین‌ها وجود ندارد. یک dsh در حال اجرا، یک درخت پلاگین است که در زمان بوت از لایه‌های مرتب‌شده تشکیل می‌شود و واحدی که انتخاب‌های شما را در خود نگه می‌دارد، یک profile است. $DSH_HOME به‌طور پیش‌فرض روی ~/.dsh تنظیم شده است و هر profile در $DSH_HOME/profiles/<name> قرار دارد. پروفایل‌های web و headless در اولین استفاده از روی قالب‌های پیش‌فرض (shipped templates) خود را ایجاد می‌کنند.

یک دایرکتوری profile شامل دو فایل است که همه‌چیز را تعیین می‌کنند:

• package.json، که شامل وابستگی‌های پلاگین خارج از درخت (out-of-tree) به همراه یک مانیفست dsh.profile است که لیست مرتب‌شده bundles را حمل می‌کند.
• cordis.patch.yml، که لایه وصله (patch) شخصی شما روی آن بسته‌هاست.

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

فرآیند بوت، لایه‌ها را به این ترتیب اعمال می‌کند و لایه‌های بعدی بر لایه‌های قبلی اولویت دارند:

1. یک ریشه خالی
2. بسته‌های پروفایل، به ترتیبی که مانیفست آن‌ها را لیست کرده است
3. فایل cordis.patch.yml پروفایل
4. $DSH_HOME/cordis.patch.yml
5. هرگونه overlay مربوط به --patch <path> که در خط فرمان پاس داده شده باشد

دو فلگ، نتیجه این ترکیب را بدون اجرای هیچ فرآیندی چاپ می‌کنند:

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

--dump-default-config درخت ترکیب‌شده را به‌تنهایی چاپ می‌کند. --dump-config لایه‌های پروفایل و وصله‌های خانگی (home patch) را اضافه می‌کند، بنابراین این نزدیک‌ترین ابزار به یک فهرست صادقانه از چیزی است که بوت بعدی شما بارگذاری خواهد کرد. پیش از اعتماد به ماشینی که به ارث برده‌اید، آن را بخوانید.

یک هشدار درباره آن فایل‌های وصله: پیکربندی در اینجا داده‌های بی‌اثر (inert) نیست، زیرا فرمت فایل اجازه می‌دهد مقادیر برچسب‌گذاری‌شده با !!js در زیر بلوک config یک پلاگین قرار گیرند. یک قطعه کد cordis.patch.yml که از یک پست در انجمن کپی شده است، در واقع یک کد اجرایی است؛ بنابراین با آن همان‌طور رفتار کنید که با یک اسکریپت shell از همان منبع رفتار می‌کنید.

dsh plugin add دقیقاً چه چیزی را اجرا می‌کند؟

dsh plugin --profile <name> <args> آرگومان‌های خود را به pnpm در دایرکتوری آن پروفایل ارسال می‌کند، بنابراین pnpm باید در PATH موجود باشد. افعال (verbs) همان افعال 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

بنابراین، مدل امنیتی نصب یک افزونه dsh، همان مدل امنیتی نصب هر وابستگی (dependency) به سبک npm است، به‌علاوه یک مرحله اضافی که در آن نتیجه در agent شما بارگذاری می‌شود. این بسته، درخت وابستگی‌های خاص خود را به همراه می‌آورد و هر بسته در آن درخت در نهایت در همان پردازش (process) قرار می‌گیرد. هر آنچه در چگونگی نفوذ حملات زنجیره تأمین npm به سرور آمده است، بدون تغییر در اینجا نیز صدق می‌کند.

نسخه 10 و بالاتر pnpm به‌طور پیش‌فرض اسکریپت‌های build یک وابستگی را اجرا نمی‌کنند و تأییدیه برای هر بسته از طریق onlyBuiltDependencies یا pnpm approve-builds انجام می‌شود. بررسی کنید که کدام نسخه از pnpm را دارید:

pnpm --version

این تنظیم پیش‌فرض ارزشمند است و در عین حال، بیش از حد نادیده گرفته‌شده‌ترین ویژگی امنیتی در این اکوسیستم محسوب می‌شود. مسدود کردن اسکریپت‌های build مانع از اجرای کد در حین نصب می‌شود. این کار هیچ تأثیری بر خودِ افزونه ندارد، زیرا هدف اصلی یک افزونه این است که harness آن را import کرده و در boot بعدی فراخوانی کند. یک افزونه نیازی به hook در postinstall ندارد. آن افزونه از قبل دعوت شده است.

پیش از نصب یک افزونه dsh چه چیزی را باید مطالعه کرد

فایل tarball منتشرشده را دانلود کرده و آن را مطالعه کنید. با استخراج یک آرشیو، هیچ کدی اجرا نمی‌شود.

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

چهار فیلد در آن package.json، بیشتر اطلاعات مورد نیاز شما را در اختیارتان می‌گذارد. برای ورودی‌های preinstall، install و postinstall، فایل scripts را مطالعه کنید. برای نام‌هایی که نمی‌شناسید یا نام‌هایی که تنها یک کاراکتر با نام‌های آشنا تفاوت دارند، dependencies را بخوانید. برای هر چیزی که بسته در مسیر PATH شما نیاز دارد، bin را بررسی کنید. برای یافتن فایل ورودی، main یا exports را بخوانید، سپس آن فایل را باز کرده و محتوای آن را دنبال کنید.

سپس کدی که قرار است بارگذاری شود را مطالعه کنید. افزونه‌ای که ابزار اعلان (notification) تبلیغ می‌کند، دلیلی ندارد که ~/.ssh را بخواند، با میزبانی که هرگز نامش را نشنیده‌اید تماس بگیرد یا یک shell ایجاد کند. اگر بسته فقط شامل JavaScript باندل‌شده یا minified باشد و هیچ سورس‌کد مشابهی در مخزن عمومی وجود نداشته باشد، این خود پاسخ شماست. افزونه‌هایی را ترجیح دهید که سورس‌کد آن‌ها قابل خواندن است و افزونه‌های کوچک‌تر را در اولویت قرار دهید.

شما همچنین می‌توانید بدون نصب هیچ چیزی، از registry پرس‌وجو کنید:

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

بسته‌ای که هفته گذشته منتشر شده، تنها یک نسخه دارد، فیلد repository در آن خالی است و نامی دارد که مشابه یک ابزار محبوب است، قدیمی‌ترین ترفند در هر registry محسوب می‌شود. تأیید دانلودها با استفاده از checksum عادتی است که باید در کنار این کار داشته باشید: پیش از آنکه اجازه دهید چیزی اجرا شود، دقیقاً بدانید چه چیزی دریافت کرده‌اید.

نسخه را ثابت (Pin) کنید و فایل lockfile را نگه دارید

محدودهٔ نسخهٔ شناور (floating version range) به این معناست که کد داخل پردازش agent شما می‌تواند در هر بار نصب یا به‌روزرسانی، بدون تصمیم شما تغییر کند. آن را ثابت (Pin) کنید.

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

محل قرارگیری flagها در نسخه‌های مختلف pnpm متفاوت است، بنابراین به‌جای اعتماد به دستور، نتیجه را بررسی کنید. پس از آن، فایل package.json پروفایل را باز کنید و تأیید کنید که dependency به‌صورت یک نسخهٔ خالص و بدون هیچ ^ یا ~ در ابتدای آن درج شده باشد. آن فایل تعیین می‌کند که چه چیزی نصب شود.

سپس فایل lockfile را نگه دارید؛ این فایل کل درخت transitive را ثابت می‌کند، نه فقط نام سطح بالا (top-level) را:

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

آن را به همراه package.json پروفایل در جایی که از آن نسخهٔ پشتیبان تهیه می‌کنید، کپی کنید. این دو فایل، همان درخت را روی یک سیستم جدید بازسازی می‌کنند. دستور dsh plugin --profile web update را فقط زمانی اجرا کنید که تصمیم به تغییر نسخه‌ها گرفته‌اید؛ هرگز آن را به عنوان یک کار روتین برای مرتب‌سازی انجام ندهید و پس از آن، تفاوت‌های (diff) فایل lockfile را مطالعه کنید.

برای پلاگینی که به‌جای registry از git نصب شده است، به‌جای branch، commit را ثابت کنید. یک spec به فرم github:owner/repo#<full commit sha> به شما یک درخت ثابت می‌دهد. نام branch باعث می‌شود در هر بار که pnpm آن را resolve می‌کند، هر آنچه در آن branch قرار دارد نصب شود؛ این تصمیمی است که شما به شخص دیگری واگذار کرده‌اید. خودِ harness نیز به همین انضباط نیاز دارد، زیرا هر build منتشرشدهٔ dsh یک release candidate محسوب می‌شود و یک نصبِ بدون نسخهٔ ثابت (unpinned) ممکن است در هر روز به نسخهٔ متفاوتی resolve شود؛ این همان جایی است که اکثر خطاهای نصب و نسخه dsh از آن ناشی می‌شوند.

بازار افزونه‌ها و ارزش «گزینش‌شده» بودن

dsh دارای یک بازارچه است که به‌صورت یک افزونه نصب می‌شود؛ این موضوع نکته‌ای را درباره معماری آن آشکار می‌کند:

dsh plugin --profile web add dshmarket

پس از یک راه‌اندازی مجدد، این بخش در مسیر Settings و سپس Plugin Market ظاهر می‌شود. فایل README آن به‌صراحت محدودیت‌ها را بیان می‌کند. نصب‌ها تنها به منابع موجود در یک رجیستری گزینش‌شده (curated) محدود هستند و هر منبع دیگری رد می‌شود. اسکریپت‌های ساخت (build scripts) به‌صورت پیش‌فرض مسدود شده‌اند و فعال‌سازی هر یک از آن‌ها نیازمند تأیید جداگانه برای هر بسته است. افزونه‌های ترمینال پیش از آنکه وارد یک پروفایل وب شوند، نشان‌گذاری (flag) می‌شوند. مهم‌ترین جمله‌ای که باید به آن توجه کرد این است که قرار گرفتن در لیست به معنای تأییدیه نیست، زیرا افزونه‌ها کدهای شخص ثالث هستند.

یک لیست گزینش‌شده، حداقل سطح امنیت را ارتقا می‌دهد. این لیست کدها را برای شما بازبینی نمی‌کند و نمی‌تواند پیش‌بینی کند که نسخه بعدی یک افزونه پس از تغییر مالکیت حساب نگهداری‌کننده (maintainer) چه رفتاری خواهد داشت. با نصب‌های تک‌کلیکی همان‌طور رفتار کنید که با curl | bash از همان نویسنده رفتار می‌کنید. یک خط دیگر از آن فایل README ارزش تکرار دارد: یک نسخه پشتیبان صادرشده (exported backup) ممکن است حاوی اعتبارنامه‌هایی از تنظیمات پروفایل شما باشد، بنابراین هرگز آن را به یک issue عمومی یا سایت‌های اشتراک‌گذاری متن (paste site) پیوست نکنید. اگر به‌جای روش کار، به دنبال لیستی برای شروع هستید، افزونه‌های dsh که ارزش نصب دارند پست مکمل این مطلب است.

اجرای dsh با کاربر اختصاصی، نه به عنوان root

بررسی دقیق، احتمال نفوذ موارد مخرب را کاهش می‌دهد. اصل حداقل دسترسی (Least Privilege) تعیین می‌کند که در صورت وقوع نفوذ، چه بخش‌هایی در معرض خطر قرار می‌گیرند. در یک VPS، پیاده‌سازی این اصل بسیار کم‌هزینه است.

برای این ابزار یک حساب کاربری یونیکس مجزا با دایرکتوری home اختصاصی ایجاد کنید و هرگز آن را با دسترسی root اجرا نکنید:

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

در آن نشست، ابزار را طوری اجرا کنید که فایل‌های خود را در دایرکتوری home همان کاربر بنویسد:

npx @deepseek-ai/dsh web

رابط کاربری وب به‌صورت پیش‌فرض روی http://127.0.0.1:3080 سرویس می‌دهد. آن را در همان وضعیت باقی بگذارید. هر چیزی که به این پورت دسترسی پیدا کند، می‌تواند عاملی (agent) را کنترل کند که دارای shell است؛ بنابراین انتشار پورت 3080 معادل انتشار یک shell از راه دور بدون دسترسی root اما با رابط کاربری کاربرپسند است. به جای آن، از طریق یک تونل SSH از لپ‌تاپ خود به آن متصل شوید:

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

سپس تأیید کنید که هیچ سرویسی روی آدرس عمومی گوش نمی‌دهد:

ss -lnt | grep 3080

آدرس محلی باید 127.0.0.1:3080 باشد. اگر آدرس 0.0.0.0:3080 را مشاهده کردید، فایروال شما تنها مانع بین یک غریبه و عامل شماست. منطق پشت اجرای ایمن Claude Code روی VPS برای dsh نیز بدون تغییر صدق می‌کند. به عامل تنها یک دایرکتوری کاری بدهید که اجازه تخریب آن را داشته باشد و هر چیزی را که نمی‌توانید دوباره بازسازی کنید، از آن ماشین دور نگه دارید. حتی بهتر است با آن ماشین مانند یک VM یک‌بارمصرف برای عامل‌های برنامه‌نویسی رفتار کنید، زیرا بازسازی یک VPS یک ساعت زمان می‌برد، در حالی که بررسی امنیتی آن ممکن است یک هفته طول بکشد.

محل نگهداری کلیدها و محدودیت‌های مجوز فایل

ابزار dsh کلیدهای API را در $DSH_HOME/.credentials.yaml و مقادیر محیطی را در $DSH_HOME/.env، تنظیمات مدل را در $DSH_HOME/settings.yaml و تاریخچه نشست‌ها را در $DSH_HOME/storages ذخیره می‌کند. اینکه کدام کلید به کدام فایل تعلق دارد و در هر حالت چه داده‌ای از سیستم خارج می‌شود، موضوع پیکربندی کلیدهای API، مدل‌ها و اندپوینت‌های dsh است. بهتر است پیش از افزودن هر افزونه (plugin)، این موارد را مشخص کنید، زیرا هر کلیدی که وارد می‌کنید، در دسترس افزونه قرار می‌گیرد. دسترسی به دو فایل حساس را محدود کنید:

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

حالت 600 به مالک اجازه خواندن و نوشتن می‌دهد و دسترسی سایر کاربران را کاملاً مسدود می‌کند؛ دانستن این موضوع در هر دو نماد حالت‌های عددی در برابر نمادین chmod مفید است. واقع‌بین باشید که این کار چه دستاوردی دارد. مجوزهای فایل، این فایل‌ها را از سایر حساب‌های کاربری روی سیستم محافظت می‌کنند. اما در برابر یک افزونه هیچ کاری انجام نمی‌دهند، زیرا افزونه با همان کاربری اجرا می‌شود که مالک فایل‌هاست و در همان فرآیندی اجرا می‌شود که فایل‌ها را می‌خواند. به همین دلیل است که دور نگه داشتن اسرار از دسترس یک عامل هوش مصنوعی به معنای عدم ذخیره آن‌ها روی دستگاه است. یک سیستم dsh فقط باید کلید مدل مورد نیاز خود را داشته باشد. اعتبارنامه‌های ابری و کلیدهای امضای شما باید در جای دیگری نگهداری شوند.

چرا افزونه‌ای که وب را می‌خواند، مدل تهدید را تغییر می‌دهد

اتصال به وب، امکان جستجو و دریافت داده را برای افزونه‌ها فراهم می‌کند. افزونه‌ای که یک صفحه را به نشست شما وارد می‌کند، در واقع متنی را می‌خواند که یک مهاجم می‌تواند آن را بنویسد. مدل‌های زبانی، دستورالعمل‌ها را از داده‌ها تفکیک نمی‌کنند؛ بنابراین یک صفحهٔ دریافت‌شده می‌تواند حاوی خطی باشد که مستقیماً خطاب به عامل (agent) شما نوشته شده است. اگر محیط اجرا (harness) دسترسی به shell داشته باشد، تنها یک گام تا اجرای آن دستور فاصله دارد.

کنترل‌های لازم از قبل در محیط اجرا وجود دارند. dsh-base که اولین بسته در هر پروفایل است، sandbox و سیاست‌های تأیید (approval policy) را ارائه می‌دهد. از آن استفاده کنید. نشستی که می‌تواند صفحات غیرقابل‌اعتماد را دریافت کند، باید برای هرگونه عملیات نوشتن یا اجرا، درخواست تأیید کند تا دستوراتِ دریافت‌شده از وب نتوانند به‌طور خودکار به یک اقدام تبدیل شوند. محدود کردن اقدامات عامل با استفاده از تأییدیه توضیح می‌دهد که چگونه باید در مورد مرزهای این دسترسی‌ها فکر کرد. این رابطه دوطرفه است؛ چرا که سرور خود شما نیز صفحه‌ای است که ممکن است توسط عامل شخص دیگری خوانده شود، که این موضوع در مسدود کردن خزنده‌های هوش مصنوعی در سرور شما بررسی شده است.

چگونه تغییرات ایجاد شده توسط یک افزونه را بررسی کنم؟

پیش از نصب، یک snapshot تهیه کنید، سپس افزونه را نصب کرده و پس از آن یک snapshot دیگر بگیرید و در نهایت تفاوت آن‌ها را بررسی کنید.

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

خروجی diff نشان می‌دهد که نصب افزونه، کدام ورودی‌ها را به درخت ترکیبی (composed tree) اضافه کرده است. اگر افزونه‌ای که برای یک قابلیت کوچک نصب کرده‌اید، چندین ورودی اضافه می‌کند که دلیل آن‌ها را نمی‌دانید، باید فرایند را متوقف کرده و پیش از اجرای آن، سورس‌کد را مطالعه کنید. dsh plugin --profile web why <package-name> به پرسش دیگر پاسخ می‌دهد: کدام‌یک از وابستگی‌های مستقیم شما، یک بستهٔ خاص را فراخوانی کرده است.

بسته‌های نصب‌شده در مسیر $DSH_HOME/profiles/node_modules قرار می‌گیرند، بنابراین می‌توانید درخت فایل‌ها را روی دیسک نیز مشاهده کنید:

ls ~/.dsh/profiles/node_modules

یک پروفایل دوم داشته باشید که هرگز در آن تغییرات آزمایشی انجام نمی‌دهید. هنگامی که یک نصب باعث اختلال در محیط می‌شود، اجرای dsh --profile <clean-name> در عرض چند ثانیه به شما می‌گوید که آیا افزونه عامل این مشکل بوده است یا خیر.

چگونه یک افزونه 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

حذف وابستگی (dependency) همیشه به معنای حذف پیکربندی نیست. ورودی‌هایی که در cordis.patch.yml پروفایل نوشته شده‌اند، در جای خود باقی می‌مانند؛ زیرا آن فایل متعلق به شماست و ابزار مدیریت (harness) آن را برای شما بازنویسی نمی‌کند. فایل را باز کرده و هر بلوکی که نام بسته حذف‌شده را دارد، پاک کنید.

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

سپس با بخشی مواجه شوید که هیچ دستور حذف (uninstall) نمی‌تواند آن را اصلاح کند. اگر افزونه‌ای را به دلیل سلب اعتماد حذف کرده‌اید، هر آنچه که آن افزونه می‌توانست بخواند، قبلاً خوانده شده است. کلید API مربوط به DeepSeek را در کنسول ارائه‌دهنده تغییر دهید (rotate) و هر چیز دیگری که در $DSH_HOME قرار داشت را نیز تغییر دهید. سپس بررسی کنید که حساب کاربری unix که افزونه با آن اجرا می‌شد، به چه بخش‌هایی از شبکه شما دسترسی داشته است.

نسخه کوتاه

• پیش از نصب، tarball منتشرشده را مطالعه کنید؛ از scripts و فایل ورودی شروع کنید.
• نسخه دقیق یا commit دقیق برای مشخصات git را ثابت (pin) کنید و فایل lockfile را نگه دارید.
• نصب را در یک profile انجام دهید و همیشه یک profile تمیز داشته باشید تا در صورت بروز مشکل، بتوانید آن را بوت کنید.
• پیش و پس از هر نصب، --dump-config را با استفاده از diff مقایسه کنید.
• harness را به عنوان یک کاربر unix مجزا، روی loopback و از طریق SSH اجرا کنید.
• تنها یک API key روی سیستم نگه دارید و در روزی که افزونه‌ای را که دیگر به آن اعتماد ندارید حذف می‌کنید، آن را تغییر دهید (rotate).

هیچ‌کدام از این موارد دلیلی برای اجتناب از افزونه‌ها نیست. مدل افزونه همان چیزی است که dsh را مفید می‌کند و harnessای که نتوان آن را توسعه داد، harnessای است که در نهایت جایگزینش خواهید کرد. این موارد دلایلی هستند برای اینکه بدانید چه چیزی نصب کرده‌اید، از چه کسی، با چه نسخه‌ای، و اینکه کل مجموعه را در جایی اجرا کنید که امکان بازسازی (rebuild) آن وجود داشته باشد.

FAQ

آیا dsh پلاگین‌ها را از یکدیگر ایزوله (sandbox) می‌کند؟

خیر. یک پلاگین از طریق Cordis در فرایند اصلی (harness) بارگذاری می‌شود و می‌تواند به نقاط دسترسی مستند، شامل shell، سیستم فایل، وب، subprocess، subagent و اعتبارنامه‌ها دسترسی داشته باشد. dsh-base، که اولین بسته در هر پروفایل است، sandbox و سیاست تأییدی را ارائه می‌دهد که تعیین می‌کند ابزارهای agent چه کارهایی می‌توانند انجام دهند؛ امنیت شما از همین سیاست ناشی می‌شود. هیچ مرز دسترسی مجزایی برای هر پلاگین وجود ندارد، بنابراین مدل صادقانه این است که نصب یک پلاگین، اعتماد شما را به نویسنده آن و تمام بسته‌های موجود در درخت وابستگی‌هایش گسترش می‌دهد.

آیا می‌توانم یک پلاگین dsh را بدون اجرای اسکریپت‌های نصب آن نصب کنم؟

نسخه pnpm 10 و بالاتر به‌طور پیش‌فرض اسکریپت‌های ساخت وابستگی‌ها را مسدود می‌کنند و dsh plugin ... add درخواست‌ها را به pnpm ارجاع می‌دهد؛ بنابراین در نسخه‌های فعلی pnpm، نصب پلاگین اسکریپت‌های بسته را اجرا نمی‌کند مگر اینکه شما آن بسته را تأیید کنید. نسخه خود را با pnpm --version بررسی کنید. این موضوع باعث نمی‌شود یک پلاگین بررسی‌نشده ایمن باشد. کد خودِ پلاگین در بوت بعدی اجرا می‌شود، زیرا harness آن را به‌طور عمدی بارگذاری می‌کند و هیچ محدودیتی در زمان نصب بر آن تأثیر ندارد.

پلاگین‌های dsh و تنظیمات آن‌ها واقعاً کجا قرار دارند؟

$DSH_HOME به‌طور پیش‌فرض در ~/.dsh قرار دارد. پروفایل‌ها در $DSH_HOME/profiles/<name> جای می‌گیرند که هر کدام شامل یک package.json برای وابستگی‌های پلاگین، به همراه مانیفست dsh.profile از بسته‌های مرتب‌شده و یک لایه patch در cordis.patch.yml هستند. بسته‌های نصب‌شده در $DSH_HOME/profiles/node_modules قرار می‌گیرند. کلیدها در $DSH_HOME/.credentials.yaml، مقادیر محیطی در $DSH_HOME/.env و یک فایل $DSH_HOME/cordis.patch.yml در سطح home بر تمام پروفایل‌ها اعمال می‌شود. برای مشاهده نتیجه نهایی بدون بوت کردن، dsh --profile web --dump-config را اجرا کنید.

آیا نصب از بازار پلاگین dsh ایمن است؟

این بازار نصب‌ها را به منابع موجود در یک registry مدیریت‌شده محدود می‌کند و اسکریپت‌های ساخت را مسدود می‌سازد، مگر اینکه آن‌ها را برای هر بسته تأیید کنید؛ این یک بهبود واقعی نسبت به کپی کردن نام بسته از یک پنجره چت است. فایل README خودِ بازار همچنان تأکید می‌کند که لیست شدن به معنای تأیید نیست، زیرا پلاگین‌ها کدهای شخص ثالث از افراد دیگر هستند. کد منبع را بخوانید و نسخه را ثابت (pin) کنید. harness را روی یک حساب کاربری، و در حالت ایده‌آل روی ماشینی اجرا کنید که از دست دادن آن برای شما قابل‌تحمل باشد.