รายงานความปลอดภัยของ curl ที่สร้างโดย AI

• โปรเจกต์ curl ดำเนินโครงการ bug bounty และมีรายงานความปลอดภัยที่ดูเหมือนสร้างด้วย LLM เพิ่มขึ้น ทำให้เวลาของนักพัฒนาถูกใช้ไปกับการตรวจสอบรายงานเท็จมากกว่าการรับมือช่องโหว่จริง
• จนถึงตอนนี้ curl จ่ายเงินรางวัลไปแล้ว มากกว่า 70,000 ดอลลาร์ และได้รับรายงาน 415 ฉบับ แต่มีประเด็นความปลอดภัยจริง 64 รายการ และ 77 รายการถูกจัดเป็น informative
• แก่นของปัญหาคือรายงานเหล่านี้มีภาษาอังกฤษที่ดูน่าเชื่อถือ คำอธิบายละเอียด และแม้แต่ข้อเสนอแก้ไข ทำให้ ต้นทุนการตรวจสอบ สูงขึ้นอย่างมาก
• ในปี 2023 มีการส่งรายงานที่อ้างว่าการเปลี่ยนแปลงโค้ดของ CVE-2023-38545 ถูกเปิดเผย และรายงาน buffer overflow ใน WebSocket เข้ามา แต่ตามลำดับแล้วไม่มีการเปิดเผยจริงหรือไม่มี buffer overflow
• AI อาจมีประโยชน์ในฐานะเครื่องมือช่วยแปล ช่วยเขียนข้อความ หรือช่วยตรวจหาช่องโหว่ แต่การส่งผลลัพธ์จาก LLM โดยไม่มีการตรวจสอบจากมนุษย์ เป็นการผลักภาระต้นทุนการรับมือความปลอดภัยของโอเพนซอร์สไปให้โปรเจกต์

---

รายงานคุณภาพต่ำที่ bug bounty ของ curl ต้องเผชิญ

• โปรเจกต์ curl ดำเนินโครงการ bug bounty ที่จ่ายเงินรางวัลจริงให้แฮ็กเกอร์ที่รายงานปัญหาความปลอดภัย
• โอกาสได้รับเงินรางวัลดึงดูด “luck seekers” ที่เพียง grep หาแพตเทิร์นในซอร์สโค้ดหรือรันสแกนเนอร์ความปลอดภัยพื้นฐาน แล้วส่งผลลัพธ์เข้ามาโดยไม่มีการวิเคราะห์เพียงพอ
• รายงานคุณภาพต่ำในอดีตโดยทั่วไปสามารถระบุและทิ้งได้อย่างรวดเร็ว จึงไม่ได้ลุกลามเป็นปัญหาใหญ่ที่ทำให้โปรเจกต์เสียเวลามากนัก
• ผลลัพธ์ของ bug bounty ของ curl จนถึงตอนนี้:
  • จ่ายเงินรางวัล มากกว่า 70,000 ดอลลาร์
  • ได้รับรายงานช่องโหว่ 415 ฉบับ
  • ยืนยันว่าเป็นประเด็นความปลอดภัยจริง 64 รายการ
  • 77 รายการ ถูกจัดเป็น informative ซึ่งมักเป็นบั๊กทั่วไป เป็นต้น
  • 66% ของรายงานทั้งหมดไม่ใช่ทั้งประเด็นความปลอดภัยและไม่ใช่บั๊กทั่วไป

ทำไมรายงานเท็จที่ดูน่าเชื่อถือจึงอันตรายกว่า

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

รายงานความปลอดภัยที่ดูเหมือนสร้างโดย AI

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

ทำไมจึงทิ้งรายงานเพียงเพราะมีร่องรอย AI ได้ยาก

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

กรณี A: คำอ้างว่าการเปลี่ยนแปลงโค้ดของ CVE-2023-38545 ถูกเปิดเผย

