วิธีตรวจสอบความปลอดภัย dsh plugin ก่อนติดตั้งใช้งานจริง

dsh plugin คืออะไร และทำอะไรได้บ้าง

dsh plugin คือ Node package ที่ DeepSeek Harness โหลดเข้าสู่กระบวนการทำงานของตัวเอง การติดตั้ง plugin หมายถึงการรันโค้ดของผู้อื่นด้วยสิทธิ์ของ agent ของคุณ บนเครื่องที่ agent ของคุณเข้าถึงได้อยู่แล้ว ไม่มีสิ่งใดกั้นระหว่าง plugin ที่ถูกโหลดกับส่วนที่เหลือของ harness ดังนั้น คำถามที่ต้องถามก่อนติดตั้งคือโค้ดนั้นเข้าถึงอะไรได้บ้าง และคุณจะจำกัดขอบเขตของมันให้เล็กที่สุดได้อย่างไร

dsh (DeepSeek Harness) คือ agent harness แบบโอเพนซอร์สของ DeepSeek AI ซึ่งสร้างขึ้นบนเฟรมเวิร์กปลั๊กอินที่ชื่อว่า Cordis ไฟล์ README ของโปรเจกต์ระบุว่าทุกอย่างคือปลั๊กอิน ไม่ว่าจะเป็น model adapter, อินเทอร์เฟซเว็บที่คุณใช้พิมพ์โต้ตอบ ทุกอย่างล้วนเป็นปลั๊กอิน สิ่งใดก็ตามที่คุณติดตั้งจากภายนอกโปรเจกต์จะถูกวางอยู่ในโครงสร้างเดียวกัน และได้รับความเชื่อถือในระดับเดียวกับส่วนประกอบที่มาพร้อมกับโปรเจกต์ หากคุณยังไม่ได้ติดตั้งใช้งาน ให้เริ่มจาก การติดตั้ง DeepSeek Harness บน VPS แล้วค่อยกลับมาที่นี่ก่อนที่จะเพิ่มส่วนขยายใดๆ

จุดขยายที่ปลั๊กอินสามารถเข้าถึงได้ถูกระบุไว้ใน AGENTS.md ของ repository โดยข้อมูล ณ เดือนสิงหาคม 2026 ครอบคลุมถึง:

• LLM (large language model): ผู้ให้บริการที่คุณจ่ายเงินผ่าน API key
• Shell: ความสามารถในการใช้ bash โดยมีผู้ให้บริการทั้งแบบ local และ pwsh
• Filesystem: การเข้าถึงไฟล์ที่ควบคุมด้วยนโยบาย
• Web: ผู้ให้บริการสำหรับการค้นหาและดึงข้อมูล
• Subprocess: ผู้ให้บริการสำหรับจัดการ process tree
• Workflow: เธรดการทำงาน (worker threads)
• Subagent: การมอบหมายงานให้กับ agent อื่น
• Settings and credentials: การตั้งค่าและตัวแปรสภาพแวดล้อมที่คุณบันทึกไว้

ปลั๊กอินยังทำการลงทะเบียนเครื่องมือต่างๆ ไว้ที่ ctx.tools และเอกสารระบุไว้อย่างชัดเจนว่า schema ของเครื่องมือที่ลงทะเบียนจะถูกนำไปรวมเข้ากับ prompt assembly ซึ่งส่วนหลังนี้คือสิ่งที่คนมักมองข้าม ปลั๊กอินสามารถเปลี่ยนการตัดสินใจของ agent ได้โดยที่โค้ดของมันเองไม่ต้องทำอะไรที่ผิดปกติ เพราะคำอธิบายที่ปลั๊กอินส่งเข้าไปจะกลายเป็นข้อความที่โมเดลอ่าน นี่เป็นปัญหาในรูปแบบเดียวกับ การทำ prompt injection ต่อ coding agent โดยมีความแตกต่างเพียงอย่างเดียวคือ ข้อความนี้จะเข้ามาเมื่อคุณติดตั้ง และจะคงอยู่จนกว่าคุณจะลบปลั๊กอินนั้นออกไป

dsh ค้นหาและโหลดปลั๊กอินอย่างไร

