แบ็กดอร์ XZ: เวลา เวลาที่ถูกสาป และการหลอกลวง

 (rheaeve.substack.com)
2 คะแนน โดย GN⁺ 2024-04-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ประเด็นรอบ แบ็กดอร์ ใน tarball ของ xz/liblzma ใช้เขตเวลาและรูปแบบเวลาทำงานของ Git commit ของ Jia Tan เป็นเบาะแสในการคาดเดาพื้นที่ที่มีการทำงานจริง
  • แม้เวลาของ commit จะถูกปรับแต่งได้ด้วย GIT_AUTHOR_DATE และ GIT_COMMITTER_DATE แต่การทำให้ไทม์ไลน์ทั้งหมดดูสมจริงอาจยากกว่า จึงมีความเป็นไปได้สูงกว่าว่าจะใช้วิธี เปลี่ยนเฉพาะเขตเวลา
  • commit ของ Jia Tan จำนวน 440 รายการส่วนใหญ่ถูกบันทึกเป็น UTC+08 แต่บางรายการที่เป็น UTC+02 และ UTC+03 กลับสอดคล้องกับการสลับเวลาในฤดูหนาวและฤดูร้อนแบบยุโรปตะวันออก
  • การสลับเขตเวลาในวันที่ 6 ตุลาคม 2022 และ 27 มิถุนายน 2023 เกิดขึ้นในช่วงเวลาที่สั้นเกินกว่าจะอธิบายได้ด้วยการเดินทางจริง ทำให้สมมติฐานเรื่องการเดินทางธรรมดาดูน่าเชื่อน้อยลง
  • commit บางรายการที่เป็น +0200 ดูเหมือนจะเป็นแพตช์ที่ Lasse Collin ใช้ git am นำเข้า ซึ่งทำให้ความน่าเชื่อถือของ ข้อมูลเขตเวลา ต่ำลงในเวิร์กโฟลว์แบบอีเมลแพตช์

แบ็กดอร์ xz และสิ่งที่นำมาวิเคราะห์

  • แบ็กดอร์ ที่พบใน tarball ของ xz/liblzma ถูกมองว่าเป็นเหตุการณ์ที่สั่นคลอนความเชื่อมั่นในระบบนิเวศซอฟต์แวร์เสรีอย่างมาก
  • มีการมองว่าแบ็กดอร์อาจถูกใส่โดย Jia Tan ซึ่งเป็นเมนเทนเนอร์หลักระยะยาวของ xz
  • ในชุมชนมีข้อมูลเกี่ยวกับ Jia Tan แทบไม่มีนอกจากชื่อ และแม้แต่ชื่อนั้นก็อาจไม่ใช่ชื่อจริง
  • สิ่งที่นำมาวิเคราะห์คือ กิจกรรมบน GitHub ของ JiaT75 และ timestamp ของ commit ใน repository ของ xz
  • จุดตั้งต้นของการวิเคราะห์นี้คือ โพสต์ใน mailing list ของ oss-security

ทำไมการปลอมแปลง Git timestamp จึงทำได้ยาก

  • เวลาของ Git commit สามารถเปลี่ยนได้ด้วย environment variable GIT_AUTHOR_DATE และ GIT_COMMITTER_DATE
  • commit ที่ยังไม่ได้ push ก็สามารถแก้วันที่ย้อนหลังภายหลังได้ด้วย amend
  • แต่การ ปลอมแปลงข้อมูลเวลา ให้ดูสมจริงมีข้อจำกัดหลายอย่าง
    • หาก push commit ที่ดูเหมือนถูกสร้างในอนาคต ก็อาจชวนให้สงสัย
    • commit ที่ดูเก่ากว่าการสนทนาออนไลน์ที่เกี่ยวข้องก็ไม่เป็นธรรมชาติ
    • หากต้องการหลีกเลี่ยงข้อจำกัดเหล่านี้ อาจต้องกัก commit ไว้ก่อน ซึ่งทำให้การพัฒนาโปรเจกต์ล่าช้าได้
  • แทนที่จะปรับเวลาจริง หาก เปลี่ยนเฉพาะเขตเวลา ก็อาจหลอกได้ง่ายกว่าโดยไม่ต้องคำนวณมากหรือหน่วงเวลา commit