• ในฤดูใบไม้ร่วงปี 2023 ชุมชน curl ได้รับแจ้งว่ากำลังจะเปิดเผย CVE-2023-38545 ซึ่งถูกประเมินความรุนแรงระดับ high
• หนึ่งวันก่อนที่ประเด็นดังกล่าวจะถูกเปิดเผย มีรายงานชื่อ “Curl CVE-2023-38545 vulnerability code changes are disclosed on the internet” ถูกส่งเข้ามาที่ HackerOne
• หากดูจากชื่อเรื่องอย่างเดียว เรื่องนี้อาจเป็นปัญหาใหญ่หากเป็นความจริง
• แต่รายงานดูเหมือน hallucination แบบ AI ทั่วไป โดยนำข้อเท็จจริงและรายละเอียดของประเด็นความปลอดภัยในอดีตมาปะปนกัน แล้วสร้างเนื้อหาใหม่ที่ไม่เชื่อมโยงกับความเป็นจริง
• การเปลี่ยนแปลงของ CVE-2023-38545 ไม่ได้ถูกเปิดเผยบนอินเทอร์เน็ต และการเปลี่ยนแปลงที่เผยแพร่อยู่แล้วนั้นเป็นเรื่องของประเด็นเก่าในอดีตตามเจตนา
• ผู้รายงานระบุว่าใช้ Bard เพื่อค้นหาประเด็นนี้ จึงช่วยให้เข้าใจข้อผิดพลาดและปิดรายงานได้ง่าย

กรณี B: คำอ้างเรื่อง WebSocket buffer overflow

• เช้าวันที่ 28 ธันวาคม 2023 มีรายงาน “Buffer Overflow Vulnerability in WebSocket Handling” ถูกส่งเข้ามาที่ HackerOne
• หากดูจากชื่อเรื่องอย่างเดียวก็ดูร้ายแรง แต่โค้ด WebSocket ของ curl ยังเป็น ฟีเจอร์ทดลอง จึงไม่อยู่ในขอบเขตของ bug bounty
• ผู้รายงานเป็นผู้ใช้ที่ไม่เคยเห็นมาก่อน แต่มีชื่อเสียงบน HackerOne อยู่ในระดับดี และไม่ใช่รายงานความปลอดภัยฉบับแรกของเขา
• รายงานถูกจัดระเบียบมาอย่างดี มีรายละเอียด ประโยคภาษาอังกฤษที่เหมาะสม และยังมีข้อเสนอแก้ไขด้วย
• ในตอนแรก รายงานดูดีกว่ารายงานครั้งแรกโดยเฉลี่ย และดูเหมือนผู้รายงานเข้าใจปัญหาและเสนอทางแก้ได้
• หลังจากผ่านไป 19 นาที มีการตรวจสอบโค้ดหลายครั้ง แต่ไม่พบ buffer overflow ตามที่กล่าวอ้าง
• หลังจากถามซ้ำและได้รับคำตอบแบบ hallucination หลายครั้ง จึงตัดสินว่าไม่ใช่ปัญหาจริง และปิดประเด็นดังกล่าวในสถานะ not applicable ในช่วงบ่ายวันเดียวกัน
• ไม่แน่ชัดว่าคำตอบเหล่านี้ถูกสร้างโดย LLM หรือไม่ แต่มีสัญญาณหลายอย่างหลงเหลืออยู่

ฟังก์ชันบล็อกของ HackerOne และบทลงโทษด้านชื่อเสียง

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

รายงานที่สร้างด้วย LLM จะเพิ่มมากขึ้น

• คาดว่ารายงานประเภทนี้จะพบได้บ่อยขึ้นเมื่อเวลาผ่านไป
• โปรเจกต์สามารถเรียนรู้ที่จะตรวจจับสัญญาณ generated-by-AI ได้ดีขึ้น และใช้เป็นเหตุผลในการทิ้งรายงาน
• อย่างไรก็ตาม อาจทำให้กรณีที่ใช้ AI อย่างเหมาะสม เช่น ช่วยแปลหรือช่วยจัดรูปประโยค ได้รับผลเสียไปด้วย
• ในอนาคตอาจมีเครื่องมือบางตัวที่ใช้ AI เพื่อค้นหาปัญหาความปลอดภัยแล้วทำงานได้ดีขึ้นจริง
• หากมี การตรวจสอบจากมนุษย์ เพิ่มเข้ามาแม้เพียงเล็กน้อย ก็น่าจะทำให้การใช้งานและผลลัพธ์ของเครื่องมือเหล่านี้ดีขึ้นมาก
• การหาทางลัดเพื่อหวังเงินรางวัลอย่างรวดเร็วน่าจะยังดำเนินต่อไป และด้วยสภาพแวดล้อมที่เข้าถึง LLM ทรงพลังได้ง่าย คาดว่าจะมีรายงานคุณภาพต่ำเข้าสู่กล่องขาเข้าของ HackerOne มากขึ้น

