uv 0.13.3 มาแล้ว หลัง 0.13.2 แก้ข้อมูลล็อกอินหลุดติดข้อความระบบ

uv 0.13.2 รวมการแก้ไข 5 รายการเพื่อป้องกันข้อมูลรับรองใน URL หลุดผ่านข้อความวิเคราะห์ปัญหาหรือข้อมูลประกอบที่บันทึกไว้ ตามบันทึกรุ่นที่ระบุรายการแก้ไขไว้ด้วยกันครับ (GitHub: uv 0.13.2) ประเด็นที่คนทำงานควรสนใจคือชื่อผู้ใช้ รหัสผ่าน หรือโทเคน ซึ่งเป็นข้อความลับที่ใช้ยืนยันสิทธิ์ อาจไม่ควรไปอยู่ในสิ่งที่ทีมเปิดอ่านหรือส่งต่อกันระหว่างแก้งาน ผมจึงแนะนำให้มองการอัปเดตครั้งนี้ควบคู่กับการตรวจข้อมูลเก่าที่ทีมเคยเก็บไว้

สำหรับคนที่ไม่ได้เขียนโปรแกรมทุกวัน uv คือเครื่องมือจัดการแพ็กเกจและโครงการ Python โดยแพ็กเกจก็คือชุดซอฟต์แวร์ที่นำมาใช้ประกอบงาน ส่วน PyPI ซึ่งเป็นเว็บไซต์เผยแพร่แพ็กเกจ ระบุรุ่นล่าสุดในข้อมูลชุดนี้เป็น 0.13.3 แล้ว (PyPI) รุ่นดังกล่าวออกตามบันทึกรุ่นวันที่ 20 ตุลาคม 2026 เพื่อแก้การส่งออกรายการแพ็กเกจที่ช้ารุนแรงในบางโครงการ จึงมีทั้งเรื่องข้อมูลลับและเรื่องเวลาทำงานให้ทีมไอทีตรวจต่อในคราวเดียว (GitHub: uv 0.13.3)

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

• ข้อมูลลับ: uv 0.13.2 แก้การเผยข้อมูลรับรองที่ฝังอยู่ใน URL หรือที่อยู่เว็บ ผ่านข้อความวิเคราะห์ปัญหาและ metadata ซึ่งหมายถึงข้อมูลประกอบที่ระบบเก็บไว้ บันทึกรุ่นไม่ได้ระบุว่ามีผู้เสียหายแล้วกี่ราย (GitHub: uv 0.13.2)
• กฎพักแพ็กเกจใหม่: รุ่นนี้แก้ให้เคารพ --exclude-newer แม้มี wheel รุ่นใหม่กว่าของชุดซอร์สที่เลือกอยู่ในแคชแล้ว โดย wheel คือแพ็กเกจที่เตรียมไว้สำหรับติดตั้ง ส่วนแคชคือข้อมูลที่เก็บไว้ใช้ซ้ำ (GitHub: uv 0.13.2)
• ความต่อเนื่องของงาน: เพิ่มการลองขอข้อมูลใหม่เมื่อการรับข้อมูลแพ็กเกจสะดุด และแก้บางกรณีที่โปรแกรมหยุดผิดปกติให้รายงานข้อผิดพลาดแทน (GitHub: uv changelog)
• รุ่นที่ตามมา: uv 0.13.3 แก้ uv export ซึ่งใช้ส่งออกรายการแพ็กเกจ ให้หลีกเลี่ยงความช้ารุนแรงเมื่อความสัมพันธ์ระหว่างแพ็กเกจมี extras หรือกลุ่มความสามารถเสริมที่เลือกติดตั้งได้ (GitHub: uv 0.13.3)

บันทึกรุ่นระบุ 0.13.2 ออกวันที่ 19 ตุลาคม และ 0.13.3 ออกวันที่ 20 ตุลาคม 2026 ส่วนเวลาที่อัปโหลดขึ้น PyPI เมื่อแปลงเป็นเวลาไทยแล้วคือวันที่ 20 ตุลาคม 2026 เวลา 03:59 น. และ 08:12 น. ตามลำดับ จึงควรแยกวันเผยแพร่ที่ผู้พัฒนาระบุออกจากเวลาอัปโหลดที่เราเห็นในไทยครับ (GitHub: uv changelog, PyPI)

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