ไม่มีไดเรกทอรีปลั๊กอินส่วนกลาง dsh ที่กำลังทำงานอยู่คือโครงสร้างปลั๊กอินที่ถูกประกอบขึ้นตอนบูตจากเลเยอร์ที่เรียงลำดับไว้ โดยหน่วยที่เก็บตัวเลือกของคุณคือโปรไฟล์ $DSH_HOME จะมีค่าเริ่มต้นเป็น ~/.dsh และแต่ละโปรไฟล์จะอยู่ใน $DSH_HOME/profiles/<name> ส่วนโปรไฟล์ web และ headless จะสร้างตัวเองขึ้นมาในการใช้งานครั้งแรกจากเทมเพลตที่มาพร้อมกับซอฟต์แวร์

ไดเรกทอรีโปรไฟล์ประกอบด้วยไฟล์สองไฟล์ที่กำหนดทุกอย่าง:

• package.json ซึ่งมีรายการ dependency ของปลั๊กอินภายนอกและไฟล์ manifest dsh.profile ที่ระบุรายการ bundles ตามลำดับ
• cordis.patch.yml ซึ่งเป็นเลเยอร์ patch ของคุณเองที่ครอบทับบน bundle เหล่านั้น

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

กระบวนการบูตจะใช้เลเยอร์ตามลำดับนี้ โดยเลเยอร์ที่อยู่ลำดับหลังจะมีความสำคัญสูงสุด:

1. root ที่ว่างเปล่า
2. bundle ของโปรไฟล์ ตามลำดับที่ระบุไว้ใน manifest
3. cordis.patch.yml ของโปรไฟล์
4. $DSH_HOME/cordis.patch.yml
5. --patch <path> overlays ใดๆ ที่ส่งผ่านทาง command line

มีสองแฟล็กที่ใช้แสดงผลลัพธ์ของการประกอบโครงสร้างนี้โดยไม่ต้องเริ่มการทำงานใดๆ:

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

--dump-default-config จะแสดงโครงสร้างที่ประกอบขึ้นมาเพียงอย่างเดียว ส่วน --dump-config จะเพิ่มเลเยอร์โปรไฟล์และเลเยอร์ patch ใน home เข้าไปด้วย จึงถือเป็นสิ่งที่ใกล้เคียงที่สุดกับรายการจริงของสิ่งที่จะถูกโหลดในการบูตครั้งถัดไปของคุณ โปรดอ่านรายการนี้ก่อนที่คุณจะเชื่อใจเครื่องที่คุณได้รับสืบทอดมา

คำเตือนประการหนึ่งเกี่ยวกับไฟล์ patch เหล่านั้น การตั้งค่าในที่นี้ไม่ใช่ข้อมูลที่อยู่นิ่ง เนื่องจากรูปแบบไฟล์อนุญาตให้ใช้ค่าที่แท็กด้วย !!js ภายใต้บล็อก config ของปลั๊กอินได้ ดังนั้น snippet cordis.patch.yml ที่คัดลอกมาจากโพสต์ในฟอรัมจึงถือเป็นโค้ด โปรดปฏิบัติต่อมันเช่นเดียวกับที่คุณปฏิบัติต่อเชลล์สคริปต์จากแหล่งที่มาเดียวกัน

dsh plugin add ทำงานอย่างไร

dsh plugin --profile <name> <args> จะส่งต่ออาร์กิวเมนต์ไปยัง pnpm ภายในไดเรกทอรีของโปรไฟล์นั้น ดังนั้น pnpm จึงต้องอยู่ใน PATH โดยคำกริยาที่ใช้จะเป็นคำกริยาของ 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 ของคุณ แพ็กเกจจะนำ dependency tree ของตัวเองมาด้วย และทุกแพ็กเกจใน tree นั้นจะไปอยู่ในกระบวนการทำงานเดียวกัน ทุกสิ่งที่ระบุไว้ใน วิธีที่การโจมตีห่วงโซ่อุปทานของ npm เข้าถึงเซิร์ฟเวอร์ สามารถนำมาปรับใช้ได้ที่นี่โดยไม่ต้องแก้ไข

pnpm เวอร์ชัน 10 ขึ้นไปจะไม่รัน build script ของ dependency โดยค่าเริ่มต้น และการอนุมัติจะทำเป็นรายแพ็กเกจผ่าน onlyBuiltDependencies หรือ pnpm approve-builds ตรวจสอบเวอร์ชัน pnpm ที่คุณใช้งานอยู่:

pnpm --version

