พบมัลแวร์ธีม Shai-Hulud ในไลบรารีฝึก AI ของ PyTorch Lightning

 (semgrep.dev)
3 คะแนน โดย GN⁺ 2026-05-02 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เวอร์ชัน 2.6.2 และ 2.6.3 ของเฟรมเวิร์กดีปเลิร์นนิง lightning ถูกใช้ในการโจมตีแบบ supply chain — แค่รัน pip install lightning ก็จะมีการ รัน JavaScript payload ที่ถูกทำให้อ่านยากโดยอัตโนมัติ จากไดเรกทอรี _runtime ที่ซ่อนอยู่
  • เนื่องจากเป็นเฟรมเวิร์กที่ถูกใช้อย่างแพร่หลายสำหรับการสร้างตัวจำแนกภาพ, การ fine-tuning LLM, โมเดล diffusion, การพยากรณ์อนุกรมเวลา ฯลฯ จึงมีความเป็นไปได้สูงว่า รวมอยู่ใน dependency tree ของหลายทีม AI/ML อยู่แล้ว
  • เมื่อมัลแวร์เริ่มทำงาน มันจะสแกนมากกว่า 80 พาธในไฟล์ซิสเต็มภายในเครื่องเพื่อ ขโมย GitHub token (ghp_, gho_), npm token (npm_), environment variable และ cloud secret โดยประมวลผลไฟล์ได้สูงสุดไฟล์ละ 5MB
  • มันจะ ไล่ตรวจและดึง secret จากผู้ให้บริการคลาวด์รายใหญ่ทั้ง 3 ราย ได้แก่ AWS (credential file, IMDSv2, ECS, Secrets Manager, SSM), Azure (Key Vault) และ GCP (Secret Manager)
  • ในสภาพแวดล้อม GitHub Actions มันจะใช้ Python ที่มีมาในระบบเพื่อ dump หน่วยความจำของโปรเซส Runner.Worker แล้วดึง secret ทั้งหมดที่ถูกระบุด้วย "isSecret":true รวมถึงข้อมูล repository และ workflow
  • จุดเริ่มต้นคือ PyPI (Python) แต่ การแพร่กระจายแบบเวิร์มขยายผ่าน npm (JavaScript) — โดยใช้ npm token ที่ขโมยมาเพื่อฉีด dropper (setup.mjs) และมัลแวร์ (router_runtime.js) เข้าไปในทุกแพ็กเกจที่มีสิทธิ์เผยแพร่ได้ จากนั้นเพิ่ม patch version แล้วเผยแพร่ใหม่ ทำให้เครื่องของนักพัฒนาปลายทางที่ติดตั้งแพ็กเกจเหล่านั้นติดเชื้อเป็นลูกโซ่
  • การขโมยข้อมูลไม่อาศัยเพียงเส้นทางเดียวเพื่อให้บล็อกได้ยาก แต่ใช้ 4 ช่องทางแบบขนาน พร้อมกัน: ① ส่งไปยัง C2 server ผ่าน HTTPS POST, ② ใช้ GitHub commit search API เป็น dead drop (ฝัง token ที่เข้ารหัส Base64 สองชั้นไว้ใน commit message), ③ commit เป็น results-<timestamp>.json ไปยัง GitHub repository สาธารณะที่ใช้ชื่อจากจักรวาล Dune, ④ push ตรงเข้าไปยัง repository ของเหยื่อ
  • หลังเจาะเข้า repository ได้แล้ว มันจะ ฝัง persistence hook ลงในเครื่องมือนักพัฒนาเพื่อให้ติดเชื้อซ้ำได้เสมอ — เขียน SessionStart hook ลงใน .claude/settings.json ให้รันอัตโนมัติเมื่อเริ่มเซสชัน และฝังงาน runOn: folderOpen ลงใน .vscode/tasks.json ให้รันทุกครั้งที่เปิดโฟลเดอร์
    • ทั้งสอง hook จะเรียก dropper แบบ self-contained คือ setup.mjs และหากไม่มี Bun runtime ก็จะดาวน์โหลดอย่างเงียบ ๆ จาก GitHub เพื่อรัน payload router_runtime.js ขนาด 14.8MB
  • หากได้ GitHub token ที่มีสิทธิ์เขียน มันจะ push workflow ปลอมชื่อ Formatter เข้าไปใน repository ของเหยื่อ — เพื่อ dump repository secret ทั้งหมดด้วย ${{ toJSON(secrets) }} ในทุก push และอัปโหลดเป็น Actions artifact
  • ทุกเครื่องที่ติดตั้งเวอร์ชันดังกล่าวในช่วงเวลาที่ได้รับผลกระทบ ควรถูกมองว่าถูก compromise ทั้งหมดแล้ว และควรหมุนเปลี่ยน GitHub token, cloud credential, API key ทันที พร้อมตรวจสอบไดเรกทอรี .claude/ และ .vscode/ ว่ามีไฟล์ที่ไม่คาดคิดหรือไม่
  • ตัวบ่งชี้การโจมตี: prefix EveryBoiWeBuildIsAWormyBoi ใน commit message, "A Mini Shai-Hulud has Appeared" ในคำอธิบาย repository, และการมีอยู่ของไดเรกทอรี _runtime/ ภายใน repository ซึ่งสามารถ ตรวจสอบได้โดยตรงผ่านการค้นหาใน GitHub

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

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

 
picopress 2026-05-03