ถ้าคุณเป็นพนักงานออฟฟิศ เจ้าของธุรกิจ ผู้ปกครอง หรือนักศึกษาที่ไม่ได้ใช้ Python เอง เรื่องนี้ไม่จำเป็นต้องเริ่มจากการติดตั้งอะไรเพิ่ม ผมแนะนำให้ใช้เป็นคำถามคุยกับคนดูแลระบบว่า งานที่ใช้ uv มีการใส่ข้อมูลลับลงในที่อยู่แหล่งดาวน์โหลดหรือไม่ และข้อความที่ระบบบันทึกระหว่างทำงานเปิดให้ใครอ่านได้บ้าง เหตุผลที่ต้องถามสองเรื่องนี้มาจากขอบเขตการแก้ไข ซึ่งระบุทั้งข้อมูลรับรองใน URL และช่องทางข้อความวิเคราะห์ปัญหากับข้อมูลที่บันทึกไว้ (GitHub: uv 0.13.2)

สำหรับทีมพัฒนา จุดที่ควรตรวจคือ CI หรือระบบที่ทดสอบและเตรียมซอฟต์แวร์ให้โดยอัตโนมัติ หากบันทึกการทำงานของทีมพิมพ์ที่อยู่คลังแพ็กเกจส่วนตัวพร้อมโทเคน ผู้ที่อ่านบันทึกนั้นได้ก็อาจเห็นข้อความลับไปด้วย นี่เป็นกรณีความเสี่ยงที่ผมยกขึ้นให้ตรวจตามลักษณะปัญหาที่ประกาศแก้ ไม่ใช่หลักฐานว่าระบบของผู้อ่านเคยรั่วแล้ว (GitHub: uv 0.13.2)

ธุรกิจในไทยที่ใช้ uv จึงควรเช็กวิธีตั้งค่าจริงของตัวเอง แต่ยังไม่มีข้อมูลในแหล่งข่าวชุดนี้ว่าองค์กรไทยแห่งใดได้รับผลกระทบ สำหรับคนที่รับผิดชอบงบหรือกำหนดส่งงาน ผมแนะนำให้ขอผลตรวจที่ตอบได้ชัดว่าใช้รุ่นอะไร พบข้อมูลลับในบันทึกเก่าหรือไม่ และมีงานส่งออกรายการแพ็กเกจที่ต้องทดสอบหลังอัปเดตหรือเปล่า เพราะบันทึกรุ่นครอบคลุมทั้งการปกป้องข้อมูลและการแก้ความช้าของงานดังกล่าว (GitHub: uv 0.13.2, GitHub: uv 0.13.3)

ทำงานยังไง

ประเด็นแรกอยู่ที่ข้อมูลรับรองในที่อยู่แหล่งแพ็กเกจ เมื่อข้อความที่ใช้ยืนยันสิทธิ์เดินทางไปพร้อม URL สิ่งที่ทีมควรตรวจต่อคือระบบนำ URL นั้นไปแสดงหรือเก็บที่ใดบ้าง บันทึก uv 0.13.2 ระบุการป้องกันข้อมูลรับรองหลุดผ่าน diagnostics หรือข้อความช่วยวิเคราะห์ปัญหา และ persisted metadata หรือข้อมูลประกอบที่ถูกบันทึกไว้ จึงไม่ควรตีความว่าขอบเขตการตรวจมีแค่หน้าจอที่คนกำลังเปิดดู (GitHub: uv 0.13.2)

เปรียบเหมือน ใบเสร็จที่พิมพ์รหัส ATM ติดมาด้วย แล้วเอาไปแปะบอร์ดออฟฟิศ ใบเสร็จอาจเป็นเอกสารที่หลายคนมีเหตุผลจะอ่าน แต่รหัสลับไม่จำเป็นต้องตามไปด้วยครับ การแก้ของ uv จึงเกี่ยวกับการไม่ปล่อยข้อมูลยืนยันสิทธิ์ออกไปพร้อมข้อมูลที่ใช้ตรวจงาน ตามขอบเขตที่ผู้พัฒนาระบุไว้ (GitHub: uv 0.13.2)