ค่าเริ่มต้นดังกล่าวเป็นสิ่งที่ควรมี และยังเป็นฟีเจอร์ความปลอดภัยที่ถูกมองข้ามมากที่สุดในระบบนิเวศนี้ การบล็อก build script ช่วยป้องกันไม่ให้โค้ดทำงานระหว่างการติดตั้ง แต่ไม่ได้ช่วยอะไรกับตัวปลั๊กอินเอง เพราะจุดประสงค์หลักของปลั๊กอินคือการที่ harness นำเข้าและเรียกใช้งานมันในการบูตครั้งถัดไป ปลั๊กอินไม่จำเป็นต้องมี hook ของ postinstall เพราะมันได้รับเชิญให้เข้ามาทำงานอยู่แล้ว

สิ่งที่ควรอ่านก่อนติดตั้ง dsh plugin

ดาวน์โหลด tarball ที่เผยแพร่แล้วอ่านเนื้อหาภายใน การแตกไฟล์เก็บถาวรไม่ได้เป็นการเรียกใช้งานโปรแกรมใดๆ

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

ฟิลด์ทั้ง 4 ใน package.json จะบอกข้อมูลส่วนใหญ่ที่คุณจำเป็นต้องทราบ ให้อ่าน scripts เพื่อดูรายการ preinstall, install และ postinstall ให้อ่าน dependencies สำหรับชื่อที่คุณไม่คุ้นเคย หรือชื่อที่สะกดคล้ายกับชื่อที่คุณรู้จัก ให้อ่าน bin สำหรับสิ่งที่แพ็กเกจต้องการเพิ่มลงใน PATH ของคุณ ให้อ่าน main หรือ exports เพื่อดูไฟล์เริ่มต้น จากนั้นเปิดไฟล์ดังกล่าวและปฏิบัติตามขั้นตอนที่ระบุไว้

จากนั้นให้อ่านโค้ดที่จะถูกโหลดขึ้นมาทำงานจริง ปลั๊กอินที่โฆษณาว่าเป็นเครื่องมือแจ้งเตือนไม่มีเหตุผลอันควรที่จะต้องอ่าน ~/.ssh, ติดต่อไปยังโฮสต์ที่คุณไม่เคยรู้จัก หรือเรียกใช้ shell หากแพ็กเกจนั้นมีเพียง JavaScript ที่ถูกรวมหรือย่อขนาด (minified) มาให้โดยไม่มีซอร์สโค้ดที่ตรงกันใน repository สาธารณะ นั่นคือคำตอบของคุณแล้ว ให้เลือกใช้ปลั๊กอินที่คุณสามารถอ่านซอร์สโค้ดได้ และควรเลือกปลั๊กอินที่มีขนาดเล็ก

คุณยังสามารถตรวจสอบข้อมูลจาก registry ได้โดยไม่ต้องติดตั้งสิ่งใด:

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

แพ็กเกจที่เพิ่งเผยแพร่เมื่อสัปดาห์ที่แล้ว มีเพียงเวอร์ชันเดียว ไม่มีฟิลด์ repository และมีชื่อที่เลียนแบบชื่อยอดนิยม ถือเป็นกลโกงที่เก่าแก่ที่สุดในทุก registry การ ตรวจสอบไฟล์ที่ดาวน์โหลดด้วย checksum เป็นนิสัยที่ควรทำควบคู่กันไป: ต้องทราบแน่ชัดว่าสิ่งที่คุณดึงมาคืออะไรก่อนที่จะอนุญาตให้มันทำงาน

กำหนดเวอร์ชันให้คงที่และเก็บไฟล์ lockfile ไว้

การใช้ช่วงเวอร์ชันแบบลอยตัว (floating version range) หมายความว่าโค้ดภายในกระบวนการทำงานของ agent อาจเปลี่ยนแปลงได้ทุกครั้งที่มีการติดตั้งหรืออัปเดตโดยที่คุณไม่ได้เป็นผู้ตัดสินใจ ดังนั้นคุณควรระบุเวอร์ชันให้คงที่ (pin)

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