งั้นตอนนี้คงอัปเดตไม่ได้แล้ว...
 
GN⁺ 2026-05-02
ความเห็นจาก Hacker News

  • อาจเป็นแค่ ความลวงจากความถี่ แต่ช่วงนี้ดูเหมือนมี การโจมตีซัพพลายเชน ที่เป็นข่าวดังเกิดกับแพ็กเกจสำคัญค่อนข้างบ่อย
    แม้แต่ในหน้าแรก ๆ ของ HN ตอนนี้ก็ยังมีหลายโพสต์ที่พูดถึงกรณีคนละแบบกัน
    พอมองย้อนกลับไปถึง left-pad เมื่อ 10 ปีก่อน ก็อดสงสัยไม่ได้ว่าตอนนี้การโจมตีที่สำเร็จมีมากกว่าเมื่อก่อนหรือไม่ และก็น่าจะใช่
    มูลค่าของการโจมตีที่สำเร็จก็น่าจะสูงขึ้นอย่างชัดเจนด้วย แต่ก็สงสัยว่าความสามารถในการตรวจจับก่อนปล่อยแพ็กเกจนั้น ในภาพรวมของทั้งคอมมูนิตี้ดีขึ้นจริงหรือเปล่า
    บริษัทซอฟต์แวร์เชิงพาณิชย์ควรทำได้ดีกว่านี้ แต่สำหรับกรณีที่เริ่มจากโค้ดงานอดิเรก/สมัครเล่นแล้วกลายเป็น dependency ของหลายโปรเจ็กต์ ดูเหมือนเรายังขาดเครื่องมือที่ใช้ง่ายและใช้ได้ทั่วไป
    ผมโพสต์คอมเมนต์เดียวกันนี้ไว้ในเธรดเรื่อง SAP supply chain attack ด้วย: https://news.ycombinator.com/item?id=47964003

    • เป็นแนวโน้มจริง ณ ต้นเดือนเมษายน ในช่วง 12 เดือนล่าสุดมี 7 กรณี ขณะที่ 20 ปีก่อนหน้านั้นมี 9 กรณี: https://www.jefftk.com/p/more-and-more-extensive-supply-chai...
    • ตอนนี้ผู้คนเอาโค้ดมายัดใส่กันเป็นจำนวนมากโดยแทบไม่อ่านให้ดี ดังนั้นการที่ การโจมตีซัพพลายเชน เพิ่มขึ้นก็เป็นเรื่องธรรมชาติ
    • สาเหตุคือ การอัปเดตอัตโนมัติ และเครื่องมือ CI ไปถึงจุดที่ใช้กันแทบทุกคนแล้ว
      เมื่อก่อนคนมักรัน npm install เองด้วยมือมากกว่า และคงทำตอนบิลด์พังหรือไม่ก็นาน ๆ ที
      การโจมตีซัพพลายเชนอาศัยการที่คน หรือพูดให้แม่นกว่านั้นคือ pipeline อัปเดตแพ็กเกจอัตโนมัติทันทีที่มีรีลีสใหม่โดยไม่คิดมาก
    • ในเชิงประวัติศาสตร์ การจัดการอาร์ติแฟกต์ที่ผ่านการตรวจสอบความปลอดภัยเพิ่มเติมมักเป็น ออปชัน enterprise แบบเสียเงิน และฝั่งที่ปลอดภัยน้อยกว่ากลับเป็นค่าเริ่มต้นที่ยุ่งยากน้อยกว่ามาก
      ไม่แน่ใจว่านี่เป็นโมเดลธุรกิจที่ดีไหม และก็น่าจะไม่ค่อยดี
    • left-pad ไม่ใช่การโจมตี แต่เป็น บั๊กของ NPM
      ไม่ควรจะสามารถลบเวอร์ชันของแพ็กเกจที่มีแพ็กเกจสาธารณะอื่นพึ่งพาอยู่ได้ และในทางกลับกันก็ควรลบเวอร์ชันใหม่ของแพ็กเกจเฉพาะที่ยังไม่มีใครพึ่งพาได้
      ตอนที่ผู้เขียน left-pad พยายามลบข้อมูลทั้งหมดเพราะตั้งใจจะออกจากบริการ NPM ควรคืน error code กลับมา
      ตาม Wikipedia เมื่อ Koçulu ไม่พอใจกับการตัดสินใจของ npm, Inc. และบอกว่าไม่อยากเป็นส่วนหนึ่งของแพลตฟอร์มอีกต่อไป Schlueter ผู้สร้าง NPM ก็ได้ออกคำสั่งลบโมดูล 273 ตัวที่เขาลงทะเบียนไว้

  • เรื่องแปลกคือมี รายงานปัญหาความปลอดภัย 4 รายการ ถูกเปิดขึ้นมา แล้วทั้งหมดโดนบอตชื่อ pl-ghost คอมเมนต์อัตโนมัติและปิดไป [1][2][3][4]
    สุดท้ายมีแค่ [4] ที่ถูกจัดการอย่างถูกต้อง และคอมเมนต์ของบอตก็ถูกลบทั้งหมด
    ในรายงานอีกฉบับ [5] ยังเห็นคอมเมนต์ของบอตได้ และมันให้ข้อมูลมากกว่าต้นฉบับด้วย
    [1] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [2] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [3] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [4] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [5] https://socket.dev/blog/lightning-pypi-package-compromised

    • ผมคือ Andy จาก Lightning ใช่แล้ว ข้อมูลรับรอง PyPI ถูกขโมยผ่าน บัญชีบอต pl-ghost ที่ถูกเจาะ
      ผู้โจมตีใช้บัญชีนี้สร้าง workflow ใหม่ของ Actions และใน workflow ที่รันนั้นก็พาร์สและดึงค่า secret ของ PyPI ออกไป
      หลังจากปล่อยแพ็กเกจแล้วก็ยังใช้บัญชีนั้นมาคอมเมนต์เหมือนเยาะเย้ยพวกเราเล็กน้อยด้วย

  • หวังว่าวันที่ไม่มี dependency เลยจะมาถึงเร็ว ๆ
    เอาแบบสุดโต่ง ตอนนี้เวลาสร้างแอปการศึกษาแบบ interactive ให้ลูกสาว ผมให้ Opus ใช้แค่ JavaScript กับ HTML ล้วน ๆ
    ตั้งแต่ลูกตุ้มคู่ไปจนถึงการจำลองของไหลก็ทำงานได้ดีในครั้งเดียว ทั้งที่เมื่อก่อนต้องมี dependency เป็นร้อย
    ถ้าเป็นโค้ดภายใต้ MIT license ก็สามารถบอก Opus ให้ดึงเฉพาะส่วนที่ต้องใช้มาปรับให้เข้ากับงานของผมแล้วรวมเข้าไปได้ตรง ๆ
    สำหรับโปรเจ็กต์งานอดิเรก วิธีนี้เวิร์กดีจนถึงตอนนี้ และหวังว่าอนาคตซอฟต์แวร์ production ก็จะลด dependency ลงได้

    • ถ้าทำแบบนั้น คุณก็ต้องรับภาระจัดการการเปลี่ยนแปลงทั้งหมดและข้อยกเว้นนับไม่ถ้วนเอง
      ถ้า Chrome เปลี่ยนรูปแบบ API บางตัว คุณต้องไปไล่แก้เอง และถ้าโมร็อกโกเปลี่ยนวันเริ่มใช้เวลาออมแสง คุณก็ต้องอัปเดตโค้ดจัดการวันเวลาเองด้วย
      เรื่องแบบนี้เราเคยชินกับการให้ไลบรารีจัดการให้แทน
      สำหรับ ตัวจำลองลูกตุ้มคู่ ที่ลูกสาวคุณอาจเลิกสนใจในสัปดาห์หน้า มันอาจไม่ใช่เรื่องใหญ่ แต่ถ้าเป็นบริษัทที่สร้างอะไรซึ่งต้องทำงานไปเรื่อย ๆ แบบไม่มีกำหนด นี่คือปัญหา
    • แบบนั้นก็เท่ากับไปผูกกับ dependency ที่เป็นของจริงอย่าง เบราว์เซอร์ แทน
    • แน่นอนว่าคุณจะตรวจทุกบรรทัดของโค้ดที่ Opus สร้างออกมาอย่างละเอียดในระดับเดียวกับที่คาดหวังจากผู้ดูแลโอเพนซอร์สใช่ไหม? ใช่ไหม?
      สงสัยต้องปล่อยโค้ด MIT license ที่เปิด remote access สักตัว เพื่อให้เข้าไปอยู่ในข้อมูลฝึกของ Opus
    • ผมชอบ Rust มากกว่า Go เลยลังเลอยู่ จากมุมมอง LLM เอง Rust ก็ดีกว่า แต่ ปรัชญาเรื่อง dependency ของ Rust นี่แทบเป็นหลุมดำด้านความปลอดภัย ส่วน Go ดีกว่ามาก
    • มีเก็บไว้ใน repo หรือ forge ที่แชร์ได้ไหม? ผมมีเกมสะกดคำเกี่ยวกับสัตว์ในฟาร์มอยู่ แล้วอยากขยายไลบรารีกับต่อยอดไอเดียเพิ่ม

  • ตอนเรียนคอร์ส deep learning ของ Fast.AI ผมตกใจกับจำนวน dependency ของ Python ที่โปรเจ็กต์ machine learning ดึงเข้ามา
    โปรเจ็กต์เว็บฟรอนต์เอนด์ถูกมองว่ามี third-party dependency เยอะมาโดยตลอด แต่สำหรับผม ecosystem ของ machine learning ดูพันกันยิ่งกว่า
    แถมวงการเว็บยังถูกมองว่าอ่อนไหวต่อความปลอดภัย จึงสั่งสมภูมิปัญญาและแนวปฏิบัติด้านความปลอดภัยมานานแล้ว แต่การพัฒนา machine learning ดูเฉพาะกิจมากกว่า และเหมือนยังไม่ค่อยเอาแนวปฏิบัติวิศวกรรมซอฟต์แวร์ทั่วไปมาใช้
    ตัวอย่างเช่น ตอนนั้นหนึ่งในวิธี deploy โมเดล machine learning คือใช้ Python pickle ซึ่งเป็นออบเจ็กต์ที่รันได้โดยแทบไม่มีข้อจำกัดในตัว
    โมเดลในรูปแบบนี้สามารถทำอะไรก็ได้บนเครื่องที่ import มันเข้าไป และ ecosystem แบบแดนเถื่อน ในช่วงแรกเช่นนี้ย่อมทำให้การเจาะระบบและการโจมตีซัพพลายเชนเกิดได้ง่ายขึ้น

    • แต่เดิมใน ecosystem นี้มีคนจำนวนมากที่ไม่ใช่วิศวกรซอฟต์แวร์
      บางคนทำไปทำมาก็พอเขียนโค้ดได้นิดหน่อย บางคนเป็นนักคณิตศาสตร์ และบางคนก็เหมือนนักพัฒนาที่เมา AI
      มีแนวคิดแบบ “โค้ดไม่สำคัญแล้ว แค่ให้มันรันได้ก็พอ” อยู่ด้วย
      สำหรับหลายคน การจัดการ dependency ที่ถูกต้องก็เป็นแค่งานจุกจิกที่ไม่อยากสนใจ
      ปัจจัยเหล่านี้มารวมกันในหลายโปรเจ็กต์ machine learning ทั้งที่จริงแล้ว machine learning กลับเป็นหนึ่งในสาขาที่ควรให้ความสำคัญกับ reproducibility มากที่สุด

  • ลองค้นใน repository ดูแล้วพบว่าในช่วง 24 ชั่วโมงที่ผ่านมา มี repository ที่สร้างใหม่และมีข้อความ "A Mini Shai-Hulud has Appeared" อยู่ถึง 2.2 พันรายการ: https://github.com/search?q=A%20Mini%20Shai-Hulud%20has%20Ap...

    • ดูเหมือนชื่อ repository ทั้งหมดจะเป็นคำ/ศัพท์จาก dune สองคำ เช่น harkonen, mentat, ornithoptor แล้วตามด้วยตัวเลข
      นี่ดูเหมือนเป็นสัญญาณว่ามีบัญชีบางบัญชี หรืออาจเป็น GitHub auth/Actions token ถูกเจาะแล้วถูกใช้สร้าง repository
    • https://github.com/tinin46 บัญชีนี้ดูเหมือนเก็บกุญแจไว้เยอะมาก แต่ผมไม่แน่ใจว่าเอาไว้ทำอะไร
    • ไม่เข้าใจว่าทำไม GitHub ถึงไม่รีบจัดการและบล็อก repository ที่ README ตรงกับ regex นี้ได้ทันที
      เรื่องแบบนี้เคยเกิดมาแล้ว น่าจะได้บทเรียนบ้าง
      มัลแวร์ตัวนี้แทบไม่ต้องพยายามอะไรเลย และ Microsoft ก็ดูเหมือนแทบไม่พยายามเช่นกัน
    • นี่มันเกิดอะไรขึ้นกันแน่?

  • ขอย้ำก่อนว่าผมไม่เคยใช้ pytorch และก็ไม่ค่อยรู้เรื่องแนวปฏิบัติด้านความปลอดภัยของซอฟต์แวร์
    แต่ผมนึกแทบไม่ออกว่ามีกรณีไหนที่ pytorch ต้องการ การเข้าถึงเครือข่าย
    การที่โมดูลอะไรก็ได้ใน codebase import แล้วใช้ API แบบนั้นได้จากตรงไหนก็ได้ ดูไม่ถูกต้อง
    น่าจะต้องมีข้อจำกัดเรื่อง import เพิ่มเติมหรือมี static analysis
    ภาษาดูเหมือนยังไม่มี abstraction ที่เหมาะสมสำหรับจัดการปัญหาแบบนี้
    เทียบกันแล้วสิ่งที่ชอบใน Rust คือแค่ดู function signature ก็เห็นเรื่อง mutability และ lifetime ได้โดยไม่ต้องเข้าใจโค้ดภายใน
    รู้สึกว่า dependency ก็ควรมีอะไรคล้ายกัน
    นักพัฒนาควรตรวจสอบ dependency ทั้งหมดได้ง่ายโดยไม่ต้องไปขุดโค้ดข้างใต้ เช่นดูแล้วรู้ว่า “อ้อ dependency ตัวนี้ใช้ eval()” หรือ “มีการเข้าถึงเครือข่าย”
    แอปมือถือบังคับใช้ permission อยู่แล้ว นักพัฒนาก็น่าจะต้องสามารถ whitelist ได้ว่าต้องการแค่ความสามารถบางอย่าง แทนที่จะยอมรับฟีเจอร์ทุกอย่างทั้งก้อน

    • ecosystem ของ Python คงไม่มีวันยอมเรื่องแบบนี้ แต่ก็หวังว่าประเด็นนี้จะถูกเข้าใจและยอมรับมากขึ้นในวงการนั้น
      ไม่อยากเหมารวม แต่โดยเฉพาะคอมมูนิตี้นักพัฒนา AI ดูเหมือนจะให้ ความสะดวก มาก่อนทุกสิ่ง
      ตัวอย่างเช่น การที่โปรเจ็กต์ดาวน์โหลดโมเดลขนาดใหญ่โดยอัตโนมัติในครั้งแรกที่รัน ดูแทบจะกลายเป็นมาตรฐานไปแล้ว
      ส่วนใหญ่ปิดได้ก็จริง แต่เพราะโค้ดมีชั้นลึกของคลาสจากหลายไลบรารี การหาพารามิเตอร์ที่ถูกต้องจึงทรมานมาก
      ข้อดีคือมันทำให้เริ่มต้นกับสิ่งซับซ้อน ซึ่งส่วนใหญ่ก็เกือบเป็นของเล่น ได้ง่ายมาก แต่บรรยากาศแบบปล่อยผ่านนี้ก็น่าอึดอัดพอสมควร
      ขั้นแรกของการแก้ปัญหาดูเหมือนจะเป็น “pip install …” เสมอ และบางสภาพแวดล้อม เช่น MacOS ก็ยัง virtualize การเข้าถึง GPU ได้ไม่ดีนัก
    • มีกรณีที่ฝึกโมเดลข้ามหลาย compute node อยู่ นั่นเป็นตัวอย่างใหญ่ที่ต้องใช้ การเข้าถึงเครือข่าย

  • สัปดาห์นี้ผมกำลังสงสัยว่าการใช้ uv จัดการเวอร์ชัน Python เป็นความคิดที่ดีไหม
    ในเว็บไซต์ [1] เขียนว่า “Python ไม่มีไบนารีอย่างเป็นทางการสำหรับการแจกจ่าย ดังนั้น uv จึงใช้ดิสทริบิวชันจากโครงการ Astral python-build-standalone”
    มันชี้ไปที่ GitHub repo นี้ https://github.com/astral-sh/python-build-standalone และที่นั่นก็อ้างถึง https://gregoryszorc.com/docs/python-build-standalone/main/r... อีกที
    ถ้าผมเข้าใจถูก ดูเหมือนมันไม่ได้ดึงซอร์สโค้ดสำหรับ build Python มาจาก python.org โดยตรง และผมไม่แน่ใจว่าปลอดภัยแค่ไหน
    asdf [2] ก็มีข้อกังวลคล้ายกัน แต่ asdf ใช้ pyenv [3] ซึ่งให้ความรู้สึกใกล้กับของทางการมากกว่า
    มีใครอธิบายได้ไหมว่าระหว่าง uv กับ asdf เครื่องมือไหนดีกว่าและปลอดภัยกว่าสำหรับติดตั้ง Python
    [1] https://docs.astral.sh/uv/guides/install-python/
    [2] https://github.com/asdf-community/asdf-python
    [3] https://github.com/pyenv/pyenv/tree/master/plugins/python-bu...

    • python-build-standalone ดึง ซอร์ส CPython จาก python.org โดยตรงอยู่แล้ว[1]
      เอาจริงก็ไม่รู้จะไปดึงจากที่อื่นทำไม
      [1]: https://github.com/astral-sh/python-build-standalone/blob/a2...
    • ผมไม่ได้กังวลเรื่อง uv กับ cpython เท่าไร กระบวนการเขาแข็งแรง ตอบสนองเร็ว และตอนนี้ก็มีเงินทุนมากพอสมควร
      สิ่งที่กังวลคือพวก formatter อย่าง mdformat ที่มีคนใช้กว้างขวางแต่หลัก ๆ มีคนเดียวดูแลในเวลาว่าง หรือ dependency เฉพาะทางมาก ๆ ที่ไม่ได้อัปเดตมาหลายปีและอยู่ลึกลงไปสามชั้นใน dependency tree
      ผมไม่อยาก pin ทุกอัปเดตแล้วอนุมัติด้วยมือตลอดในแอปที่พัฒนาอย่างต่อเนื่อง แต่สำหรับแอปจริงจัง ตอนนี้มันเริ่มดูเหมือนเป็นสิ่งจำเป็น
      ระหว่างนี้คงต้องไปดึง API key ออกจากไฟล์ .env ที่ไม่ได้เข้ารหัส
      ถ้าโดนในเว็บแอปผู้บริโภคขนาดใหญ่ก็น่าอายแต่พอเข้าใจได้ แต่การเสียเงินหลายร้อยถึงหลายพันดอลลาร์เพราะ indirect dependency ของ demo repo เล่น ๆ ที่ดันอยู่บนโฮสต์และระบบเดียวกันนี่เจ็บเกินไป
      มีใครรู้ไหมว่าถ้าคีย์ถูกขโมยแบบนี้ OAI หรือ Anthropic คืนเงินให้หรือเปล่า หรือถือว่าเป็นความผิดพลาดของผู้ใช้เอง?
    • แต่ตั้งแต่แรก uv ก็คือ ไบนารี ที่คุณเอามารันบนเครื่องเพื่อจัดการ Python binaries, packages, binaries ที่อยู่ในนั้น, เครื่องมือทั้งระบบ ฯลฯ
      ไม่ว่าพวกเขาจะ build Python binary เองหรือให้คนอื่น build ให้ ผมก็ไม่แน่ใจว่าความเสี่ยงต่างกันมากแค่ไหน

  • เดี๋ยวนี้ pip install ของผมส่วนใหญ่เกิดจาก Claude Code แนะนำ แล้วผมก็กด Enter ตามไปเลย
    โมเดลถูกฝึกจากข้อมูลเมื่อหลายเดือนก่อน ดังนั้นมันไม่มีทางรู้หรอกว่าสัปดาห์นี้อะไรถูกเจาะไปบ้าง
    เท่ากับว่าผมสร้างตัวกรองที่แย่ที่สุดขึ้นมาเองในการตัดสินว่า “แพ็กเกจนี้ตอนนี้ปลอดภัยไหม”

    • อย่าไปโทษ LLM สำหรับความขี้เกียจและการไม่ทำ due diligence ของตัวเองเลย
    • หมายถึงตัวกรองอะไร?
      คุณบอกว่าปล่อยให้ Claude Code แนะนำซอฟต์แวร์จากอินเทอร์เน็ตที่จะติดตั้ง แล้วคุณก็ติดตั้งตามนั้น
      ผมไม่เคยได้ยินว่า Claude Code หรือ LLM ตัวไหนถูกเสนอให้เป็นตัวกรองสำหรับตัดสินว่า “แพ็กเกจนี้ตอนนี้ปลอดภัยไหม” และด้วยเหตุผลที่คุณเองก็พูดมา มันเป็น heuristic ที่แย่มาก
    • ข้อมูลฝึกที่เก่าเป็นส่วนหนึ่งของปัญหาก็จริง แต่ถึงเป็นโมเดลล่าสุด มันก็ไม่มีทางรู้ได้ว่า setup.py จะรันอะไรบนเครื่องของผม
      เพราะไม่มีอะไรตรวจแพ็กเกจก่อนรันจริง
      สิ่งที่ต้องการคือเครื่องมือที่ดึง metadata มาก่อนแล้วเช็กว่ามี hook อะไรบ้างก่อน execution
    • ถ้าไม่กด Enter ก็หลีกเลี่ยงได้ง่าย
    • “ตัวกรองที่แย่ที่สุด” หมายถึงการกด Enter ตามที่ Claude บอกงั้นเหรอ?

  • Claude Code อัปเดตแทบทุกวัน บางทีก็หลายครั้งต่อวัน
    ถ้าวันหนึ่ง Anthropic ถูกเจาะ พวกเราคงเจ็บหนักกันทุกคน

    • “พวกเรา” หมายถึงใครบ้าง?
    • ถ้ารันมันใน VM/คอนเทนเนอร์ ที่ไม่มีสิทธิ์และจำกัดการเข้าถึงเครือข่าย ก็ไม่ถึงขนาดนั้น
      แต่ทุกวันนี้ทุกอย่างเป็นแบบ YOLO กันหมด
    • เหมือนเรื่องนี้น่าจะถูกสะท้อนไปในราคาของ Polymarket แล้ว

  • ผมเห็นข้อความนี้บน GitHub ที่โพสต์เมื่อ 20 เมษายน แล้วค่อนข้างสับสน
    "deependujha hi @thebaptiste, thanks for inquiring. Release of 2.6.2 is blocked due to some internal reasons. Will notify once release is made."
    ถ้าพวกเขารู้ปัญหาตั้งแต่ตอนนั้นแต่ยังไม่เตือนจนถึงตอนนี้ ผมคงไม่พอใจมาก
    อยากให้คนที่รู้มากกว่ามาอธิบายให้ชัดเจนหน่อย
    https://github.com/Lightning-AI/pytorch-lightning/issues/216...

    • ผมคือ Andy จาก Lightning แพ็กเกจอันตรายถูกเผยแพร่ขึ้น PyPI วันนี้เวลา 12:45 PM UTC
      ก่อนหน้านั้นยังไม่มีดิสทริบิวชันที่ได้รับผลกระทบ และเราก็ยังไม่รู้ว่ามีการรั่วไหลเกิดขึ้น
      รีลีสดั้งเดิมบน GitHub ไม่มีปัญหา แต่เราถอดมันลงไว้ชั่วคราวเพื่อเลี่ยงความสับสน
    • สำหรับคนที่ใช้ uv: https://docs.astral.sh/uv/reference/settings/#exclude-newer