อีกจุดคือ signed URL ซึ่งเป็นลิงก์ที่มีข้อมูลใช้ยืนยันสิทธิ์ประกอบอยู่ รุ่นนี้แยกรายการแคชของลิงก์ที่ใช้กับตัวเลือกค้นหาแพ็กเกจเพิ่มเติม --find-links เมื่อส่วนข้อมูลลับที่แนบมากับลิงก์ต่างกัน แม้ส่วนอื่นของลิงก์จะเหมือนกันก็ตาม สิ่งที่ยืนยันได้คือมีการแก้การแยกข้อมูลในแคช ส่วนผลกระทบจริงต่อผู้ใช้แต่ละรายไม่ได้อธิบายไว้ในบันทึกรุ่น (GitHub: uv 0.13.2)

ด้านการเผยแพร่แพ็กเกจ uv publish จะใช้ข้อมูลรับรองที่ตั้งค่าไว้ก่อนถามผู้ใช้ และหลีกเลี่ยงการถามเมื่อไม่มีการอัปโหลดเกิดขึ้น สำหรับทีมที่มีขั้นตอนอัตโนมัติ ผมแนะนำให้ตรวจว่าค่าที่ตั้งไว้ถูกใช้งานตามที่คาดหลังอัปเดต โดยไม่ต้องนำข้อความลับมาใส่ในรายงานผลทดสอบ (GitHub: uv 0.13.2)

ส่วน --exclude-newer ให้อ่านเป็นภาษาคนว่า “ทำเหมือนแพ็กเกจที่ใหม่กว่าวันที่กำหนดไม่มีอยู่” จึงใช้ประกอบนโยบายพักแพ็กเกจใหม่ก่อนนำเข้ามาใช้งานได้ จุดแก้ครั้งนี้เจาะกรณีที่มี wheel ใหม่กว่าของ source distribution หรือชุดซอร์สต้นฉบับที่ระบบเลือก อยู่ในแคชแล้ว บันทึกรุ่นระบุให้เคารพข้อจำกัดวันที่ในกรณีนั้นด้วย ไม่ได้ประกาศว่าตัวเลือกนี้ตรวจหาแพ็กเกจอันตรายได้ (GitHub: uv 0.13.2)

จุดหักมุม: แพ็กเกจที่เก็บไว้แล้วก็ต้องอยู่ใต้กฎวันที่

เรื่องที่ผมว่าน่าสนใจคือกฎเลือกแพ็กเกจต้องทำงานสอดคล้องกันแม้มีข้อมูลเก็บไว้ก่อนแล้ว การแก้ --exclude-newer ใน 0.13.2 ระบุชัดถึง wheel ที่อยู่ในแคช จึงเป็นรายละเอียดที่ทีมซึ่งตั้งระยะพักแพ็กเกจควรตรวจ ไม่ควรดูเพียงว่ามีการกำหนดวันที่ไว้ในขั้นตอนทำงานหรือยัง (GitHub: uv 0.13.2)

ข้อเสนอของผมคือคงนโยบายพักแพ็กเกจที่ทีมเลือกใช้อยู่ และทดสอบให้ครอบคลุมกรณีมีข้อมูลในแคชด้วย ผลทดสอบที่มีประโยชน์ควรบอกได้ว่าระบบยังเลือกแพ็กเกจตามข้อจำกัดวันที่ โดยอ้างอิงกรณีที่ประกาศแก้ ไม่ใช่ขยายความไปว่าการรอครบกำหนดรับประกันความปลอดภัย เพราะบันทึกรุ่นให้หลักฐานเฉพาะการเคารพข้อจำกัดนี้ (GitHub: uv 0.13.2)

