uv 0.13.5 อุดความเชื่อใจใบรับรองเก่า แต่อัปเดตแล้วต้องเช็กทุกโปรเจกต์

uv 0.13.5 ปรับชุด CPython ตั้งแต่ 3.11 ขึ้นไปที่เครื่องมือดาวน์โหลดมาให้ โดยใส่ pip 26.2.2 และ certifi 2026.10.19 ซึ่งตัดใบรับรองราก eMudhra/emSign ที่เกี่ยวข้องกับเหตุความปลอดภัยออกแล้ว แต่สภาพแวดล้อมทำงานเก่าไม่ได้เปลี่ยนตามทั้งหมดโดยอัตโนมัติ (GitHub) สำหรับคนใช้ Python ทำรายงาน งานเรียน หรือระบบธุรกิจ ประเด็นจึงอยู่ที่การตามอัปเดตให้ถึงโปรเจกต์ที่ใช้งานจริง ไม่จบแค่เครื่องมือหลักขึ้นเลขใหม่ครับ

uv คือเครื่องมือจัดการ Python และชุดโปรแกรมเสริมของ Astral ส่วน pip คือเครื่องมือติดตั้งชุดโปรแกรมเสริมเหล่านั้น รุ่นนี้แก้ทั้งฝั่ง uv เองและ Python ที่ uv ติดตั้งให้ ซึ่งเป็นคนละส่วนของงานตรวจสอบใบรับรอง (GitHub) ถ้าคุณไม่ได้ดูแลระบบเอง บทความนี้ช่วยให้คุยกับคนดูแลได้ตรงจุดว่าอัปเดตอะไรแล้ว และยังเหลืออะไรต้องตรวจ

สรุป 30 วินาที: เกิดอะไรขึ้น

เหตุความปลอดภัยที่เกี่ยวกับใบรับรองตัวกลางของ eMudhra ทำให้ต้องนำใบรับรองราก emSign ที่ได้รับผลกระทบออกจากชุดใบรับรองที่ซอฟต์แวร์เชื่อถือ Python.org เตือนว่าหากไม่ปรับปรุง อาจเสี่ยงต่อการถูกแทรกกลางการเชื่อมต่อที่ใช้ TLS หรือระบบตรวจสอบและปกป้องการเชื่อมต่อ รวมถึงการเชื่อมต่อกับ python.org และ pypi.org ซึ่งเป็นแหล่งซอฟต์แวร์ Python (Python.org)

uv 0.13.4 นำใบรับรองรากที่มีปัญหาออกจากชุดของตัวเองแล้ว ส่วน 0.13.5 เพิ่มการปฏิเสธสายใบรับรองที่มีคีย์ตัวกลาง eMudhra ที่ถูกกระทบ โดยคีย์ในที่นี้คือข้อมูลกุญแจที่ใช้กับการรับรองความน่าเชื่อถือ และยังปรับ Python ที่ดาวน์โหลดมาให้ใช้ชุดใบรับรองใหม่ด้วย (Astral Changelog)

สิ่งที่ต้องจำมีสามชั้น: อัปเดต uv, อัปเดต Python ที่ uv จัดการ และจัดการ pip ในแต่ละ virtual environment หรือพื้นที่แยกชุดโปรแกรมของแต่ละโปรเจกต์ รายงานของ Jason Vs The Noise ย้ำว่าการเปลี่ยนตัว uv ไม่ได้เปลี่ยนพื้นที่เก่าเหล่านั้นให้เอง (Jason Vs The Noise)

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าคุณเป็นพนักงานที่รันงาน Python ประจำ นักศึกษาที่มีหลายโปรเจกต์ หรือเจ้าของกิจการที่มีทีมดูแลระบบ สิ่งที่ควรถามคือโปรเจกต์เหล่านั้นใช้ pip ตัวไหนอยู่ เพราะ Python.org อธิบายว่า pip มี certifi ของตัวเองติดมาด้วย และยังอ่านชุดนั้นร่วมกับชุดที่ระบบปฏิบัติการเชื่อถือ การปรับความเชื่อถือของระบบปฏิบัติการอย่างเดียวจึงไม่พอสำหรับ pip แบบที่ประกาศนี้กล่าวถึง (Python.org)

