Vet – เครื่องมือสำหรับรันสคริปต์เชลล์ระยะไกลได้อย่างปลอดภัยยิ่งขึ้น

 (getvet.sh)
10 คะแนน โดย GN⁺ 2025-07-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • vet เป็นเครื่องมือ CLI ที่ช่วย เปลี่ยนการรันสคริปต์ติดตั้งระยะไกลแบบ curl | bash ให้ปลอดภัยขึ้นเป็นกระบวนการ "ดาวน์โหลด→ตรวจสอบ→อนุมัติให้รัน"
  • มีฟีเจอร์ป้องกันหลายชั้น เช่น การตรวจดูความเปลี่ยนแปลงของสคริปต์ (diff), การ lint (วิเคราะห์แบบสถิต) ด้วย shellcheck และการอนุมัติด้วยตนเองก่อนรันจริง
  • ใช้คำสั่งเดียว (vet https://example.com/install.sh) เพื่อตรวจสอบ ความเสี่ยงที่อาจเกิดขึ้น การถูกแก้ไขดัดแปลง การพิมพ์ผิด และช่องโหว่ โดยอัตโนมัติก่อนรันสคริปต์ระยะไกล
  • การติดตั้งตัวมันเองก็รองรับทั้งแบบ "ดาวน์โหลดแล้วตรวจสอบ" และแบบ curl | sh อีกทั้งยังสามารถตรวจดูโค้ดติดตั้งของ vet ได้โดยตรง
  • เป็นโซลูชันที่เชื่อถือได้ซึ่งช่วยป้องกัน ความเสี่ยงด้านความปลอดภัยในสภาพแวดล้อมพัฒนา/ปฏิบัติการ พร้อมคงไว้ทั้งความอัตโนมัติและความสะดวก

ปัญหา: การรันสคริปต์ติดตั้งระยะไกลโดยไม่รอบคอบ

  • โอเพนซอร์สและเครื่องมือจำนวนมากแนะนำวิธีติดตั้งด้วยสคริปต์ระยะไกล เช่น curl -sSL https://example.com/install.sh | bash
  • วิธีนี้มี ความเสี่ยงด้านความปลอดภัยร้ายแรง เช่น การรันโค้ดอันตรายหรือการรันไฟล์ที่ดาวน์โหลดมาไม่ครบ อันเกิดจากการถูกแก้ไขสคริปต์ การถูกแฮ็กเซิร์ฟเวอร์ หรือข้อผิดพลาดของเครือข่าย

โซลูชันของ vet: การรันแบบอินเทอร์แอ็กทีฟที่ปลอดภัย

  • vet ครอบการรันสคริปต์ระยะไกลไว้ด้วย กระบวนการความปลอดภัย 4 ขั้นตอน ดังนี้
    • 1. Fetch: ดาวน์โหลดสคริปต์ระยะไกลอย่างปลอดภัยไปยังตำแหน่งชั่วคราว
    • 2. Diff & Review: เปรียบเทียบกับประวัติการรันก่อนหน้าเพื่อแสดงความเปลี่ยนแปลง (diff) และให้ตรวจดูโค้ดใหม่/โค้ดที่เปลี่ยนด้วยตาตนเอง
    • 3. Lint: ใช้ shellcheck (ขณะติดตั้ง) เพื่อวิเคราะห์แบบสถิตหา bug, ช่องโหว่ และแพตเทิร์นที่ผิดปกติโดยอัตโนมัติ
    • 4. Confirm: ขอให้ผู้ใช้ยืนยันขั้นสุดท้าย (yes/no) ก่อนรันจริง
  • คำสั่งเดียว: 
    vet https://example.com/install.sh

วิธีติดตั้ง

วิธีที่แนะนำและปลอดภัยกว่า (ดาวน์โหลด → ตรวจสอบ → รัน)

  • 1. ดาวน์โหลดสคริปต์ติดตั้ง:
  • 2. ตรวจดูโค้ดของสคริปต์ที่ดาวน์โหลดมาด้วยตนเอง (เช่น less, vim):
    less install_vet.sh
  • 3. หลังตรวจสอบแล้วค่อยรันเอง:
    sh install_vet.sh

ติดตั้งแบบรวดเร็ว (คำสั่งบรรทัดเดียวบนพื้นฐานของความเชื่อถือ)

คุณสมบัติและข้อดีของ vet

  • ตรวจจับความเปลี่ยนแปลง (diff): เปรียบเทียบกับสคริปต์ที่เคยรันก่อนหน้าเพื่อดูว่าส่วนใดเปลี่ยนไป
  • lint อัตโนมัติ (เชื่อมต่อกับ shellcheck): ตรวจหาช่องโหว่ การพิมพ์ผิด และโค้ดน่าสงสัยในสคริปต์เชลล์โดยอัตโนมัติ
  • การยืนยันก่อนรันอย่างชัดเจน (Confirm): ควบคุมการรันจริงได้ด้วยการคลิกหรือกรอกยืนยันหนึ่งครั้ง
  • บันทึกสคริปต์และจัดการประวัติอัตโนมัติ: ติดตามสคริปต์ติดตั้งที่ใช้บ่อยได้อย่างปลอดภัย
  • รับประกันความปลอดภัยในการติดตั้ง/อัปเดตภายในด้วย

บทสรุป

  • vet คือ ทางเลือกที่ปลอดภัยสำหรับ curl | bash ที่ทั้งนักพัฒนาและผู้ดูแลระบบควรมี ช่วยให้ได้ทั้งระบบติดตั้งอัตโนมัติและความปลอดภัย
  • "อย่ารันทันทีแบบไม่คิด ตรวจสอบด้วย vet ก่อนแล้วค่อยรัน!"

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-07-02
ความคิดเห็นจาก Hacker News
  • ใน 90% ของกรณี ก็สงสัยว่าเวลาจะใช้ตัวติดตั้ง เราตรวจสอบความน่าเชื่อถือของซอฟต์แวร์นั้นจริง ๆ อย่างไร บางกรณีโค้ดมีการเซ็นกำกับไว้ แต่ในหลายกรณีก็เป็นโค้ดที่ดาวน์โหลดมาจากเซิร์ฟเวอร์ HTTPS เดียวกันโดยไม่มีการตรวจสอบเพิ่ม ถ้าโค้ดมาในรูปแบบคอมไพล์แล้วก็ถามต่อว่ามีการทำ diff กันหรือไม่ การรันตัวติดตั้งจากอินเทอร์เน็ตแบบไม่คิดอะไรไม่ใช่วิธีที่ดีนัก และถ้าติดตั้งผ่านดิสโทรของระบบปฏิบัติการก็จะมีวิธีตรวจสอบที่ดีกว่ามากอยู่แล้ว แต่ถึงอย่างนั้น วิธีเหล่านี้ก็ไม่ได้ช่วยเพิ่มความเชื่อมั่นได้มากนัก
    • จุดประสงค์ของ vet คือโฟกัสที่ความปลอดภัยของสคริปต์ติดตั้งเอง โดยเน้นป้องกันไม่ให้สคริปต์ติดตั้งถูกแก้ให้ข้ามการตรวจสอบ checksum หรือดาวน์โหลดไบนารีจาก URL ที่เป็นอันตราย มันเป็นการป้องกันที่แข็งแรงในบางส่วน แต่ไม่ได้ครอบคลุมทั้ง chain
    • โดยทั่วไปตัวติดตั้งจะรันแค่ครั้งเดียว เลยสงสัยว่าการแสดงความเปลี่ยนแปลงเทียบกับการรันครั้งก่อนจะมีประโยชน์แค่ไหน
    • จะติดตั้งผ่านรายการแพ็กเกจที่ชุมชนดูแลและมีการเซ็นคริปโตกราฟิกที่เชื่อถือได้เท่านั้น โดยใช้แนวทางที่มีประวัติด้านความปลอดภัยแข็งแรง คิดว่าปัญหาหลักไม่ใช่ว่าการทำให้สคริปต์ดาวน์โหลดปลอดภัยเป็นเรื่องยาก แต่คือวัฒนธรรมในบางชุมชนอย่าง macOS ที่ยอมรับวิธีติดตั้งแบบแฮ็ก ๆ นี้มากกว่า ควรเรียกร้องมาตรฐานที่เข้มงวดกว่านี้จากแพลตฟอร์มที่น่าเชื่อถือ ไม่คิดว่าการเอาเชลล์สคริปต์ที่โหลดจากอินเทอร์เน็ตไปรัน Lint จะช่วยให้ปลอดภัยขึ้น
  • สงสัยว่าถ้ามีคนคอยแทรก pragma # shellcheck disable= เข้าไปในสคริปต์อันตรายจะเป็นอย่างไร
    • เป็นข้อสังเกตที่ดี แบบนั้นทำได้จริง แต่ vet ไม่ได้เชื่อ ShellCheck อย่างเดียว diff ต่างหากคือหัวใจหลัก ต่อให้ linter เงียบอยู่ การแทรกโค้ด # shellcheck disable= ที่น่ากังวลก็ยังตรวจจับได้ผ่าน diff และการเปลี่ยนแปลงนั้นเองก็คือสัญญาณเตือน
  • รู้สึกถึงความย้อนแย้ง: 
    # สถานการณ์ที่เชื่อสคริปต์รีโมตแบบไม่ตั้งคำถาม:
curl -sSL https://example.com/install.sh | bash
    แล้วก็มารันต่อด้วย 
    curl -sL https://getvet.sh | sh
    แบบนี้
    • เหมือนจะอ่านข้ามส่วนนั้นไป ประเด็นสำคัญของ vet คือมันรับรู้ถึงความย้อนแย้งนี้เอง และแนะนำให้ผู้ใช้ตรวจสอบสคริปต์ติดตั้งของ vet ด้วยตัวเอง นั่นแหละคือเป้าหมายของ vet สามารถดูซอร์สของ install.sh ได้โดยตรง
  • คิดว่าเป็นโซลูชันที่เจ๋งมาก เคยกังวลเรื่องนี้บ่อย ๆ และก็สงสัยเรื่องเดียวกันกับ uv ด้วย แต่ส่วนใหญ่ก็ยอมประนีประนอมใช้ไป เพราะทุกคนเชื่อใจผู้ดูแลโค้ดอยู่แล้ว
    • อยากรู้ว่ามีความเห็นอย่างไรเกี่ยวกับ uv
  • การถกเถียงนี้ทำให้นึกถึงก้าวถัดไปของ vet คือการรองรับสภาพแวดล้อมแบบ private การตรวจสอบสคริปต์สาธารณะก็ดี แต่ก็เริ่มมีความต้องการรันสคริปต์ deploy จาก GitHub repo ภายในหรือเซิร์ฟเวอร์ภายในด้วย เลยเปิดคำขอฟีเจอร์เพื่อเพิ่มความสามารถด้าน authentication ให้ vet ไว้แล้ว ใน roadmap มีทั้งการรองรับ .netrc, ตัวแปรสภาพแวดล้อม VET_TOKEN และในอนาคตอาจรวมถึงการเชื่อมต่อกับ secret manager อย่าง HashiCorp Vault ถ้าสนใจอยากฟังความเห็นใน GitHub issue ขอบคุณสำหรับฟีดแบ็ก
  • สงสัยว่าบนหน้าเว็บหรือใน readme จะมีการแสดงภาพการทำงานหรือวิดีโอเดโมได้ไหม เช่น เปิดผ่าน pager หรือ editor และคำเตือนจาก shellcheck แสดงอย่างไร
    • เห็นด้วย README ตอนนี้อธิบายแค่ว่า vet ทำงานอย่างไร แต่ยังไม่แสดงประสบการณ์ใช้งานจริงได้ดีพอ มีแผนจะเพิ่มเดโม GIF ในหน้าเว็บ เพื่อตอบคำถาม โดยปกติจะเปิดไฟล์ใน pager (less หรือถ้ามี bat ติดตั้งอยู่ก็จะใช้ pager ที่ไฮไลต์สวยกว่า) และจะไม่เปิดใน editor เพื่อป้องกันการแก้ไขโดยไม่ตั้งใจ ถ้า ShellCheck พบปัญหา ก็จะแสดงผลในเทอร์มินัลแบบมีสีทันที แล้วถามผู้ใช้ตรง ๆ ว่าจะตรวจต่อหรือไม่ในรูปแบบ [y/N] ตัวอย่าง: 
      ==> Running ShellCheck analysis...

In /tmp/tmp.XXXXXX line 7:
echo "Processing file: $filename"
           ^-- SC2086: Double quote to prevent globbing and word splitting.

==> WARNING: ShellCheck found potential issues.
[?] Continue with review despite issues? [y/N]
      ขอบคุณสำหรับข้อเสนอแนะดี ๆ
  • น่าเสียดายที่มันไม่ทำงานอัตโนมัติแบบแพตเทิร์น curl | bash ฝั่ง Windows มีความสามารถที่สแกนไฟล์ให้อัตโนมัติเมื่อผู้ใช้พยายามติดตั้ง
  • ไอเดียดีมาก ความท้าทายใหญ่สุดของเครื่องมือความปลอดภัยแบบนี้คือความไม่เป็นเชิงกำหนดของ LLM และความเสี่ยงด้านความเป็นส่วนตัวที่โค้ดอาจถูกส่งไปยัง API ของบุคคลที่สาม นี่คือเหตุผลที่ vet พึ่งพา ShellCheck เพราะ ShellCheck เป็น linter แบบกำหนดผลได้ตามกฎ ทำงานออฟไลน์ได้ทั้งหมด และให้ผลลัพธ์ที่เชื่อถือได้เหมือนเดิมเสมอเมื่ออินพุตเหมือนกัน สำหรับการวิเคราะห์ที่ฉลาดกว่านี้ คิดว่าในอนาคต vet อาจต้องมี AI ที่รันได้เร็วและทำงานในเครื่อง เป็นประเด็นที่น่าคิดต่อมาก
  • เป็นไอเดียที่ฉลาดมาก อีกฟีเจอร์หนึ่งที่น่าสนใจคือส่งเนื้อหาเชลล์สคริปต์ให้ LLM วิเคราะห์เพื่อหาส่วนที่น่าสงสัยด้านความปลอดภัย
  • สวัสดี HN ผู้พัฒนา vet เอง ผมรู้สึกไม่สบายใจกับแพตเทิร์น curl | bash มาตลอด และคิดว่าควรมีเครื่องมือที่แสดง diff เมื่อสคริปต์เปลี่ยนไป รัน shellcheck และขอการอนุญาตอย่างชัดเจนจากผู้ใช้ก่อนรัน เลยสร้าง vet ขึ้นมา แม้แต่การติดตั้งก็ใช้หลักการเดียวกัน แนะนำให้อ่านสคริปต์ติดตั้งก่อนเสมอ ยินดีรับฟีดแบ็ก เรโปอยู่ที่ https://github.com/vet-run/vet
    • ดีใจที่ไม่ใช่มีแค่ผมคนเดียวที่กังวลเรื่องนี้ คิดว่ามันเป็นจุดที่เปิดให้ถูกโจมตีได้ง่าย รู้สึกขำที่ยก nvm มาเป็นตัวอย่างด้วย (เคยตั้งประเด็น ปัญหาคล้ายกันใน nvm มาก่อน) แต่ threat model ยังดูไม่ชัดนัก ถ้าผู้โจมตีสามารถดัดแปลง SSL แล้วส่งสคริปต์อันตรายมาได้ ก็น่าจะมีความสามารถพอจะเปลี่ยนไบนารีที่สคริปต์จริงดาวน์โหลดได้ด้วย ถึงแม้การให้ทุกคนช่วยกันดูแลการตรวจสอบด้วยคริปโตกราฟิกแฮชจะทำได้ยาก แต่ในท้ายที่สุดมันคือวิธีที่แน่นอนที่สุด 1) ดึงอินพุตระยะไกลมาแล้วเทียบกับแฮชที่ commit ไว้ 2) รันใน sandbox ที่ตัดการเชื่อมต่ออินเทอร์เน็ต 3) บล็อกรับ payload ที่มีแฮชไม่ได้รับการยืนยัน
    • ถามว่าทำไมต้อง “แสดง diff เมื่อสคริปต์เปลี่ยนและรัน shellcheck” เคยคิดหรือไม่ว่า shellcheck มีหน้าที่อะไร และคิดว่า diff จะทำงานเมื่อไร ส่วน “ขออนุญาตอย่างชัดเจนก่อนรัน” ก็ไม่มีประโยชน์ถ้าสิ่งที่เปลี่ยนมีแค่การจัดย่อหน้า เชลล์สคริปต์ขนาดเล็กยังพออ่านได้เร็ว แต่ตัวติดตั้งขนาดใหญ่ก็มักมีสไตล์โค้ดที่อ่านยากด้วยเหตุผลที่ถูกต้องหลายอย่าง เลยไม่แน่ใจว่า vet กำลังพูดถึงปรัชญาแบบไหน วิธีที่ vet ทำอยู่นั้นดูคล้ายกับแพตเทิร์นที่ผู้โจมตีใช้แจกจ่ายมัลแวร์เสียเองด้วยซ้ำ (เช่นถ้าดาวน์โหลดด้วย wget -qO- https://getvet.sh เซิร์ฟเวอร์จะตอบกลับมาเป็น text/html) กลับกัน อยากแนะนำให้ดึง install.sh โดยตรงมากกว่า และสำหรับคำขอฟีดแบ็ก ก็แนะนำทริก bash ว่า “ลองทำแบบนี้ดู”: 
      check () {
  echo "> $BASH_COMMAND" >&2
  echo -n "Allow? (yes/no) " >&2
  select c in yes no
  do
    if [ "$c" = "yes" ]
    then break
    elif [ "$c" = "no" ]
    then return 1
    fi
  done
}

shopt -s extdebug
trap check DEBUG
      วิธีนี้จะให้ bash ขออนุญาตทุกครั้งก่อนจะรันอะไรสักอย่าง สคริปต์ยาว ๆ อาจน่ารำคาญ จึงอาจปรับแต่งให้มี whitelist สำหรับคำสั่งที่คิดว่าปลอดภัย หรือมีตัวเลือก “remember” ได้ ส่วนเรื่อง sudo มัลแวร์อาจใช้วิธีรัน sudo กับคำสั่งที่ดูไม่มีพิษภัยก่อนเพื่อแคช credential เอาไว้ แล้วค่อยรันคำสั่ง sudo อีกทีในภายหลังโดยไม่มีการเตือนใด ๆ ดังนั้นการใช้ sudo -k เพื่อล้าง session cache ก่อนรันโปรแกรมที่ไม่รู้จักจึงปลอดภัยกว่า
    • ชื่นชมความพยายามที่เห็นปัญหาแล้วพยายามสร้างทางแก้ แต่หน้าที่ดั้งเดิมของ shellcheck ไม่ใช่การสแกนไวรัสหรือช่องโหว่ เลยคิดว่าทิศทางของ vet อาจไม่ได้มีประสิทธิผลมากนัก
    • ตัวไอเดียนั้นดี vet น่าจะมีประโยชน์สำหรับนักพัฒนาที่มองเห็นซอร์สโค้ดได้ชัดและอ่านเองได้โดยตรง ตอนนี้ฝีมือของตัวเองยังไม่ถึง เลยไม่แน่ใจว่าตัวเองอยู่ฝั่งผู้ใช้ส่วนใหญ่หรือผู้ใช้ส่วนน้อย