ความเป็นไปได้ของบันทึกแบบ UTC+08 และ UTC+02/03

  • commit ของ Jia Tan ส่วนใหญ่จำนวน 440 รายการ มี timestamp เป็น UTC+08
  • UTC+08 มีแนวโน้มว่าจะเป็นเวลา CST ของจีน แต่ก็เป็นเขตเวลาเดียวกับอินโดนีเซีย ฟิลิปปินส์ และออสเตรเลียตะวันตกด้วย
  • ชื่อ Jia Tan อาจเป็นสัญญาณที่ตั้งใจทำให้ดูเหมือนเป็นคนเอเชีย โดยเฉพาะคนจีน
  • มีการเสนอว่าพื้นที่ที่มีการทำงานจริงอาจเป็นเขต UTC+02 ในฤดูหนาว / UTC+03 ในฤดูร้อน
    • พื้นที่ดังกล่าวรวมถึง EET ของยุโรปตะวันออก และ IST ของอิสราเอล
    • หากปรับบันทึก UTC+08 มาอิง UTC+02/03 จะกลายเป็นรูปแบบการทำงานปกติช่วง 9 โมงเช้าถึง 6 โมงเย็น
    • หากไม่ปรับ จะกลายเป็นรูปแบบที่ทำงานตอนเที่ยงคืนและตี 1 ของคืนวันอังคาร ซึ่งดูไม่เป็นธรรมชาติเท่าไร

เบาะแสที่ปรากฏจากการสลับเขตเวลา

  • commit บางรายการอาจเป็นผลจากการที่ Jia Tan ลืมเปลี่ยนเขตเวลา
  • พบ commit ที่เป็น UTC+02 จำนวน 3 รายการ และ UTC+03 จำนวน 6 รายการ
    • UTC+02 สอดคล้องกับเวลาในฤดูหนาวของเดือนกุมภาพันธ์และพฤศจิกายน
    • UTC+03 สอดคล้องกับเวลาในฤดูร้อนของเดือนมิถุนายน กรกฎาคม และต้นตุลาคม
    • สิ่งนี้ตรงกับรูปแบบการเปลี่ยนเวลาออมแสงของยุโรปตะวันออก คือ +0200 หลังสุดสัปดาห์สุดท้ายของเดือนตุลาคม และ +0300 หลังวันอาทิตย์สุดท้ายของเดือนมีนาคม
  • เขตเวลาเหล่านี้ยังดูเหมือนจะตรงกับเขตเวลาของ Lasse Collin และ Hans Jansen ด้วย
  • ในอัปเดตวันที่ 2 เมษายน มีการสะท้อนข้อสังเกตของ Joey Hess ว่าหลายกรณีในลักษณะนี้เป็น commit ที่มี Lasse Collin เป็น committer
    • อย่างไรก็ตาม ปรากฏการณ์แบบเดียวกันไม่ได้เกิดกับทุก commit ของ Jia ที่ Lasse เป็นผู้ commit และหลายกรณีก็ยังถูกบันทึกเป็น +0800
    • ดังนั้นจึงยังไม่ชัดเจนว่า commit แบบ +02/03 เป็นความผิดพลาดหรือแค่ความเปลี่ยนแปลงของเวิร์กโฟลว์