certifi คือรายชื่อผู้ออกใบรับรองที่ Python เชื่อถือ ใบรับรองรากคือจุดเริ่มต้นความเชื่อถือ ส่วนใบรับรองตัวกลางเชื่อมความเชื่อถือนั้นไปยังใบรับรองปลายทาง ในกรณีนี้ทั้ง uv และ pip ต้องได้รับการดูแล เพราะมีการตรวจสอบใบรับรองของตัวเองแยกกัน (Jason Vs The Noise) พูดให้ง่ายขึ้น การเห็น uv เป็นรุ่นใหม่ยังไม่ใช่หลักฐานว่าโปรเจกต์ทั้งหมดใช้ชุดความเชื่อถือใหม่แล้ว

ธุรกิจในไทยที่ใช้ uv ก็ควรเช็กตามแนวทางนี้ แต่แหล่งข้อมูลที่ให้มายังไม่ระบุว่ามีองค์กรไทยได้รับผลกระทบหรือมีความเสียหายเท่าไร และรายงาน Jason Vs The Noise ระบุว่าทั้ง uv และ CPython ไม่ได้กล่าวว่ามีการปลอมแหล่งแจกแพ็กเกจเกิดขึ้นแล้ว จึงควรแยกความเสี่ยงที่ต้องแก้ ออกจากเหตุโจมตีที่ยืนยันแล้ว (Jason Vs The Noise)

ทำงานยังไง

managed Python หมายถึง Python ที่ uv ดาวน์โหลดมาให้ สำหรับรุ่นนี้ชุด CPython ซึ่งเป็นตัว Python ที่กล่าวถึงในประกาศ ตั้งแต่ 3.11 ขึ้นไป เปลี่ยนไปใช้ชุดสร้างสำเร็จ python-build-standalone 20261021 โดยรวม CPython 3.15.1, 3.14.9 และ 3.13.17 ซึ่งเป็นรุ่นแก้ความปลอดภัยไว้ด้วย (GitHub)

ในชุดที่อัปเดตมี pip 26.2.2 สองตำแหน่ง คือส่วนที่ติดตั้งพร้อมตัว Python และส่วนที่บรรจุอยู่กับ ensurepip ซึ่งเป็นองค์ประกอบที่เตรียม pip ให้เมื่อสร้างพื้นที่แยกด้วย python -m venv ทั้งสองส่วนใช้ certifi 2026.10.19 ที่ถอดใบรับรองรากที่มีปัญหาออกแล้ว (Astral Changelog) ความต่างนี้มีผลต่อทั้ง Python ที่เพิ่งติดตั้งและพื้นที่โปรเจกต์ที่กำลังจะสร้างใหม่

เปรียบเหมือน เปลี่ยนรายชื่อคนที่ รปภ. ยอมให้เข้าตึก แต่ตึกเก่าที่สร้างไปแล้วต้องเอารายชื่อใหม่ไปแปะเอง การเปลี่ยนเครื่องมือที่ใช้สร้างตึกจึงไม่ได้ทำให้รายชื่อในทุกตึกเก่าถูกเปลี่ยนตาม ในข่าวนี้ตึกเก่าก็คือพื้นที่โปรเจกต์ที่ยังมี pip และ Python ชุดเดิมอยู่ ซึ่ง Astral ระบุให้จัดการ pip แยกต่างหาก (GitHub)