อีกด้านหนึ่ง 0.13.3 มีรายการแก้หลักเพียงเรื่องความช้าของการส่งออกในโครงการที่มี extras จำนวนรายการจึงไม่ใช่เหตุผลให้มองข้าม สำหรับทีมที่มีงานลักษณะนี้ ผมแนะนำให้รวมการทดสอบส่งออกไว้ในรอบอัปเดตด้วย แม้บันทึกรุ่นจะไม่ได้ให้ตัวเลขว่าประหยัดเวลาได้เท่าไร (GitHub: uv 0.13.3)

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

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

ด้านเวลารอ รุ่น 0.13.2 ลดงานประมวลผลที่เพิ่มขึ้นมากเมื่อจัดการ dependency markers หรือเงื่อนไขที่กำหนดว่าแพ็กเกจต้องใช้ภายใต้สภาพแวดล้อมใด พร้อมลดเวลาและหน่วยความจำที่ใช้เก็บเงื่อนไขซับซ้อน และลดหน่วยความจำของ resolver ซึ่งเป็นส่วนเลือกชุดแพ็กเกจที่ใช้ร่วมกันได้ ในโครงการที่มีความสัมพันธ์จำนวนมาก (GitHub: uv changelog)

เรื่องนี้มีน้ำหนักกับทีมที่ต้องรอผลเตรียมโครงการหรือส่งออกข้อมูลเป็นประจำ แต่ยังไม่มีผลวัดความเร็วหรือค่าใช้จ่ายที่ลดลงในแหล่งข้อมูลชุดนี้ ผมจึงแนะนำให้เปรียบเทียบงานจริงของทีมก่อนและหลังอัปเดต แทนการนำคำว่า “ลดเวลา” ไปคูณเป็นเงินทันที โดยเฉพาะเมื่อ 0.13.3 ยังตามมาแก้ความช้ารุนแรงเฉพาะงานส่งออกที่มี extras อีกครั้ง (GitHub: uv changelog, GitHub: uv 0.13.3)

ความต่อเนื่องยังเป็นอีกส่วนที่ควรตรวจ รุ่น 0.13.2 เพิ่มการลองใหม่เมื่อคำขอแบบ GET และ HEAD ซึ่งใช้รับข้อมูลหรือตรวจข้อมูลเบื้องต้นจากแหล่งแพ็กเกจ หลุดระหว่างทาง และเปลี่ยนบางกรณีที่เกิด panic หรือการหยุดผิดปกติภายในโปรแกรม ให้เป็นข้อผิดพลาดที่รายงานได้ รวมถึงการระบุรุ่น Python ไม่ถูกต้องและชื่อไฟล์ผลลัพธ์ไม่ถูกต้อง (GitHub: uv 0.13.2)

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

วันปล่อยกับเวลาอัปโหลดเป็นคนละข้อมูล: บันทึก GitHub ระบุวันปล่อย 0.13.2 เป็น 19 ตุลาคม 2026 ส่วน PyPI ระบุเวลาอัปโหลดเป็น 20 ตุลาคม 2026 เวลา 03:59 น. เมื่อแปลงเป็นเวลาไทย สำหรับ 0.13.3 บันทึกรุ่นระบุวันที่ 20 ตุลาคม และ PyPI ตรงกับเวลาไทย 08:12 น. ในวันเดียวกัน ความต่างนี้จึงไม่ควรถูกสรุปเองว่าแหล่งใดลงวันผิด (GitHub: uv 0.13.2, GitHub: uv 0.13.3, PyPI)

รายการคุณสมบัติทดลองมีรายละเอียดต่างกัน: changelog มีรายการทดลองเกี่ยวกับการอ่านข้อมูลรูปแบบแพ็กเกจตาม PEP 825 ซึ่งเป็นข้อกำหนดทางเทคนิคหนึ่ง ขณะที่ข้อความหน้ารุ่น 0.13.2 ที่ให้มามีหัวข้อคุณสมบัติทดลองแต่ไม่มีรายการนี้ ผมจึงไม่ใช้ส่วนดังกล่าวเป็นเหตุผลหลักในการแนะนำอัปเดต และไม่สรุปต่อว่าทีมใดเปิดใช้แล้ว (GitHub: uv changelog, GitHub: uv 0.13.2)