ตำแหน่งของ flag อาจแตกต่างกันไปตามเวอร์ชันของ pnpm ดังนั้นให้ตรวจสอบผลลัพธ์แทนการเชื่อมั่นในคำสั่งเพียงอย่างเดียว หลังจากนั้นให้เปิดไฟล์ package.json ของโปรไฟล์ขึ้นมาดู แล้วยืนยันว่า dependency นั้นแสดงเป็นเลขเวอร์ชันตรงๆ โดยไม่มีสัญลักษณ์ ^ หรือ ~ นำหน้า ไฟล์ดังกล่าวจะเป็นตัวตัดสินว่าสิ่งที่ติดตั้งลงไปคืออะไร

จากนั้นให้เก็บไฟล์ lockfile ไว้ ซึ่งไฟล์นี้จะทำหน้าที่ล็อกโครงสร้าง dependency ทั้งหมดแบบ transitive ไม่ใช่แค่ชื่อแพ็กเกจระดับบนสุดเท่านั้น:

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

คัดลอกไฟล์นี้ไปยังที่ที่คุณสำรองข้อมูลไว้ พร้อมกับไฟล์ package.json ของโปรไฟล์ ไฟล์ทั้งสองนี้จะช่วยให้คุณสร้างโครงสร้างเดิมขึ้นมาใหม่บนเครื่องอื่นได้ ให้รันคำสั่ง dsh plugin --profile web update เฉพาะเมื่อคุณตัดสินใจที่จะเปลี่ยนเวอร์ชันเท่านั้น ห้ามรันเป็นกิจวัตรเพื่อจัดระเบียบไฟล์ และให้ตรวจสอบความแตกต่างของไฟล์ lockfile หลังจากรันคำสั่งเสมอ

สำหรับปลั๊กอินที่ติดตั้งจาก git แทนที่จะติดตั้งจาก registry ให้ระบุเป็น commit hash แทนการระบุชื่อ branch การกำหนดค่าในรูปแบบ github:owner/repo#<full commit sha> จะช่วยให้คุณได้โครงสร้างที่คงที่ แต่หากใช้ชื่อ branch คุณจะได้โค้ดล่าสุดที่ branch นั้นถือครองอยู่ในการแก้ไขครั้งถัดไปของ pnpm ซึ่งเป็นการตัดสินใจที่คุณมอบอำนาจให้ผู้อื่นเป็นผู้กำหนด ตัว harness เองก็ต้องการวินัยในลักษณะเดียวกัน เนื่องจาก dsh build ทุกตัวที่เผยแพร่ออกมาถือเป็น release candidate และการติดตั้งแบบไม่ได้ระบุเวอร์ชันให้คงที่อาจทำให้ได้ผลลัพธ์ที่แตกต่างกันในแต่ละวัน ซึ่งเป็นสาเหตุหลักของ ข้อผิดพลาดในการติดตั้งและเวอร์ชันของ dsh ส่วนใหญ่

ตลาดปลั๊กอินและคุณค่าของคำว่า "คัดสรร"

dsh มีตลาดปลั๊กอินและติดตั้งในรูปแบบปลั๊กอิน ซึ่งบอกให้คุณทราบถึงสถาปัตยกรรมของมันได้เป็นอย่างดี:

dsh plugin --profile web add dshmarket

หลังจากรีสตาร์ท มันจะปรากฏภายใต้ Settings แล้วไปที่ Plugin Market ไฟล์ README ของมันระบุข้อจำกัดไว้อย่างชัดเจน การติดตั้งจะถูกจำกัดเฉพาะแหล่งที่มาที่ระบุไว้ใน registry ที่ผ่านการคัดสรรแล้วเท่านั้น และรายการอื่นทั้งหมดจะถูกปฏิเสธ สคริปต์การ build จะถูกบล็อกโดยค่าเริ่มต้น และการเปิดใช้งานสคริปต์ใดสคริปต์หนึ่งจำเป็นต้องได้รับการอนุมัติเป็นรายแพ็กเกจ ปลั๊กอินเทอร์มินัลจะถูกทำเครื่องหมายแจ้งเตือนก่อนที่จะถูกนำไปใช้ในโปรไฟล์เว็บ ประโยคที่สำคัญที่สุดคือการระบุรายการไม่ได้หมายถึงการรับรอง เพราะปลั๊กอินเหล่านี้เป็นโค้ดจากบุคคลที่สาม