อีกฝั่งหนึ่ง uv 0.13.5 ปรับส่วนตรวจสอบใบรับรอง rustls-webpki เป็น 0.103.16 เพื่อปฏิเสธสายใบรับรองที่มีคีย์ตัวกลาง eMudhra ที่ถูกกระทบ จึงมีทั้งการเอารากออกจากรายการที่เชื่อถือในรุ่นก่อน และการบล็อกคีย์ตัวกลางในตัวตรวจสอบของรุ่นนี้ (Astral Changelog)

จุดที่ควรเข้าใจคือโปรแกรมอาจเรียก pip โดยตรงภายหลัง โดยไม่ได้ย้อนกลับไปใช้ตัวตรวจสอบของ uv หาก pip นั้นยังมี certifi เก่า ก็ยังมีความเชื่อถือชุดเก่าอยู่ รายงาน Jason Vs The Noise จึงเตือนให้ตรวจเส้นทางการทำงานจริงของเครื่องมือด้วย (Jason Vs The Noise) การเช็กเฉพาะขั้นตอนดาวน์โหลดผ่าน uv จึงยังตอบไม่ได้ว่าทุกคำสั่งภายหลังใช้ชุดใหม่แล้ว

จุดสังเกต: เลข Python เดิม อาจต้องเปลี่ยนชุดติดตั้งใหม่

รายละเอียดที่ชวนพลาดคือรุ่นย่อย 3.11 และ 3.12 รายงาน Jason Vs The Noise ระบุว่าชุดสร้างสำเร็จนี้ไม่ได้แสดงการขยับเลขรุ่นของสองสายดังกล่าว ต่างจาก 3.13, 3.14 และ 3.15 จึงแนะนำให้ตรวจด้วย uv python list หลังอัปเดต และยืนยันว่า Python ที่ติดตั้งได้รับ pip 26.2.2 จริง (Jason Vs The Noise)

ส่วนพื้นที่แยกที่ตรึง Python ไว้กับรุ่นแก้ไขเก่า จะไม่สลับไปใช้ตัวแปลภาษาใหม่อัตโนมัติหลัง uv python upgrade ตามที่ Astral ระบุไว้ชัดเจน (GitHub) ดังนั้นการตรวจแค่เลขสายหลัก เช่น 3.13 โดยไม่ดูรุ่นเต็มและ pip ที่ใช้งานจริง อาจทำให้ทีมสรุปงานเร็วเกินไป

ไฟล์ล็อกซึ่งใช้บันทึกชุดแพ็กเกจของโปรเจกต์ก็ไม่ได้ตรึงรุ่นตัว uv และการสั่ง uv lock ไม่ได้เขียนพื้นที่แยกเดิมขึ้นใหม่ รายงานเดียวกันจึงย้ำว่าไฟล์ล็อกไม่ได้ทำหน้าที่อัปเดตตัวแปลภาษาหรือ pip ในพื้นที่เดิม (Jason Vs The Noise) สำหรับงานรอบนี้ ควรแยกหลักฐานว่าแก้รายการแพ็กเกจแล้ว ออกจากหลักฐานว่าสภาพแวดล้อมที่ใช้รันได้รับการแก้แล้ว

เรื่องเงิน / ผลกระทบ

แหล่งข่าวชุดนี้ไม่มีตัวเลขความเสียหาย ค่าใช้จ่ายแก้ระบบ หรือจำนวนผู้ได้รับผลกระทบในไทย จึงยังประเมินเป็นเงินบาทไม่ได้ สิ่งที่ยืนยันได้คือ Python.org ขอให้อัปเดตซอฟต์แวร์ที่เกี่ยวข้อง และสร้าง container image ใหม่โดยปิดการใช้ชั้นข้อมูลเดิมที่เก็บไว้ เพื่อให้ได้ใบรับรองระบบล่าสุด (Python.org)