ขอบเขตเหตุข้อมูลลับยังไม่ครบ: บันทึกรุ่นไม่ได้ให้ช่วงรุ่นที่ได้รับผลกระทบทั้งหมด ไม่ได้ระบุว่ามีการนำข้อมูลที่หลุดไปใช้จริงหรือไม่ และไม่ได้บอกจำนวนบัญชีหรือองค์กรในไทย การมีรายการแก้จึงเป็นเหตุผลให้ตรวจระบบของเรา แต่ยังไม่เพียงพอให้ประกาศว่าทุกคนถูกขโมยข้อมูลแล้ว (GitHub: uv 0.13.2)

ความเร็วไม่มีตัวเลขรับประกัน: ทั้งรายการลดเวลาและหน่วยความจำใน 0.13.2 กับการแก้ความช้าใน 0.13.3 ไม่ได้แนบผลทดสอบความเร็วในข้อความที่ให้มา เราจึงยังบอกไม่ได้ว่าเครื่องของคุณจะเร็วขึ้นเท่าไร หรือประหยัดเวลาทำงานต่อวันกี่นาที (GitHub: uv changelog, GitHub: uv 0.13.3)

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

คนใช้ทั่วไป เจ้าของธุรกิจ และคนดูแลงาน

1. ขอให้ผู้ดูแลตรวจว่างานของทีมใช้ uv หรือไม่ หากใช้ ให้แจ้งรุ่นที่ใช้อยู่และแผนอัปเดต โดยข้อมูล PyPI ที่ให้มาระบุรุ่นล่าสุดเป็น 0.13.3 (PyPI)
2. ขอผลตรวจเรื่องข้อมูลลับในบันทึกเก่าเป็นสถานะ เช่น พบหรือไม่พบและจัดการแล้วหรือยัง ผมแนะนำว่าไม่ควรขอให้ทีมคัดลอกโทเคนจริงลงเอกสารรายงาน เพราะจุดที่ประกาศแก้เกี่ยวข้องกับข้อมูลรับรองที่ตามไปอยู่ในข้อความและข้อมูลที่เก็บไว้ (GitHub: uv 0.13.2)
3. ให้ทีมที่ใช้งานส่งออกรายการแพ็กเกจอยู่แล้วรายงานผลทดสอบหลังอัปเดตด้วย โดยเฉพาะโครงการที่เลือกความสามารถเสริม เพราะนี่คือกรณีที่ 0.13.3 ระบุว่าแก้ความช้ารุนแรง (GitHub: uv 0.13.3)

นักพัฒนาและผู้ดูแลระบบอัตโนมัติ

1. อัปเดต uv ผ่านตัวจัดการแพ็กเกจที่ทีมใช้ติดตั้งอยู่ หรือเลือกวิธีติดตั้งที่ทีมตรวจทานจากหน้ารุ่น 0.13.3 แล้ว จากนั้นตรวจเครื่องพัฒนาและระบบอัตโนมัติที่ใช้ทำงานจริงให้ครบตามขอบเขตของทีม หน้ารุ่นมีวิธีติดตั้งไบนารีสำเร็จรูปไว้ให้ตรวจสอบ (GitHub: uv 0.13.3)
2. ตรวจบันทึก CI เก่าและข้อมูลประกอบที่ทีมเก็บไว้ เพื่อหาข้อมูลรับรองที่อาจติดไปกับ URL หากพบ ผมแนะนำให้เปลี่ยนข้อมูลลับนั้นและตรวจสิทธิ์ผู้อ่านบันทึกด้วย การอัปเดตควรเดินคู่กับงานตรวจย้อนหลัง เพราะรายการแก้ระบุช่องทางข้อมูลที่บันทึกไว้ด้วย (GitHub: uv 0.13.2)
3. ทบทวนการตั้งค่าข้อมูลรับรองให้เหมาะกับขั้นตอนเผยแพร่ ผมแนะนำให้ใช้การตั้งค่าที่ทีมดูแลแยกไว้แทนการฝังโทเคนลงใน URL ที่อาจถูกแสดง โดยทดสอบพฤติกรรมของ uv publish ซึ่งรุ่นนี้ระบุว่าใช้ข้อมูลรับรองที่ตั้งไว้ก่อนถามผู้ใช้ (GitHub: uv 0.13.2)
4. คงกฎ --exclude-newer หากทีมใช้นโยบายพักแพ็กเกจ และตรวจกรณีมี wheel ใหม่กว่าอยู่ในแคชด้วย อย่าเพิ่มข้อสรุปว่ากฎวันที่ตรวจความปลอดภัยให้แล้ว เพราะสิ่งที่ประกาศแก้คือการเคารพข้อจำกัดวันที่ในกรณีดังกล่าว (GitHub: uv 0.13.2)
5. หากใช้ pylock.toml ซึ่งเป็นไฟล์บันทึกชุดแพ็กเกจสำหรับติดตั้ง ให้ทดสอบการติดตั้งหรือปรับสภาพแวดล้อมให้ตรงไฟล์นั้น รุ่นนี้แก้ให้เคารพข้อจำกัดสภาพแวดล้อมตาม PEP 751 และเพิ่มการส่งออกข้อจำกัดที่รองรับไปกับไฟล์ด้วย (GitHub: uv 0.13.2)