[GN⁺]

ความคิดเห็นบน Hacker News

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

  • Daniel Stenberg[1] ชี้ประเด็นได้ดี: curl ถูกใช้ทั่วโลก ดังนั้นจึงไม่แปลกเลยที่คนที่ไม่ได้ใช้ภาษาอังกฤษเป็นภาษาแม่จะใช้ LLM ช่วยเขียนรายงานบั๊ก
    เพราะฉะนั้น แค่ สัญญาณผิวเผิน ว่าประโยคภาษาอังกฤษดูเหมือนสร้างโดย LLM จึงยังสรุปไม่ได้ว่าเนื้อหารายงานเองก็ถูก LLM แต่งขึ้น

    [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

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

  • พอเห็นคำว่า “ฟังดูเหมือนพ่อบ้านหุ่นยนต์” จู่ ๆ ก็เข้าใจคำว่า Butlerian Jihad ขึ้นมา

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

  • แน่นอนว่าเป็น สัญญาณอันตราย ใหญ่ แต่ถ้าเป็นคนจริง ๆ ที่ส่งเนื้อหาห่วย ๆ นั้นมา ก็แค่ลบบรรทัดนั้นออกก็พอ
    เนื้อหายังน่าสงสัยอยู่ดี แต่เบาะแสให้จับได้จะน้อยลงมาก

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

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

• ตอนแรกคิดว่าบทความนี้ซ้ำกับ https://news.ycombinator.com/item?id=37904047 แต่ปรากฏว่าเป็น รายงานช่องโหว่ปลอมที่สร้างโดย LLM อีกฉบับบน HackerOne ที่ยื่นใส่ curl

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

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

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

• น่าสนใจที่เราได้ทำให้ การเขียน ซึ่งเป็นวิธีแบนด์วิดท์ต่ำที่สุดในการพิสูจน์การกระทำและความพยายาม กลายเป็นสิ่งที่ต้องใช้แรงงานมากขึ้นมากในการตัดสินว่ามีการกระทำหรือความพยายามจริงหรือไม่
  ผลกระทบลูกโซ่น่าจะใหญ่มาก
  ในกรณีนี้ ทั้งผู้แจ้งและผู้ดูแลต่างเสียเวลาที่ควรใช้กับสิ่งที่มีประโยชน์กว่า และกระบวนการ CVE ที่อาศัย bug bounty กับ crowdsourcing ทั้งหมดก็ถูกบั่นทอนเพราะอัตราส่วนสัญญาณต่อสัญญาณรบกวนลดลง
  ผลคือมีแนวโน้มสูงขึ้นที่จะยกระดับกำแพงการส่งข้อมูลเพื่อรับมือสแปม ซึ่งอาจนำไปสู่การพบบั๊กและแก้บั๊กลดลง ช่องโหว่ด้านความปลอดภัยเพิ่มขึ้น และปัญหาทั้งหมดที่ตามมา
  พลวัตแบบเดียวกันยังเกิดขึ้นในด้านอื่น ๆ ได้ด้วย ทำให้เราให้ความเชื่อถือกับรีวิวสินค้า เอกสารยื่นต่อศาล สูตรอาหาร คู่มือการใช้งาน คำแนะนำทางการแพทย์ และอื่น ๆ ได้น้อยลงเรื่อย ๆ
  หนึ่งในคำมั่นของอินเทอร์เน็ตคือการขยายคอนเทนต์อย่างรวดเร็วผ่านการทำให้การเผยแพร่เป็นประชาธิปไตย แต่ดูเหมือนเรากำลังเห็นแม้แต่ข้อดีที่เหลืออยู่ก็ถูก คว้านไส้จากข้างใน

• การตั้งประเด็นเรื่อง การตรวจสอบขอบเขตความยาว ตรงนี้แปลกเป็นพิเศษ
  เพราะไม่มีการใช้ข้อมูลที่ผู้ใช้ป้อนเข้ามาเลย และทุกขนาดเป็นค่าคงที่แบบ static ณ เวลา compile
  curl ใส่สตริงสุ่มขนาด 16 ไบต์ที่เข้ารหัสเป็น base64 ซึ่งก็คือ ASCII 25 ไบต์รวมกับอักขระปิดท้าย null \0 ลงในบัฟเฟอร์ static ขนาด 40 ไบต์

  https://github.com/curl/curl/blob/1d8e8c9ad1ff3351386422535f...

และถ้าถามด้วยความสงสัยล้วน ๆ คนที่รู้ C ดีกว่าผมช่วยอธิบายได้ไหมว่าทำไมตรงนี้ถึงใช้ตัวแปรโลคัล keyval
ทำไมไม่ตั้งค่าเป็น heads[3].val = randstr แล้วค่อย free() หลังจากจัดการข้อมูล header เสร็จ
แล้วทำไม keyval ถึงเป็น 40 ไบต์ ไม่ใช่ 26 หรือ 32 ไบต์

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

• ถ้าจะทำแบบนั้น ก็ตัดทั้ง randstr และ keyval ออก แล้ว encode ลงใน &heads[3].val โดยตรงเลยก็ได้ เพราะยังไงก็ allocate อยู่แล้ว
  ถึงอย่างนั้นก็ยังต้องส่ง randlen ที่ไร้ประโยชน์เข้าไป ไม่งั้นจะ crash
  ช่างเป็นความงดงามแบบ output parameter ของ C จริง ๆ
  ท่าเต้น “คัดลอกจาก heap ไปยังตัวแปรบน stack” นี้ไม่ได้ช่วยลดงาน cleanup ด้วย
  เพราะหลัง encode แล้วมีจุด return เพียงจุดเดียวเท่านั้น
  แต่ถ้าจัดตัวแปรที่ต้องใช้ไว้ด้านบนก่อน แล้วค่อยเพิ่งรู้ทีหลังว่า Curl_base64_encode allocate เสมอ ก็พอเข้าใจได้ว่าโค้ดปัจจุบันออกมาแบบนี้ได้อย่างไร

• การใช้ stack แทบจะฟรี เพราะมีการจองพื้นที่ไว้แล้วตอนตั้งค่าฟังก์ชัน และถูกเก็บกวาดอัตโนมัติเมื่อฟังก์ชัน return
  การใช้ heap ต้องทำงานมากกว่า อาจล้มเหลวได้ และต้อง cleanup เอง

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

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

• ถ้าไม่น่าหงุดหงิดและไม่เสียเวลา สถานการณ์ที่ dineshsec / dinesh_b พยายามสอน Daniel ว่าใช้ strncpy อย่างไรคงจะตลกดี
  ก่อนอื่นก็แท็ก Daniel ด้วย handle ที่มั่วขึ้นมา แล้วต่อด้วย “โค้ดที่เป็นปัญหามีดังนี้:” พร้อมสร้างโค้ดที่ไม่มีอยู่จริงขึ้นมา

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

• ไม่ควรใช้ strcpy หรือ strncpy แต่ควรใช้ memcpy เฉย ๆ
  โดยเฉพาะ strncpy นั้นเป็นตัวเลือกที่แย่ที่สุดในสามตัวอย่างชัดเจน
  โค้ดรู้อยู่แล้วว่าบัฟเฟอร์ต้นทางมีขนาดเท่าไร และตรวจแล้วด้วยว่าจะใส่ลงบัฟเฟอร์ปลายทางได้หรือไม่ ดังนั้นจึงไม่มีเหตุผลต้องเรียก strcpy ให้มันวัดความยาวสตริงโดยไม่จำเป็น
  พูดตรง ๆ คำแนะนำของ LLM อยู่ในระดับที่ควรห้ามอย่างจริงจัง
  ถ้าไม่รู้ขนาด ไม่สนใจการตัดทิ้งแบบเงียบ ๆ และไม่สนใจประสิทธิภาพ ก็ใช้ snprintf ได้
  strncpy จะเติม 0 ลงในส่วนที่เหลือของบัฟเฟอร์โดยไม่จำเป็น
  ถ้าไม่ได้ทำอะไรประมาณ UI โดยทั่วไปก็ควรต้องใส่ใจเรื่องการถูกตัดทิ้ง และในกรณีแบบนั้น strncpy ก็ช่วยไม่ได้

• ดูเหมือนจะเกี่ยวข้องกับเรื่องนี้: https://news.ycombinator.com/item?id=38840907