container image คือชุดสภาพแวดล้อมที่เตรียมไว้สำหรับนำโปรแกรมไปรัน ส่วนการเก็บชั้นข้อมูลเดิมช่วยนำส่วนที่สร้างไว้แล้วกลับมาใช้ ตามคำแนะนำในประกาศ รอบนี้ต้องระวังว่าการสร้างใหม่ยังหยิบส่วนเก่ามาใช้หรือไม่ (Python.org) ในทางจัดการงาน ผมแนะนำให้เผื่อเวลาสำหรับสร้างชุดใหม่และทดสอบงานสำคัญ แทนการนับว่าปิดงานทันทีที่อัปเดตบนเครื่องนักพัฒนา

อีกเรื่องที่กระทบแผนทีมคือ Astral หยุดเผยแพร่ Docker image ที่มี uv บน Python 3.9 และ 3.10 ซึ่งไม่ได้รับการอัปเดตจากต้นทางแล้ว และแนะนำให้ย้ายออกจากสองสายนี้ (GitHub) Docker เป็นเครื่องมือหนึ่งสำหรับใช้สภาพแวดล้อมแบบ container ประเด็นสำหรับเจ้าของระบบจึงรวมถึงเวลาและคนที่จะย้ายงานเก่า แม้ยังไม่มีข้อมูลราคาหรืองบประมาณให้คำนวณจากข่าวนี้

ส่วนของที่ช่วยงานประจำใน 0.13.5 มีการลดหน่วยความจำสูงสุดตอนคำนวณชุดแพ็กเกจข้ามหลายสภาพแวดล้อม และเร่งการส่งออกรายการแพ็กเกจที่มีความสัมพันธ์ของส่วนเสริมซับซ้อน แต่ changelog ไม่ได้ให้เปอร์เซ็นต์ความเร็วหรือปริมาณหน่วยความจำที่ลดลง จึงยังตีมูลค่าหรือรับรองเวลาได้ไม่ได้ (Astral Changelog)

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

วันออกรุ่นมีสองวันที่ต้องแยกกัน release notes บน GitHub และ changelog ระบุว่าออกวันที่ 21 ตุลาคม 2026 ขณะที่ข้อมูลหน้ารวม GitHub ลงวันที่ 22 ตุลาคม และ Jason Vs The Noise ระบุว่าเผยแพร่วันที่ 22 ตุลาคม พร้อมบอกเองว่า release notes ลงวันที่ 21 ตุลาคม แหล่งข้อมูลไม่ได้ให้เวลาพร้อมเขตเวลา จึงไม่ควรเดาว่าเกิดจากการแปลงเป็นเวลาไทย (GitHub, Astral Changelog, Jason Vs The Noise)

เลข certifi ต่างกันในคำอธิบายประกาศ กระทู้ Python.org ระบุว่าประกาศคำแนะนำเดิมกล่าวถึง 2026.10.18 แต่แนะนำ 2026.10.19 เพื่อรักษาความเข้ากันได้กับใบรับรองราก emSign ที่ไม่ได้รับผลกระทบ ดังนั้นเลขเป้าหมายที่ควรยึดจากข้อมูลชุดนี้คือ 2026.10.19 ตามคำแนะนำดังกล่าว (Python.org)

Python 3.9 และ 3.10 ยังไม่ถือว่าครอบคลุม Astral ระบุว่า CPython ต้นทางสองสายนี้ยังบรรจุ pip ที่มีชุดใบรับรองเชื่อถือรากที่ได้รับผลกระทบ ขณะที่ผู้ร่วมกระทู้ Python.org อธิบายว่า pip ต่ำกว่า 26.2.2 ยังคงเชื่อถือใบรับรองที่มีปัญหาผ่าน certifi ที่ติดมา จึงแก้แค่ความเชื่อถือของระบบปฏิบัติการไม่ได้ (GitHub, Python.org) ไม่ควรอ่านว่าอัปเดต uv แล้วทำให้ pip ที่แถมมากับสองสายนี้ถูกแก้ไปด้วย