รายการที่ผ่านการคัดสรรช่วยยกระดับมาตรฐานขั้นต่ำ แต่มันไม่ได้อ่านโค้ดแทนคุณ และไม่สามารถบอกคุณได้ว่าปลั๊กอินเวอร์ชันถัดไปจะทำอะไรหลังจากที่บัญชีผู้ดูแลเปลี่ยนมือ ให้ปฏิบัติต่อการติดตั้งแบบคลิกเดียวเหมือนกับที่คุณปฏิบัติต่อ curl | bash จากผู้เขียนคนเดียวกัน มีอีกหนึ่งบรรทัดจาก README นั้นที่ควรค่าแก่การย้ำเตือน: ไฟล์สำรองที่ส่งออกออกมาอาจมีข้อมูลรับรอง (credentials) จากการตั้งค่าโปรไฟล์ของคุณ ดังนั้นห้ามแนบไฟล์ดังกล่าวไปกับประเด็นปัญหา (issue) สาธารณะหรือเว็บไซต์วางข้อความ (paste site) หากคุณต้องการรายการเริ่มต้นแทนที่จะเป็นวิธีการ ปลั๊กอิน dsh ที่น่าติดตั้ง คือบทความคู่ขนานกับบทความนี้

เรียกใช้งาน dsh ด้วยผู้ใช้ของตนเอง ไม่ใช่ root

การตรวจสอบช่วยลดโอกาสที่สิ่งไม่พึงประสงค์จะหลุดเข้ามา และหลักการสิทธิ์ขั้นต่ำ (least privilege) จะเป็นตัวกำหนดขอบเขตความเสียหายหากเกิดเหตุการณ์ดังกล่าวขึ้น บน VPS การตั้งค่าส่วนหลังนี้ทำได้ง่ายและมีต้นทุนต่ำ

กำหนดบัญชีผู้ใช้ unix แยกต่างหากสำหรับเครื่องมือนี้พร้อม home directory ของตนเอง และห้ามเรียกใช้งานด้วยสิทธิ์ root โดยเด็ดขาด:

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

ภายใน session นั้น ให้เริ่มการทำงานของเครื่องมือเพื่อให้เขียนข้อมูลลงใน home directory ของบัญชีผู้ใช้นั้น:

npx @deepseek-ai/dsh web

โดยปกติแล้ว web UI จะทำงานบนพอร์ต http://127.0.0.1:3080 ให้คงค่าเดิมไว้ เนื่องจากสิ่งที่เข้าถึงพอร์ตนี้ได้สามารถควบคุม agent ที่มี shell อยู่ได้ ดังนั้นการเปิดพอร์ต 3080 สู่สาธารณะจึงเท่ากับการเปิด remote shell ที่ไม่มีสิทธิ์ root แต่มีหน้าตาใช้งานง่าย ให้เข้าถึงผ่าน SSH tunnel จากแล็ปท็อปของคุณแทน:

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

จากนั้นตรวจสอบให้แน่ใจว่าไม่มีบริการใดกำลังรอรับการเชื่อมต่อบน public address:

ss -lnt | grep 3080

local address ควรแสดงเป็น 127.0.0.1:3080 หากแสดงเป็น 0.0.0.0:3080 แสดงว่า firewall ของคุณเป็นปราการด่านเดียวที่กั้นระหว่างคนแปลกหน้ากับ agent ของคุณ เหตุผลเบื้องหลังการ เรียกใช้งาน Claude Code บน VPS อย่างปลอดภัย สามารถนำมาปรับใช้กับ dsh ได้โดยไม่ต้องเปลี่ยนแปลงใดๆ ให้สิทธิ์ agent เข้าถึง workspace directory เพียงแห่งเดียวที่ยอมให้เกิดความเสียหายได้ และเก็บข้อมูลใดๆ ที่คุณไม่สามารถสร้างใหม่ได้ไว้ภายนอกเครื่องนั้น หรือทางที่ดีกว่าคือให้มองว่าเครื่องนี้เป็น VM แบบใช้แล้วทิ้งสำหรับ coding agent เพราะการสร้าง VPS ใหม่ใช้เวลาเพียงหนึ่งชั่วโมง ในขณะที่การตรวจสอบความปลอดภัยของเครื่องที่ใช้งานอยู่อาจต้องใช้เวลาถึงหนึ่งสัปดาห์

ตำแหน่งจัดเก็บคีย์และข้อจำกัดของสิทธิ์การเข้าถึงไฟล์