รายละเอียดเสริมที่ทีม Python ควรเช็ก

สำหรับคนใช้ PyPy ซึ่งเป็นตัวรันภาษา Python อีกแบบหนึ่ง รุ่น 0.13.2 เพิ่ม PyPy 3.11.17 และ 3.12.15 ไว้ในรายการรองรับ ผมแนะนำให้ทีมที่ต้องใช้รุ่นเหล่านี้รวมการตรวจตัวรันไว้ในรอบทดสอบ ส่วนทีมที่ไม่ได้ใช้ก็ไม่จำเป็นต้องเพิ่มงานเปลี่ยนตัวรันเพียงเพราะมีรายการนี้ (GitHub: uv 0.13.2)

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

ผมมองว่า…

ผมมองว่า ในเชิงความเห็น การอัปเดตครั้งนี้ ไม่ใช่แค่เรื่องตัวเลขรุ่น แต่คือการดูแลข้อมูลลับตลอดขั้นตอนทำงาน เหตุผลที่ผมให้น้ำหนักแบบนี้คือรายการแก้กล่าวถึงทั้งข้อความวิเคราะห์ปัญหา ข้อมูลที่บันทึกไว้ และการใช้ข้อมูลรับรองที่ตั้งค่าไว้ระหว่างเผยแพร่แพ็กเกจ ซึ่งเป็นคนละจุดในงานประจำของทีม (GitHub: uv 0.13.2)

ความเห็นของผมคือผลลัพธ์ที่ดีควรมีทั้งการอัปเดตและคำตอบจากการตรวจระบบจริง ทีมควรรู้ว่าข้อมูลลับเคยถูกบันทึกหรือไม่ กฎพักแพ็กเกจยังทำงานตามที่ตั้งใจหรือเปล่า และงานส่งออกยังใช้เวลาสมเหตุสมผลหรือไม่ ข้อเสนอนี้อิงเรื่องที่รุ่น 0.13.2 และ 0.13.3 ประกาศแก้ แต่ระดับความเร่งด่วนของแต่ละทีมต้องตัดสินจากวิธีใช้งานและผลตรวจของตัวเองครับ (GitHub: uv 0.13.2, GitHub: uv 0.13.3)

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

หลังอัปเดต ผมแนะนำให้จับตาผลในสามจุดที่ตรวจได้จริง ได้แก่ ข้อความจากระบบไม่มีข้อมูลรับรองที่ไม่ควรแสดง การเลือกแพ็กเกจยังเคารพกฎวันที่แม้มีแคช และการส่งออกโครงการที่มี extras ไม่เกิดความช้ารุนแรงแบบที่ประกาศแก้ ทั้งสามข้อนี้เป็นกรอบตรวจงานตามบันทึกรุ่น ไม่ใช่การยืนยันล่วงหน้าว่าทุกระบบจะให้ผลเหมือนกัน (GitHub: uv 0.13.2, GitHub: uv 0.13.3)

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

Recap

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