การใช้ใบรับรองจากระบบหรือชุดที่องค์กรกำหนดต้องตรวจแยก Jason Vs The Noise ระบุว่ายังไม่ได้ยืนยันว่าเส้นทางการตั้งค่าบางแบบใช้ตัวตรวจสอบที่แก้แล้วหรือไม่ และการอัปเดตนี้ไม่ได้แก้ไฟล์ใบรับรองภายนอกหรือชุดความเชื่อถือของระบบให้เอง จึงยังรับรองครอบคลุมทุกการตั้งค่าไม่ได้ (Jason Vs The Noise)

แล้วเราควรทำอะไร

นักพัฒนารายบุคคลและนักศึกษา

1. ตรวจรุ่นที่ใช้อยู่ด้วย uv --version แล้วอัปเดต uv เป็น 0.13.5 ถ้าติดตั้งแบบที่อัปเดตตัวเองได้ ให้ใช้ uv self update แต่ถ้าติดตั้งผ่านเครื่องมือจัดการแพ็กเกจ ให้ปรับผ่านเครื่องมือนั้นตามคำแนะนำของรายงาน (Jason Vs The Noise)
2. รัน uv python upgrade เพื่อรับชุด Python ที่แก้แล้ว จากนั้นตรวจรายการด้วย uv python list โดยเฉพาะสาย 3.11 และ 3.12 ที่เลขรุ่นอาจไม่ขยับตามที่คาด (GitHub, Jason Vs The Noise)
3. ไล่จัดการพื้นที่แยกของแต่ละโปรเจกต์ อัปเดต pip เป็นอย่างน้อย 26.2.2 และ certifi ให้ได้รุ่นที่แนะนำ หรือสร้างพื้นที่ใหม่จาก Python ที่อัปเดตแล้ว สำหรับการให้ pip เก่าติดตั้งตัวใหม่ ให้ใช้วิธีที่ระบุไฟล์และค่า SHA256 จากประกาศ Python.org ซึ่งเป็นค่าตรวจสอบว่าไฟล์ตรงกับที่กำหนด (Python.org)
4. หากเลือกสร้างพื้นที่ใหม่ ให้ยืนยันว่าใช้ชุด Python ที่อัปเดตจริง เพราะ ensurepip ในชุดใหม่นั้นมี pip 26.2.2 แล้ว ส่วนพื้นที่เดิมที่ตรึงรุ่นเก่าไม่ได้สลับตามเอง (GitHub)

ทีมดูแล CI และ Docker image

1. CI คืองานอัตโนมัติที่ใช้สร้างและตรวจโปรแกรม ควรอัปเดตทั้ง uv และ Python บนเครื่องที่ทำงานเหล่านั้น แล้วตรวจว่าขั้นตอนใดเรียก pip โดยตรง เพราะการเรียก pip อาจไม่ได้ผ่านส่วนตรวจสอบการเชื่อมต่อของ uv (Jason Vs The Noise)
2. สร้าง container image ใหม่โดยปิดการใช้ชั้นข้อมูลเดิมตามคำแนะนำ Python.org เพื่อรับใบรับรองระบบล่าสุด พร้อมจัดการ pip และ certifi ภายในชุดที่นำไปใช้งานด้วย (Python.org)
3. บันทึกผลตรวจรุ่น uv, Python และ pip ของชุดที่นำไปรันจริงไว้ในงานตรวจรับ ผมแนะนำให้ใช้ข้อมูลเหล่านี้เป็นหลักฐานประกอบ แทนการอ้างเพียงว่ามีไฟล์ล็อกใหม่ เพราะไฟล์ล็อกไม่ได้อัปเดตตัว uv หรือพื้นที่แยกเดิมให้ (Jason Vs The Noise)

ทีมที่ยังใช้ Python 3.9 หรือ 3.10