dsh จัดเก็บ API keys ไว้ใน $DSH_HOME/.credentials.yaml และค่า environment ไว้ใน $DSH_HOME/.env โดยมีการตั้งค่าโมเดลใน $DSH_HOME/settings.yaml และประวัติเซสชันภายใต้ $DSH_HOME/storages ว่าคีย์ใดควรอยู่ในไฟล์ใดและข้อมูลใดจะถูกส่งออกจากเครื่องในแต่ละโหมดนั้นเป็นเนื้อหาของ การกำหนดค่า API keys, โมเดล และ endpoint ของ dsh ซึ่งควรทำความเข้าใจให้ชัดเจนก่อนเพิ่มปลั๊กอิน เพราะทุกคีย์ที่คุณเชื่อมต่อคือข้อมูลที่ปลั๊กอินสามารถอ่านได้ ให้จำกัดสิทธิ์ไฟล์สำคัญทั้งสองดังนี้:

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

โหมด 600 อนุญาตให้เจ้าของไฟล์อ่านและเขียนได้เท่านั้น และไม่อนุญาตให้ผู้อื่นเข้าถึง ซึ่งเป็นสิ่งที่ควรทราบทั้งในรูปแบบตัวเลขและสัญลักษณ์ (โหมด chmod แบบตัวเลขเทียบกับสัญลักษณ์) จงตระหนักถึงสิ่งที่โหมดนี้ทำได้จริง สิทธิ์ของไฟล์ช่วยป้องกันไฟล์เหล่านั้นจากบัญชีผู้ใช้อื่นบนเครื่อง แต่ไม่มีผลใดๆ ต่อปลั๊กอิน เพราะปลั๊กอินทำงานในฐานะผู้ใช้ที่เป็นเจ้าของไฟล์และอยู่ภายในกระบวนการที่อ่านไฟล์เหล่านั้น นี่คือเหตุผลว่าทำไม การเก็บความลับให้พ้นจากมือของ AI agent จึงหมายถึงการไม่นำความลับเหล่านั้นมาไว้บนเครื่องเลย เครื่องที่ติดตั้ง dsh ควรเก็บเฉพาะคีย์ของโมเดลที่จำเป็นต้องใช้เท่านั้น ส่วนข้อมูลรับรองระบบคลาวด์และคีย์สำหรับลงนามของคุณควรจัดเก็บไว้ที่อื่น

เหตุใดปลั๊กอินที่อ่านเว็บจึงเปลี่ยนรูปแบบการคุกคาม

จุดเชื่อมต่อเว็บช่วยให้ปลั๊กอินสามารถค้นหาและดึงข้อมูลจากผู้ให้บริการได้ ปลั๊กอินที่ดึงหน้าเว็บเข้ามาในเซสชันของคุณกำลังดึงข้อความที่ผู้โจมตีสามารถเขียนขึ้นมาได้ เนื่องจากโมเดลไม่ได้แยกคำสั่งออกจากข้อมูล หน้าเว็บที่ถูกดึงมาจึงอาจมีบรรทัดที่ระบุถึงเอเจนต์ของคุณ และระบบที่ถือสิทธิ์การเข้าถึง shell อยู่ห่างจากการรันคำสั่งนั้นเพียงขั้นตอนเดียวเท่านั้น

การควบคุมมีอยู่แล้วในระบบ dsh-base ซึ่งเป็นชุดคำสั่งแรกในทุกโปรไฟล์ โดยทำหน้าที่จัดเตรียม sandbox และนโยบายการอนุมัติ คุณควรใช้งานมัน เซสชันที่สามารถดึงหน้าเว็บที่ไม่น่าเชื่อถือควรต้องมีการอนุมัติสำหรับทุกสิ่งที่เขียนหรือรัน เพื่อไม่ให้คำสั่งที่ดึงมากลายเป็นการกระทำด้วยตัวมันเอง การจำกัดการกระทำของเอเจนต์ด้วยการอนุมัติ ครอบคลุมถึงวิธีคิดว่าควรวางขอบเขตไว้ที่ใด ความสัมพันธ์นี้ทำงานทั้งสองทิศทาง เนื่องจากเซิร์ฟเวอร์ของคุณเองก็เป็นหน้าเว็บที่เอเจนต์ของผู้อื่นจะเข้ามาดึงข้อมูล ซึ่งเป็นกรณีเดียวกับ การบล็อก AI crawler บนเซิร์ฟเวอร์ของคุณ

