ป้ายนี้บันทึกอะไรจริง ๆ
ป้าย verified commit เป็นผลจากการตรวจลายเซ็น ไม่ใช่หนังสือรับรองอุปนิสัย เมื่อคุณเห็นคำว่า “Verified” ข้าง commit บน GitHub แพลตฟอร์มกำลังบอกคุณเพียงเรื่องแคบ ๆ เรื่องเดียว คือมันตรวจลายเซ็นเชิงรหัส (cryptographic signature) ที่แนบมากับ commit นั้นแล้ว และการตรวจผ่าน
GitHub จะทำเครื่องหมาย commit ที่ลงนามแล้วว่า Verified เมื่อตรวจสอบลายเซ็นสำเร็จ แหล่งที่มา
ป้ายนี้ผูกกับ commit ไม่ได้ผูกกับบุคคล และไม่ใช่ตัวชี้วัดความปลอดภัยแบบเรียลไทม์ของบัญชีที่คุณกำลังดูอยู่ในวันนี้ ผลการตรวจสอบเป็นบันทึกเชิงประวัติศาสตร์ของการตรวจที่เกิดขึ้น ณ จุดเวลาหนึ่ง
เมื่อบันทึกการตรวจสอบแล้ว บันทึกนั้นอาจคงอยู่ต่อไปได้แม้คีย์ที่ใช้ลงนามจะถูกเพิกถอนหรือหมดอายุ แหล่งที่มา
การคงอยู่เช่นนี้สำคัญสำหรับผู้ตรวจสอบ ป้ายอาจยังปรากฏบน commit เก่าแม้คีย์ที่สร้างลายเซ็นนั้นจะถูกเพิกถอนหรือหมดอายุแล้ว คีย์ที่ถูกเพิกถอนไม่ได้ลบป้ายย้อนหลัง และคีย์ที่หมดอายุไม่ได้ทำให้ commit เก่ากลายเป็น unverified ดังนั้นป้ายบอกคุณว่าลายเซ็นผ่านการตรวจตอนที่บันทึกไว้ ไม่ได้บอกว่าคีย์ยังได้รับความเชื่อถืออยู่ บัญชียังปลอดภัยอยู่ หรือผู้ถือบัญชีปัจจุบันเป็นคนเดียวกับผู้ลงนาม
ขั้นที่ 1: แยกคำถามสามข้อออกจากกัน
เมื่อมีคนยก commit ที่ verified ขึ้นมาเป็นหลักฐานของข้อกล่าวอ้างเกี่ยวกับนักพัฒนา มักเป็นการผสมคำถามที่แตกต่างกันสามข้อเข้าด้วยกัน แยกออกจากกันก่อนประเมินอะไร
| คำถาม | ป้าย verified บอกได้อะไร | บอกอะไรไม่ได้ด้วยตัวเอง |
|---|---|---|
| commit นี้ถูกลงนามและตรวจสอบแล้วหรือไม่ | GitHub บันทึกว่าการตรวจลายเซ็นของ commit นั้นสำเร็จ | ใครเป็นคนเขียนโค้ด หรือโค้ดดีหรือไม่ |
| ใครควบคุมบัญชีอยู่ตอนนี้ | ไม่บอกโดยตรง ป้ายผูกกับ commit ไม่ใช่กับการควบคุมการเข้าสู่ระบบปัจจุบัน | คนเดิมยังเป็นเจ้าของบัญชีหรือไม่ หรือบัญชีเปลี่ยนมือไปแล้วหรือไม่ |
| คนนี้เป็นคนที่เขาอ้างว่าเป็น หรือทำงานที่เขาอ้างหรือไม่ | ไม่บอกโดยตรง | ตัวตน การจ้างงาน หรืออำนาจในการพูดแทนองค์กร |
ป้าย verified ตอบได้เพียงแถวแรก แถวที่สองและสามต้องใช้หลักฐานแยกต่างหาก นี่คือวินัยเดียวกับที่อธิบายไว้ในคู่มือของเราเรื่อง การค้นหาโปรไฟล์สาธารณะบอกอะไรได้และบอกอะไรไม่ได้เกี่ยวกับบุคคล: สิ่งที่เปิดเผยต่อสาธารณะเป็นเบาะแส ไม่ใช่ข้อสรุป
ขั้นที่ 2: อ่านตัว commit ไม่ใช่แค่อ่านป้าย
ป้ายคือทางลัด และทางลัดมักซ่อนบริบท เปิดตัว commit เองแล้วดูสิ่งที่อยู่รอบผลการตรวจสอบ
- ช่อง author และช่อง committer ของ commit ทั้งสองเป็นรายการเมทาดาทา (metadata) ไม่ใช่หลักฐานว่าใครพิมพ์โค้ด ในหลายกระบวนการทำงานสามารถตั้งเป็นอะไรก็ได้
- คีย์ที่ใช้ลงนามซึ่งแสดงอยู่ GitHub เชื่อมผลการตรวจสอบกับคีย์หนึ่ง ๆ สังเกตว่าคีย์นั้นถูกนำเสนอว่าเป็นของบัญชี องค์กร หรือบอต
- รีโพซิทอรีและแบรนช์ commit ที่ verified ใน fork ส่วนตัวมีน้ำหนักเชิงองค์กรน้อยกว่า commit ที่ถูก merge เข้าโปรเจกต์ที่มีการดูแล แต่ทั้งสองแบบไม่ได้พิสูจน์การจ้างงาน
- วันที่ commit ที่ verified แล้วและเก่าแก่เป็นข้อมูลเชิงประวัติศาสตร์จุดหนึ่ง ไม่ได้บอกอะไรเกี่ยวกับสถานะความปลอดภัยปัจจุบันของบัญชี
ไม่มีฟิลด์ใดเหล่านี้ ไม่ว่าอย่างเดียวหรือรวมกัน ยืนยันได้ว่าผู้ถือบัญชีคือบุคคลที่ระบุชื่อในประวัติย่อ หรือว่าบุคคลนั้นทำงานที่โปรไฟล์บอกว่าทำงาน
ขั้นที่ 3: ตรวจการควบคุมบัญชีปัจจุบันแยกต่างหาก
commit ที่ verified เป็นบันทึกเกี่ยวกับ commit การควบคุมบัญชีเป็นคำถามคนละข้อ และหน้าเว็บสาธารณะแทบไม่ตอบคำถามนี้โดยตรง สิ่งที่ทำได้คือมองหาความสอดคล้องและความต่อเนื่อง
- เปรียบเทียบประวัติสาธารณะของบัญชีเมื่อเวลาผ่านไป ประวัติการมีส่วนร่วมที่ยาวนานและสอดคล้องกันเป็นเบาะแส ไม่ใช่หลักฐาน
- มองหามือถือ (handle) หรือชื่อที่แสดงเดียวกันบนแพลตฟอร์มอื่น มือถือที่ตรงกันเป็นเบาะแส ไม่ใช่หลักฐานว่าบัญชีเหล่านั้นเป็นของคนเดียวกัน เพราะมือถือไม่ซ้ำกันข้ามแพลตฟอร์มและอาจถูกนำกลับมาใช้หรือจับจองได้
- มองข้อความในโปรไฟล์ รูปอวตาร และประวัติย่อว่าเป็นคำกล่าวอ้างของผู้ถือบัญชี ไม่ใช่ข้อเท็จจริงที่ตรวจสอบแล้ว
ถ้ามีคนยกป้าย verified เป็นหลักฐานว่าเขาควบคุมบัญชีอยู่ในปัจจุบัน นั่นคือการจัดประเภทผิด ป้ายไม่ได้วัดความปลอดภัยของการเข้าสู่ระบบปัจจุบัน และไม่ได้ยืนยันว่าคนที่กำลังพูดกับคุณคือผู้ถือบัญชี
ขั้นที่ 4: มองหาหลักฐานอิสระ
หลักฐานอิสระคือสิ่งใดก็ตามที่ไม่ได้มาจากบัญชีเดียวกันกับที่กล่าวอ้าง ตัวอย่างเช่น รายชื่อสมาชิกทีมที่องค์กรเผยแพร่เอง รายการบรรยายบนเว็บไซต์งานประชุม หรือรีโพซิทอรีที่ดูแลภายใต้บัญชีองค์กรซึ่งมีบันทึกสาธารณะของตัวเอง แม้สิ่งเหล่านี้ก็เป็นการสนับสนุน ไม่ใช่หลักฐานยืนยันตัวตน หน้าที่ของคุณคือตัดสินว่าการรวมกันของหลักฐานควรมีน้ำหนักแค่ไหน ไม่ใช่ประกาศความแน่ใจ
ตารางตัดสินใจ: ควรให้น้ำหนักกับป้าย verified แค่ไหน
| สถานการณ์ | การตีความที่สมเหตุสมผล | ความไม่แน่นอนที่ยังเหลือ |
|---|---|---|
| มีป้าย คีย์ยังเชื่อมกับบัญชี และ commit ใหม่ | ลายเซ็นถูกตรวจสอบแล้วและการเชื่อมคีย์เป็นปัจจุบัน | ไม่ได้พิสูจน์ว่าบุคคลนั้นควบคุมบัญชีหรือเขียนโค้ด |
| มีป้าย แต่คีย์ถูกเพิกถอนหรือหมดอายุ | การตรวจสอบถูกบันทึกไว้ตอนที่เกิดขึ้น | ไม่บอกอะไรเกี่ยวกับความเชื่อถือคีย์ปัจจุบันหรือความปลอดภัยของบัญชี |
| มีป้ายเฉพาะบน commit เก่า | บันทึกการตรวจสอบเชิงประวัติศาสตร์ | ไม่มีนัยเกี่ยวกับกิจกรรมหรือการควบคุมในปัจจุบัน |
| ไม่มีป้าย | ไม่มีลายเซ็นที่ verified บน commit นั้น | การไม่มีไม่ได้เป็นหลักฐานของการกระทำผิด กระบวนการทำงานที่ชอบด้วยกฎหมายหลายแบบไม่ได้ลงนามทุก commit |
| มีป้ายและมีมือถือตรงกันบนแพลตฟอร์มอื่น | เบาะแสที่ควรติดตาม | มือถือไม่ซ้ำกัน บัญชีอาจเป็นของคนละคน |
| มีป้ายและมีการกล่าวถึงในโปรไฟล์องค์กร | การสนับสนุนความเป็นไปได้ของความเกี่ยวข้อง | ไม่ได้พิสูจน์การจ้างงานหรืออำนาจในการพูดแทนองค์กร |
ข้อผิดพลาดที่พบบ่อย
- ตีความป้ายว่าเป็นการตรวจสอบตัวตน มันคือผลของลายเซ็น ไม่ใช่การตรวจประวัติภูมิหลัง
- สันนิษฐานว่าป้ายเก่าแก่พิสูจน์ความปลอดภัยของบัญชีปัจจุบัน บันทึกอาจคงอยู่หลังคีย์ถูกเพิกถอนหรือหมดอายุ ป้ายจึงไม่ใช่ไฟสถานะสด
- สับสนเมทาดาทา author และ committer กับความเป็นผู้เขียน ฟิลด์เหล่านี้เป็นคำกล่าวอ้างในออบเจกต์ commit ไม่ใช่ข้อเท็จจริงที่ตรวจสอบแล้วว่าใครเขียนโค้ด
- ถือว่ามือถือที่ตรงกันเป็นหลักฐานว่าเป็นคนเดียวกัน มือถือเดียวกันบนสองแพลตฟอร์มเป็นเบาะแส ไม่ใช่หลักฐานว่าบัญชีเหล่านั้นเป็นของบุคคลเดียวกัน
- อ่านป้ายบน fork ว่าเป็นการรับรองจากองค์กร commit ที่ verified ใน fork ส่วนตัวไม่ได้ยืนยันว่าองค์กรตรวจทานหรือรับรองงานนั้น
- สันนิษฐานว่า commit ที่ไม่ลงนามน่าสงสัย ผู้มีส่วนร่วมและกระบวนการทำงานที่ชอบด้วยกฎหมายหลายแบบไม่ได้ลงนามทุก commit
รายการตรวจสอบด้วยตัวเอง
ก่อนที่คุณจะพูดซ้ำข้อกล่าวอ้างเกี่ยวกับนักพัฒนาที่อาศัยป้าย verified ให้ทำรายการตรวจสอบนี้
- ฉันเปิด commit และบันทึก author, committer, คีย์, รีโพซิทอรี และวันที่แล้วหรือยัง
- ฉันแยก “ลายเซ็นผ่านการตรวจ” ออกจาก “การควบคุมบัญชี” และจาก “ตัวตนหรือการจ้างงาน” แล้วหรือยัง
- ฉันตรวจแล้วหรือยังว่าคีย์ยังเชื่อมกับบัญชีอยู่ หรือบันทึกอาจคงอยู่หลังการเพิกถอนหรือหมดอายุ
- ฉันมองหาแหล่งข้อมูลอย่างน้อยหนึ่งแหล่งที่ไม่ได้มาจากบัญชีเดียวกันแล้วหรือยัง
- ฉันอธิบายมือถือที่ตรงกันว่าเป็นเบาะแส ไม่ใช่หลักฐานว่าเป็นคนเดียวกันแล้วหรือยัง
- ฉันหลีกเลี่ยงการอ้างว่าป้ายพิสูจน์ความปลอดภัยปัจจุบัน ความเป็นผู้เขียน หรือการจ้างงานแล้วหรือยัง
ปกป้องร่องรอยของคุณเอง
ถ้าคุณลงนาม commit จำไว้ว่าป้าย verified คือบันทึกที่คุณทิ้งไว้ มันอาจอยู่ได้นานกว่าคีย์ที่สร้างมัน ก่อนที่คุณจะเพิกถอนหรือหมุนเวียนคีย์ลงนาม ตัดสินใจว่าคุณอยากให้ commit เก่าอ่านอย่างไร และเก็บบันทึกของคุณเองว่าคีย์ใดถูกใช้เมื่อใด ถ้าคุณดูแลโปรไฟล์สาธารณะ ให้ทบทวนมือถือที่คุณเคยใช้เมื่อเวลาผ่านไปและตรวจว่าบัญชีเก่ายังชี้มาที่คุณอยู่หรือไม่ การค้นหาชื่อผู้ใช้อย่าง TraceSeek ช่วยให้คุณทบทวนมือถือสาธารณะที่รู้จักของคุณเองข้าม 3,000+ แพลตฟอร์มได้ สแกนครั้งแรกฟรีและไม่ต้องลงทะเบียนหรือเข้าสู่ระบบ และโดยทั่วไปผลลัพธ์จะส่งคืนภายใน 20–30 วินาที มองผลลัพธ์เป็นรายการเบาะแสที่ต้องตรวจทาน ไม่ใช่การยืนยันตัวตน TraceSeek ไม่เปลี่ยนการตั้งค่าแพลตฟอร์ม ไม่รับประกันว่าจะพบข้อมูลที่ตรงกัน และไม่ยืนยันตัวตนของใคร ดูวิธีที่เรากรอบหลักฐานและข้อจำกัดได้ใน ระเบียบวิธี ของเรา
ข้อเท็จจริงสำคัญ
- GitHub ทำเครื่องหมาย commit ที่ลงนามแล้วว่า Verified เมื่อตรวจสอบลายเซ็นสำเร็จ
- เมื่อบันทึกการตรวจสอบแล้ว บันทึกนั้นอาจคงอยู่ต่อไปได้แม้คีย์ที่ใช้ลงนามจะถูกเพิกถอนหรือหมดอายุ
- ป้าย verified commit เป็นผลของลายเซ็นสำหรับ commit หนึ่ง ๆ ไม่ใช่หลักฐานการควบคุมบัญชีปัจจุบันหรือตัวตน
- ตัวระบุสาธารณะที่ตรงกันข้ามแพลตฟอร์มเป็นเบาะแส ไม่ใช่หลักฐานว่าบัญชีเหล่านั้นเป็นของคนเดียวกัน
- TraceSeek ครอบคลุม 3,000+ แพลตฟอร์ม และเสนอการสแกนครั้งแรกฟรีโดยไม่ต้องลงทะเบียนหรือเข้าสู่ระบบ