1. แยกรายการงานสองสายนี้ออกมาตรวจโดยเฉพาะ อย่าสรุปว่าชุดแก้สำหรับ managed CPython 3.11 ขึ้นไปครอบคลุมแล้ว เพราะ Astral ยืนยันว่า pip ที่ต้นทางแถมมากับ 3.9 และ 3.10 ยังเชื่อถือรากที่มีปัญหา (GitHub)
2. วางแผนย้ายออกจากสองสายนี้ตามคำแนะนำ Astral และทบทวนงานที่พึ่ง Docker image ดังกล่าว เพราะจะไม่มีการเผยแพร่ image ของ uv สำหรับสายที่ระบุแล้ว (Astral Changelog)
3. ระหว่างจัดแผนย้าย ให้ผู้ดูแลตรวจ pip ทุกสภาพแวดล้อมและข้อจำกัดความเข้ากันได้ของงานตนเอง ประกาศ Python.org ย้ำว่าการอัปเดต pip เป็นวิธีแก้ที่เชื่อถือได้สำหรับปัญหาชุดใบรับรองของ pip จึงไม่ควรใช้การอัปเดตระบบปฏิบัติการเป็นหลักฐานแทน (Python.org)

การเปลี่ยนแปลงอื่นที่ควรรู้

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

อีกจุดคือการปฏิเสธค่าระบุแคชการสร้างที่ไม่ถูกต้อง แคชคือข้อมูลที่เก็บไว้เพื่อนำกลับมาใช้ แทนพฤติกรรมเดิมที่เงียบแล้วกลับไปใช้ค่าเริ่มต้น รวมถึงการลดขนาดตัวโปรแกรม uv ด้วย รายการนี้เป็นงานแก้ความถูกต้องและประสิทธิภาพคนละส่วนกับการแก้ใบรับรอง (Astral Changelog) สำหรับทีมที่เวลาแน่น ผมแนะนำให้ตรวจเรื่องความปลอดภัยก่อน แล้วจึงประเมินประโยชน์ด้านความเร็วจากงานของตัวเอง

ผมมองว่า…

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

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

ปิดท้าย: สิ่งที่ต้องจับตา

สิ่งที่ควรติดตามต่อคือข้อมูลเพิ่มเติมในกระทู้ Python.org ซึ่งระบุว่าจะปรับปรุงเมื่อมีรายละเอียดใหม่ และการตรวจเส้นทางใบรับรองที่องค์กรกำหนดเองซึ่งรายงาน Jason Vs The Noise ยังไม่ยืนยันว่าครอบคลุมทุกกรณี (Python.org, Jason Vs The Noise)

ก่อนปิดงานรอบนี้ ควรกลับไปยืนยันว่าพื้นที่เดิมได้รับการอัปเดต pip หรือสร้างใหม่แล้ว และชุดที่ใช้ในงานอัตโนมัติเป็นชุดที่ตรวจจริง เพราะ Astral ระบุชัดว่าพื้นที่ที่ตรึง Python รุ่นแก้ไขเก่าไม่ได้เปลี่ยนตามเอง (GitHub) ความเรียบร้อยของงานนี้จึงวัดจากสิ่งที่ใช้อยู่ มากกว่าสิ่งที่เพิ่งดาวน์โหลดมา

Recap

• ตรวจและอัปเดต uv ให้เป็น 0.13.5
• รัน uv python upgrade เพื่อรับชุด Python ที่แก้แล้ว
• ตรวจชุดที่ติดตั้งจริง โดยเฉพาะ Python 3.11 และ 3.12
• อัปเดต pip และ certifi ในแต่ละพื้นที่เดิม หรือสร้างพื้นที่ใหม่
• ใช้แนวทางตรวจสอบไฟล์จากประกาศ Python.org เมื่อต้องอัปเดตผ่าน pip เก่า
• สร้าง container image ใหม่ตามแนวทางปิดการใช้ชั้นข้อมูลเก่า
• แยกตรวจงาน Python 3.9 และ 3.10 พร้อมวางแผนย้าย
• ตรวจงานที่เรียก pip โดยตรงและการใช้ชุดใบรับรองที่องค์กรกำหนด