ฉันจะตรวจสอบได้อย่างไรว่าปลั๊กอินมีการเปลี่ยนแปลงอะไรบ้าง

ให้ทำ 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> จะช่วยตอบคำถามอีกข้อหนึ่งคือ แพ็กเกจที่ระบุถูกดึงเข้ามาโดย dependency ตัวใดที่คุณเรียกใช้งานโดยตรง

แพ็กเกจที่ติดตั้งจะถูกเก็บไว้ภายใต้ $DSH_HOME/profiles/node_modules ดังนั้นคุณจึงสามารถตรวจสอบโครงสร้างบนดิสก์ได้เช่นกัน:

ls ~/.dsh/profiles/node_modules

ให้เก็บ profile สำรองไว้อีกชุดหนึ่งที่คุณจะไม่นำมาใช้ทดลอง เมื่อการติดตั้งทำให้ระบบเสียหาย การบูตด้วย 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 ของโปรไฟล์จะยังคงอยู่ที่เดิม เนื่องจากไฟล์นั้นเป็นของคุณและระบบจะไม่เขียนทับให้โดยอัตโนมัติ ให้เปิดไฟล์ดังกล่าวแล้วลบบล็อกที่ระบุชื่อแพ็กเกจที่คุณต้องการนำออก

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

จากนั้นให้จัดการในส่วนที่ไม่มีคำสั่งถอนการติดตั้งใดแก้ไขได้ หากคุณลบปลั๊กอินเพราะไม่ไว้วางใจอีกต่อไป ข้อมูลใดก็ตามที่ปลั๊กอินนั้นสามารถอ่านได้ ถือว่าถูกอ่านไปเรียบร้อยแล้ว ให้หมุนเวียน (rotate) DeepSeek API key ในคอนโซลของผู้ให้บริการ และหมุนเวียนข้อมูลอื่นใดก็ตามที่เคยอยู่ใน $DSH_HOME จากนั้นให้ตรวจสอบว่าบัญชีผู้ใช้ unix ที่ปลั๊กอินนั้นใช้รันอยู่ สามารถเข้าถึงส่วนใดของเครือข่ายคุณได้บ้าง

สรุปโดยย่อ

• อ่าน tarball ที่เผยแพร่ก่อนทำการติดตั้ง โดยเริ่มจาก scripts และไฟล์ entry
• ระบุเวอร์ชันที่แน่นอน หรือระบุ commit ที่แน่นอนสำหรับ git spec และเก็บ lockfile ไว้
• ติดตั้งลงใน profile เดียว และรักษา profile ที่สะอาดไว้เพื่อให้สามารถบูตเข้าใช้งานได้เมื่อเกิดปัญหา
• ตรวจสอบความแตกต่างของ --dump-config ก่อนและหลังการติดตั้งทุกครั้ง
• รัน harness ในฐานะผู้ใช้ unix ของตนเอง บน loopback และเข้าถึงผ่าน SSH
• เก็บ API key ไว้บนเครื่องเพียงชุดเดียว และหมุนเวียนคีย์ในวันที่คุณลบปลั๊กอินที่ไม่น่าเชื่อถือออก

คำแนะนำเหล่านี้ไม่ใช่เหตุผลที่จะหลีกเลี่ยงการใช้ปลั๊กอิน รูปแบบปลั๊กอินคือสิ่งที่ทำให้ dsh มีประโยชน์ และ harness ที่คุณไม่สามารถขยายขีดความสามารถได้ ก็คือ harness ที่คุณจะต้องเปลี่ยนใหม่ในที่สุด แต่สิ่งเหล่านี้เป็นเหตุผลที่คุณควรทราบว่าคุณติดตั้งอะไร จากใคร ที่เวอร์ชันใด และควรดำเนินการทั้งหมดในสภาพแวดล้อมที่คุณสามารถสร้างใหม่ได้เสมอ

FAQ

dsh มีการแยก sandbox ของปลั๊กอินแต่ละตัวออกจากกันหรือไม่?