ช่วงเวลาที่อธิบายด้วยการเดินทางจริงได้ยาก

  • คำอธิบายว่าผู้ที่อาศัยใน UTC+08 เดินทางไปยังพื้นที่ UTC+02/03 เป็นครั้งคราวนั้นไม่สอดคล้องกับรายละเอียดของ timestamp มากนัก
  • วันที่ 6 ตุลาคม 2022 มี commit เวลา 21:53:09 +0300 ตามด้วย commit เวลา 17:00:38 +0800
    • ช่วงห่างระหว่างสอง commit นี้ประมาณ 11 ชั่วโมง
    • จากจีนไปยุโรปตะวันออกหรือตะวันออกกลาง ใช้เวลาเดินทางทางอากาศอย่างน้อย 10-12 ชั่วโมงโดยยังไม่นับปัจจัยอื่น และเที่ยวบินตรงก็หาได้ไม่ง่าย จึงอาจใช้เวลานานกว่านั้น
  • วันที่ 27 มิถุนายน 2023 มี commit เวลา 23:38:32 +0800 ต่อเนื่องกับ commit เวลา 17:27:09 +0300
    • ความต่างระหว่างสอง commit อยู่ในระดับเพียงไม่กี่นาที
  • การสลับแบบนี้สนับสนุนความเป็นไปได้ว่า Jia Tan ไม่ได้อยู่ในพื้นที่ CST ที่เป็น UTC+08 จริง

รูปแบบวันหยุดและการทำงานในวันธรรมดา

  • รูปแบบวันหยุดก็ดูจะสอดคล้องกับ ยุโรปตะวันออก มากกว่าจีน
  • รายการวันหยุดราชการของจีนอ้างอิงจาก ประกาศวันหยุดปี 2023 ของ Bank of China Indonesia
  • พบประวัติการทำงานในวันที่ถูกระบุว่าเป็นวันหยุดของจีนด้วย
    • 29 กันยายน 2023: เทศกาลไหว้พระจันทร์
    • 5 เมษายน 2023: เทศกาลเช็งเม้ง
    • 22-27 มกราคม 2023 เป็นต้น: ช่วงตรุษจีน
  • สำหรับวันหยุดของยุโรปตะวันออก มีข้อสังเกตว่าไม่มีประวัติการทำงานในวันคริสต์มาส 25 ธันวาคม และช่วงปีใหม่ 31 ธันวาคมกับ 1 มกราคม
  • วันที่ Jia ทำงานบ่อยที่สุดคือวันอังคาร 86 ครั้ง วันพุธ 85 ครั้ง วันพฤหัสบดี 89 ครั้ง และวันศุกร์ 79 ครั้ง

ข้อสังเกตเรื่องชื่อและ caveat ของการใช้แพตช์

  • มีข้อสังเกตว่าหาก “Jia Cheong Tan” เป็นชื่อจริง ก็ไม่น่าเป็นการถอดเสียงชื่อจีนด้วยอักษรโรมันที่ใช้ในจีน และใกล้เคียงกับรูปแบบในเอเชียตะวันออกเฉียงใต้ เช่น มาเลเซีย มากกว่า
  • การสะกด “Cheong” ไม่ได้ใช้ในจีนยุคปัจจุบัน และยังมีตัวอย่างว่าการเขียนชื่อจีนเป็นภาษาอังกฤษแบบจีนมักจะเขียนพยางค์ของชื่อให้ติดกัน
    • ตัวอย่างคือ “Yangqing Jia” ไม่ใช่ “Yang Qing Jia”
  • อย่างไรก็ตาม commit +0200 สองรายการ de5c5e4, e446ab7a มี Lasse Collin เป็น committer และดูเหมือนเป็นแพตช์ที่ Jia ส่งมาทางอีเมลแล้วถูกนำเข้าโดย git am
  • commit เหล่านั้นและบาง commit ที่อยู่ใกล้กันมี timestamp เดียวกัน ซึ่งสอดคล้องกับกรณีที่มีการใช้ git am นำเข้าชุดไฟล์แพตช์
  • เมื่อแพตช์ถูกส่งผ่านอีเมล ก็ยากที่จะพึ่งพา ข้อมูลเขตเวลา ได้ ทำให้บางส่วนของการวิเคราะห์นี้อ่อนลง

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

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

 
GN⁺ 2024-04-01
ความเห็นจาก Hacker News

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

    • มีความเป็นไปได้สูงว่าเบื้องหลังปฏิบัติการนี้คือ ทั้งทีม และงานของทีมนั้นอาจรวมถึงเรื่องอย่าง “ชักจูงทางวิศวกรรมสังคมให้โปรเจกต์ XZ ยอมรับผู้ดูแลที่เราเลือก”
      ในโพสต์อื่น[1] ก็มีการเสนอว่าบัญชีที่เพิ่งเกิดขึ้นอย่างกะทันหันอาจถูกใช้เพื่อสร้างความรู้สึกเร่งด่วนและเร่งการโอนสิทธิ์ดูแล
      [1] https://connortumbleson.com/2024/03/31/watching-xz-unfold-fr...
      via: https://news.ycombinator.com/item?id=39888854
      ส่วนที่เกี่ยวข้องค้นหาได้ด้วย "Progress will not happen until there is new maintainer"
    • ถ้าตั้งต้นว่าไม่ใช่ “หมาป่าเดียวดายคนเดียว” ก็จะมีอีกหลายอย่างที่เป็นไปได้มากขึ้น
      รวมถึงการทำให้ดูเหมือนเคลื่อนไหวจากสถานที่หนึ่งโดยเฉพาะ และในเวลาเดียวกันก็ ทำให้ไม่ดูเหมือนมีมากกว่าหนึ่งคน

  • ผมคิดว่าไม่น่าใช่คนจากยุโรปตะวันออก แต่เมื่อดู UTC+0200/+0300 แล้ว ในยุโรปก็จะมีฟินแลนด์ กลุ่มประเทศบอลติก ยูเครน โรมาเนีย มอลโดวา และกรีซที่เข้าเกณฑ์
    ถ้าลงมาทางใต้หน่อย ก็รวมพื้นที่ส่วนใหญ่ของตะวันออกกลางรวมถึงอิสราเอลด้วย

    • มี ช่องว่าง 4 สัปดาห์ ในเดือนสิงหาคม ซึ่งสอดคล้องกับตารางวันหยุดของยุโรป
      แต่ในฟินแลนด์คนมักนิยมลาหยุดในเดือนกรกฎาคมมากกว่า จึงพบน้อยกว่า
    • Tukaani เป็น องค์กรฟินแลนด์ ที่หลัก ๆ มีชาวฟินแลนด์ร่วมพัฒนา และเมื่อดูรายชื่อผู้มีส่วนร่วมก็แทบทั้งหมดเป็นชื่อแบบฟินแลนด์
      ดูเผิน ๆ แล้วก็สมเหตุสมผลดี
    • ถ้าดูจากเวลาออมแสงและวันหยุด ก็สงสัยว่าอิสราเอลจะสอดคล้องได้อย่างไร
    • ไม่รู้ว่าทำไมถึงโดนโหวตลบ พอนึกถึงผู้กระทำระดับรัฐ อิสราเอลก็ติดกลุ่มบน ๆ ร่วมกับสหรัฐ รัสเซีย จีน และเกาหลีเหนือ เพราะมีกรณีอย่าง Stuxnet
      โดยเฉพาะ Unit 8200 ของ IDF นั้นมีชื่อเสียงพอตัว
      ไม่ได้แปลว่าประเทศอื่นไม่มีความสามารถ หรือว่าการโจมตีนี้ดูเหมือนต้องใช้ทรัพยากรระดับ NSA หรือ GCHQ เสมอไป ความจริงอาจเป็นหมาป่าเดียวดายคนเดียวก็ได้ แต่ก็ยังน่าสนใจอยู่ดี
    • “อย่าไว้ใจใครทั้งนั้น! ตั้งแต่พระเจ้าถ่ายมนุษย์ดึกดำบรรพ์คนที่สามออกมา ก็มีการสมคบคิดเล่นงานหนึ่งในนั้นแล้ว!” - Gen. Hunter Gathers, OSI (The Venture Bros.)
      กลุ่มที่มีทรัพยากรและแรงจูงใจแทบไม่จำกัดสามารถจัด ปฏิบัติการลวง เพื่อผลักความรับผิดไปในทิศทางใดทิศทางหนึ่งได้ พวกเขาเก่งมากในการลบร่องรอย และต่อให้นักวิจัยด้านความปลอดภัยที่ชำนาญที่สุดก็อาจต้องใช้เวลาหลายเดือนหรือหลายปีกว่าจะสรุปแบบมีเหตุผลได้ว่าใครเป็นคนทำ
      เพราะอย่างนั้นการพยายามหาว่า “ใครเป็นคนทำ” จึงแทบเป็นการเสียเวลา
      บทเรียนคือ: อย่าเอาซอฟต์แวร์ล้ำสมัยที่ยังไม่ผ่านการพิสูจน์เข้าไปในสภาพแวดล้อม production ไม่ว่าด้วยเหตุผลใด, ผู้ทดสอบการเจาะระบบขององค์กรควรพยายามพังสแตกเป็นประจำแล้วแจ้งผลให้องค์กรและผู้ดูแลแพ็กเกจทราบ, ผู้ดูแล free/open source ควรตรวจสอบโค้ดใหม่ที่อ่อนไหวด้านความปลอดภัยเป็นพิเศษในทุกรีลีส, และควรบริจาคให้ผู้ดูแลด้วย
      โชคดีที่มันไม่ได้เข้า stable และเข้าใกล้ระดับ เชอร์โนบิลด้านความปลอดภัย ภายในระบบแบบเฉียดฉิวก่อนจะรอดมาได้
      มีคนที่พยายามโน้มน้าวทุกคนว่ากลุ่มใดกลุ่มหนึ่งต้องเป็นผู้รับผิดชอบ ซึ่งมีเป้าหมายทางภูมิรัฐศาสตร์อยู่เบื้องหลัง ตัวอย่างเช่น ในสหรัฐมีการถกเถียงเรื่องห้ามต่างชาติถือครองเว็บแอปยอดนิยม หากมีกฎหมายแบบนั้นแล้วรัฐบาลหรือบริษัทที่ได้ประโยชน์จากมันจะสะดวกแค่ไหน ถ้าผู้ใช้ GitHub ชื่อจีนคนหนึ่งคอมมิตเวกเตอร์การโจมตีด้วยไทม์สแตมป์ที่ทำให้ดูเหมือนมาจาก PRC
      ต่อให้เป็นคนจากจีนแผ่นดินใหญ่จริง ๆ ถ้าได้รับการสนับสนุนจากรัฐ ก็แทบไม่มีโอกาสที่จะถูกส่งตัวให้เจ้าหน้าที่สหรัฐ แม้จะมีการตั้งข้อหาและคำร้องขอส่งผู้ร้ายข้ามแดนก็ตาม ตรงกันข้าม อาจถูก “ปิดปาก” เพื่อไม่ให้ข้อมูลขององค์กรที่ใหญ่กว่ารั่วไปถึงฝ่ายตรงข้าม
      ถ้าตัดทฤษฎีสมคบคิดแบบหนัง Bond ออกไป ความรู้นี้ก็แทบไม่มีที่ให้เอาไปใช้ในทางปฏิบัติอยู่ดี ปกติเราก็รู้อยู่แล้วว่าผู้ใช้มาจากที่ไหน และก็อาจบล็อกตามภูมิภาคได้ ถ้าไม่ใช่ ก็ต้องเตรียมรับมือภัยคุกคามอื่นจากภูมิภาคนั้นอยู่แล้ว

  • GMT+8, โครงสร้างของชื่อ (ชื่อแบบจีน/ผสมภาษาถิ่น + นามสกุล Hokkien) และข้อบ่งชี้ว่าเข้าถึงจากสิ่งที่ดูเหมือน VPN exit หรือโฮสติ้งเซิร์ฟเวอร์ในสิงคโปร์[1] ล้วนสอดคล้องกับ อัตลักษณ์แบบสิงคโปร์ ไม่ว่าจะเป็นของจริงหรือการปลอมแปลง
    ดังนั้นสิ่งที่แหล่งที่มาใน [1] ระบุว่า “ชื่อนี้ฟังดูปลอม” ก็ควรฟังหูไว้หูในระดับหนึ่ง คนจีนแผ่นดินใหญ่ไม่ได้รู้จักชุมชนชาวจีนโพ้นทะเลดีเสมอไป
    วันหยุดที่ถูกกล่าวถึงหลายวันก็ไม่ใช่วันหยุดราชการของสิงคโปร์[2] เช่นกัน วันที่ 24 มกราคมเป็นวันหยุด แต่ถ้าจะใช้แพตเทิร์นว่า “ทำงานในวันทำการ” วันที่ 22 มกราคมเป็นวันอาทิตย์แต่กลับถูกระบุว่ามีการทำงาน
    น่าสนใจถ้าได้ดูงานเขียนของ Jia Tan มากขึ้น โดยเฉพาะงานเก่า ๆ เพราะอาจมีลักษณะทางภาษาที่ค่อนข้างชัดเจนพอใช้แยกชาวสิงคโปร์ ชาวจีนแผ่นดินใหญ่ ผู้พูดภาษากลุ่มสลาวิกหลายภาษา และเจ้าของภาษาอังกฤษได้
    [1] https://boehs.org/node/everything-i-know-about-the-xz-backdo...
    [2] https://www.mom.gov.sg/employment-practices/public-holidays

    • จากคอมมิตบางส่วนของ Jia Tan ที่ผมเห็น ภาษาอังกฤษอ่านลื่นไหลเหมือนเจ้าของภาษาสหรัฐหรือสหราชอาณาจักร และผมไม่เห็นร่องรอยของ ภาษาอังกฤษแบบสิงคโปร์
      แน่นอนว่าตัวอย่างมีน้อยมาก เลยสรุปอะไรมากไม่ได้
      ชาวสิงคโปร์เกือบ 10% ใช้นามสกุล Tan
      [1] [https://en.wikipedia.org/wiki/File:Singaporean_surnames_by_f...](https://en.wikipedia.org/wiki/File:Singaporean_surnames_by_frequency.png)
    • Tan ไม่ได้เป็นแค่นามสกุล Hokkien อีกแบบหนึ่งของ 陳 ที่พบได้บ่อยกว่ามากเท่านั้น แต่ยังเป็นนามสกุลจีน 譚 ด้วย

  • ถ้าไม่นับความร้ายแรงของประเด็นนี้ไว้ก่อน ฉันอินกับความเป็นนิยายสืบสวนของเหตุการณ์นี้มาก
    กระบวนการที่อินเทอร์เน็ตช่วยกันต่อภาพว่า “ใคร ทำอย่างไร และทำไปทำไม” นั้นน่าสนใจมาก

  • เมื่อหลายปีก่อน ฉันตั้งให้ gc ในเทอร์มินัลแมปไปที่ TZ=UTC0 git commit ก็ด้วยเหตุผลแบบนี้พอดี
    ไม่จำเป็นต้องเปลี่ยนเวลาระบบหรือการตั้งค่า git อาจมีวิธีที่ดีกว่านี้ใน global config ก็ได้
    ไม่ใช่ด้วยเหตุผลร้ายอะไร ฉันเดินทางบ่อยและไม่อยากให้ตารางการเดินทางรั่วออกไปใน public repository

    • ฉันทำเครื่องมือเล็ก ๆ ไว้ใช้เพื่อซ่อนข้อมูลเวลาใน git commit: https://github.com/SmartHypercube/git-date-truncate
      มันไม่ได้แค่ตั้งเขตเวลาเป็น UTC แต่ยังตั้งเวลาเป็น 00:00 ทำให้ใน commit เหลือเพียงข้อมูลวันที่เท่านั้น ฉันคิดว่าข้อมูลที่ถูกเก็บถาวรใน git commit แค่ระดับวันที่ก็เพียงพอแล้ว และไม่จำเป็นต้องปล่อยเวลา commit แบบเป๊ะ ๆ ออกไป
    • แบบนี้เป็นไง?
      alias git='TZ=UTC0 git'
    • ถึงจะเดินทางบ่อย แต่ช่วงนี้ฉันก็ไม่ได้เปลี่ยนเขตเวลาของเวิร์กสเตชันจาก PST/PDT
      เพราะมันต้องทำเอง และฉันก็ไม่ได้ใช้บริการระบุตำแหน่งด้วย

  • น่าเห็นใจ Jia นะ งานที่ทำมา 2 ปีพังหมดเลย
    Jia ถ้าคุณกำลังอ่านข้อความนี้อยู่ จำไว้ว่าช็อตที่ไม่ได้ยิงคือช็อตที่พลาด 100% เงยหน้าขึ้นนะพี่ชาย

    • ไม่มีใครรู้ว่าคนที่อยู่หลังบุคลิกออนไลน์นั้นมีตัวตนอีกกี่แบบ และใช้ตัวตนเหล่านั้นไปปนเปื้อนโปรเจกต์อื่น ๆ มากแค่ไหน
    • ไม่ต้องกังวลหรอก พวกเขา หรือก็คือทีมนั่นแหละ คงไปมีส่วนร่วมกับ image library, WebKit, Kubernetes และอย่างอื่นด้วย
    • ทำไมถึงมองว่าพังหมดล่ะ? รู้แล้วเหรอว่าเขาไม่บรรลุเป้าหมาย?
    • ยากจะมั่นใจว่า JiaT ทำงานอยู่แค่ในโปรเจกต์ xz เท่านั้น

  • “ใครกันที่ทำงานเป็นประจำตั้งแต่เช้ามืด?”
    ฉันเอง
    “ถ้าเป็นแฮ็กเกอร์ก็ดูน่าเป็นไปได้กว่ามากที่จะทำงานตอนบ่ายหรือดึก”
    ถ้าเปลี่ยนคำว่าแฮ็กเกอร์ตรงนี้เป็นคนหนุ่มสาวก็น่าจะตรงกว่า

    • ภาพเหมารวมเรื่อง “แฮ็กเกอร์” ก็ล้าสมัยอยู่แล้ว แต่การเปลี่ยนเป็น “คนหนุ่มสาว” แล้วสื่อเป็นนัยว่าไม่ใช่ “คนอายุมาก” ก็ประหลาดพอ ๆ กัน
      ฉันอายุ 41 แล้ว และในช่วง 10 ปีที่ผ่านมา วันไหนที่ตื่นก่อน 7 โมงเช้ามีรวมกันสัก 20 วันได้ไหมยังไม่แน่ใจ ครึ่งหนึ่งของเหตุผลที่ฉันยังทนทำงานสายคอมพิวเตอร์ได้อยู่ ก็เพราะมันเป็นหนึ่งในไม่กี่อาชีพที่ยังทำได้ดีแม้จะทำงานตามตาราง 11:00–19:00 น. เกือบทุกวัน
      มีทั้งคนนอนเช้าและคนนอนดึก แต่ละคนก็มีจังหวะของตัวเอง ไม่ใช่เรื่องให้ตัดสิน และมันไม่ได้เปลี่ยนเองตามธรรมชาติหรือจำเป็นต้องเปลี่ยนเมื่ออายุมากขึ้น
    • ไวยากรณ์ c/hacker/younger person นี่คืออะไร? ฉันรู้จัก s/a/b/ ของการแทนที่แบบ sed แต่ไม่เคยเห็นที่ขึ้นต้นด้วย c
    • ต่อให้ตัดภาพเหมารวมออกไป แฮ็กเกอร์ที่ตั้งใจโค้ดจริง ๆ ก็มักจะต้องจัดตาราง “เวลาทำงานจริง” ให้ล้อมรอบภาระผูกพันจากภายนอกอยู่ดี
      ตอนเช้ามักมีสิ่งรบกวนอย่างการต้องรับมือกับ “คนนอนเช้า” เยอะกว่า ส่วนหลังมื้อเที่ยงไปจนถึงตอนเย็นมักมีเรื่องแทรกน้อยกว่ามาก
      ในเวลา 4 ชั่วโมงที่ไม่ถูกรบกวน คุณทำงานได้มากกว่าเวลางาน 8 ชั่วโมงที่มีโทรศัพท์กับอีเมลเด้งเข้ามาแบบสุ่มเสียอีก ฉันก็ไม่ใช่คนหนุ่มแล้วเหมือนกัน แต่ถ้าไม่มีอะไรมารบกวน และมีเวลาได้คิดค้างไว้เป็นพัก ๆ หลายชั่วโมง ฉันก็ทำงานตอนกลางคืนบ้างเพราะจบได้ในครึ่งเวลา
      ถ้าคุณมีเช้าที่สงบสุข ก็อิจฉาจริง ๆ

  • “มีสอง commit ในวันอังคารที่ 27 มิถุนายน 2023 คือ 23:38:32 +0800 กับ 17:27:09 +0300 ถ้าคำนวณดูจะห่างกันประมาณ 9 ชั่วโมง”
    แต่ 17:27:09 +0300 ก็คือ 22:27:09 +0800 ไม่ใช่หรือ? งั้นสอง commit นี้ก็ควรจะห่างกันประมาณ 1 ชั่วโมงไม่ใช่เหรอ?

    • ใช่ และยังมีส่วนที่แย่กว่านั้นอีก
      “ที่ชี้ขาดยิ่งกว่าคือในวันที่ 6 ตุลาคม 2022 มี commit เวลา 21:53:09 +0300 แล้วตามด้วย commit เวลา 17:00:38 +0800 ซึ่งห่างกันเพียงไม่กี่นาที!”
      ไม่ใช่เลย อันนี้ห่างกันเกือบ 10 ชั่วโมง
      ดูเหมือนผู้เขียนจะสลับสองกรณีวิเคราะห์กันโดยไม่ได้ตั้งใจ หรือไม่ก็แปลงเขตเวลาไม่เก่ง

  • ถ้าเป็นคนอเมริกัน หรือคนจากที่อื่นโดยสิ้นเชิง แกล้งทำเป็นชาวยุโรปตะวันออกที่แกล้งทำเป็นคนจีนล่ะ?
    ถ้าจะอำพรางอะไรสักอย่าง อย่างน้อยก็น่าจะอ้อมเพิ่มอีกชั้น

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

  • ฉันเป็นหนึ่งในผู้เขียนต้นฉบับ ได้ไอเดียดี ๆ สำหรับการวิเคราะห์ต่อไปเยอะมาก และถ้าจะตอบข้อโต้แย้งสี่ข้อที่ถูกพูดถึงบ่อย ก็ประมาณนี้
    ฉันเห็นด้วยว่ายังไม่ชัดว่าเป็นคนเดียวหรือหลายคน แต่ถึงจะเป็นทีม แนวทางดูจากเขตเวลาก็ยังอาจบอกได้ว่าทีมนั้นอยู่ที่ไหน เวลาการทำงานมันดูคล้ายเวลางานปกติมากเกินไป มากกว่าจะเป็นทีมที่กระจายกันอยู่ทั่วโลก
    แน่นอนว่าเวลา commit อาจถูกเปลี่ยน หรืออาจมีการ commit/upload ผ่านสคริปต์ตั้งเวลาไว้ล่วงหน้าได้ แต่ถึงอย่างนั้น ถ้าจะซ่อนความต่างของเขตเวลาจริง ๆ แบบมาก ๆ ก็ต้องใส่ดีเลย์มหาศาล ซึ่งฉันมองว่าในทางปฏิบัติทำได้ยาก เพราะ xz ไม่ได้ถูกพัฒนาอยู่ในสุญญากาศ แต่มันพัฒนาไปพร้อมกับการตอบสนองต่อเหตุการณ์ออนไลน์ เช่น การเปิด issue หรือโพสต์ใน mailing list
    สองตัวอย่างนั้นฉันเขียนสลับกันจริง ๆ เวลาสองช่วงที่ฉันบอกว่าห่างกันราว 10 ชั่วโมง จริง ๆ แล้วห่างกันแค่ไม่กี่นาที ส่วนที่ฉันบอกว่าห่างกันไม่กี่นาที กลับห่างกันราว 10 ชั่วโมง จะอัปเดตแก้ไข
    สุดท้าย ประเด็นที่ว่า UTC+2/3 ไม่ได้ครอบคลุมแค่ยุโรปตะวันออก แต่รวมถึงบางส่วนของตะวันออกกลางด้วย ก็ถูกต้องเช่นกัน ฉันได้ทำให้จุดนี้ชัดเจนขึ้นแล้วในการอัปเดตบทความ