ไม่ ปลั๊กอินจะถูกโหลดเข้าสู่กระบวนการ harness ผ่าน Cordis และสามารถเข้าถึงส่วนเชื่อมต่อความสามารถที่ระบุไว้ได้ทั้งหมด รวมถึง shell, ระบบไฟล์, เว็บ, subprocess, subagent และ credentials โดย dsh-base ซึ่งเป็น bundle แรกในทุกโปรไฟล์ จะเป็นตัวส่งมอบ sandbox และนโยบายการอนุมัติที่ควบคุมสิ่งที่เครื่องมือของ agent สามารถทำได้ และนโยบายดังกล่าวคือจุดที่ให้การป้องกันแก่คุณ ทั้งนี้ไม่มีการกำหนดขอบเขตสิทธิ์แยกรายปลั๊กอิน ดังนั้นรูปแบบที่ตรงไปตรงมาที่สุดคือการยอมรับว่าการติดตั้งปลั๊กอินเป็นการขยายความไว้วางใจของคุณไปยังผู้เขียนปลั๊กอินและทุกแพ็กเกจใน dependency tree ของปลั๊กอินนั้น

ฉันสามารถติดตั้งปลั๊กอิน dsh โดยไม่รันสคริปต์ติดตั้งได้หรือไม่?

pnpm 10 ขึ้นไปจะบล็อกสคริปต์ build ของ dependency โดยค่าเริ่มต้น และ dsh plugin ... add จะส่งคำสั่งต่อไปยัง pnpm ดังนั้นใน pnpm เวอร์ชันปัจจุบัน การติดตั้งจะไม่รันสคริปต์ของแพ็กเกจเว้นแต่คุณจะอนุมัติแพ็กเกจนั้น คุณสามารถตรวจสอบเวอร์ชันได้ด้วย pnpm --version อย่างไรก็ตาม สิ่งนี้ไม่ได้ทำให้ปลั๊กอินที่ไม่ได้ตรวจสอบมีความปลอดภัย เพราะโค้ดของปลั๊กอินจะทำงานในการบูตครั้งถัดไปเนื่องจาก harness โหลดปลั๊กอินนั้นโดยเจตนา ซึ่งไม่มีข้อจำกัดในขั้นตอนการติดตั้งใดๆ ที่ส่งผลต่อการทำงานนี้

ปลั๊กอิน dsh และไฟล์ตั้งค่าของมันถูกจัดเก็บไว้ที่ใด?

$DSH_HOME มีค่าเริ่มต้นอยู่ที่ ~/.dsh โดยโปรไฟล์จะอยู่ใน $DSH_HOME/profiles/<name> ซึ่งแต่ละโปรไฟล์จะเก็บ package.json ที่มี dependency ของปลั๊กอิน รวมถึงไฟล์ manifest dsh.profile ของ bundle ที่เรียงลำดับไว้ และเลเยอร์ patch cordis.patch.yml ส่วนแพ็กเกจที่ติดตั้งแล้วจะถูกจัดเก็บไว้ภายใต้ $DSH_HOME/profiles/node_modules สำหรับกุญแจจะอยู่ใน $DSH_HOME/.credentials.yaml, ค่า environment อยู่ใน $DSH_HOME/.env และไฟล์ $DSH_HOME/cordis.patch.yml ระดับ home จะถูกนำมาใช้กับทุกโปรไฟล์ ให้รัน dsh --profile web --dump-config เพื่อดูผลลัพธ์ที่ประกอบรวมกันโดยไม่ต้องทำการบูต

การติดตั้งจาก dsh plugin market ปลอดภัยหรือไม่?

ตลาดปลั๊กอินจำกัดการติดตั้งไว้เฉพาะแหล่งที่มาจาก registry ที่ผ่านการคัดสรรและบล็อกสคริปต์ build เว้นแต่คุณจะอนุมัติเป็นรายแพ็กเกจ ซึ่งถือเป็นการปรับปรุงที่ดีกว่าการคัดลอกชื่อแพ็กเกจจากหน้าต่างแชทมาติดตั้งโดยตรง อย่างไรก็ตาม README ของตลาดเองยังคงระบุว่าการแสดงรายการไม่ได้หมายถึงการรับรอง เนื่องจากปลั๊กอินเป็นโค้ดของบุคคลที่สามจากผู้อื่น คุณควรตรวจสอบซอร์สโค้ดและล็อกเวอร์ชันไว้เสมอ รวมถึงควรใช้งาน harness บนบัญชีผู้ใช้ หรือในอุดมคติคือบนเครื่องที่คุณสามารถยอมรับความเสี่ยงหากเกิดความเสียหายได้