ถ้าคุณทำให้เราเสียเวลากับรายงานไร้ประโยชน์ เราจะแบนคุณและเยาะเย้ยคุณต่อสาธารณะ

 (curl.se)
3 คะแนน โดย GN⁺ 2026-01-23 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • เนื้อหาที่ระบุไว้ใน /.well-known/security.txt ของโครงการโอเพนซอร์ส curl
  • รับรายงานปัญหาด้านความปลอดภัยที่พบในผลิตภัณฑ์ของตนเอง แต่ ไม่มีการมอบรางวัลเป็นเงินหรือผลตอบแทนในรูปแบบใด ๆ สำหรับปัญหาที่ถูกรายงาน
  • แต่สำหรับปัญหาที่ยืนยันแล้ว จะมีการ แสดงคำขอบคุณและให้เครดิตในเอกสาร
  • หากทำให้เสียเวลาด้วย รายงานที่หละหลวมหรือไร้ความหมาย จะมีการเตือนว่าอาจถูก เยาะเย้ยต่อสาธารณะและถูกแบน
  • ใช้ รูปแบบมาตรฐาน security.txt ที่สรุปสาระสำคัญของนโยบายการรายงานด้านความปลอดภัยอย่างกระชับ

นโยบายการรายงานด้านความปลอดภัยของโครงการ curl

  • โครงการโอเพนซอร์ส curl รับรายงานปัญหาด้านความปลอดภัยของผลิตภัณฑ์ที่สร้างโดยโครงการ curl
    • สามารถส่งรายงานได้ทางอีเมล (security@curl.se) หรือผ่านหน้า GitHub Security Advisory
  • ระบุอย่างชัดเจนว่า ไม่มีนโยบายให้รางวัล และไม่มีการมอบรางวัลเป็นเงินหรือในรูปแบบอื่นใด
    • แต่สำหรับปัญหาที่ยืนยันแล้ว จะมี การแสดงคำขอบคุณและให้เครดิต ในเอกสารที่เกี่ยวข้อง

คำเตือนต่อรายงานที่ไม่เหมาะสม

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

ขั้นตอนการรายงานด้านความปลอดภัยและข้อมูลทางการ

  • ช่องทางติดต่อ: อีเมล (security@curl.se) และหน้า GitHub Security Advisory
  • เอกสารนโยบาย: เปิดเผยที่ https://curl.se/dev/vuln-disclosure.html
  • หน้าคำขอบคุณ: ดูได้ที่ https://curl.se/docs/security.html
  • ภาษาที่ต้องการ: อังกฤษ (en)
  • วันหมดอายุนโยบาย: ระบุเป็นวันที่ 22 ตุลาคม 2026
  • URL ทางการ: https://curl.se/.well-known/security.txt

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

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

 
slowandsnow 2026-01-24

ดูเหมือนว่าทางออกคือปิดหน้า GitHub Issues ไปเลย เพราะมีการเปิดอิชชูแบบสะเปะสะปะไม่เลือกหน้า
 
skageektp 2026-01-23

ก็แอบคิดอยู่เหมือนกันนะว่า การเยาะเย้ยกันต่อหน้าสาธารณะนี่ไม่ผิดกฎหมายเกาหลีเหรอ 555
 
GN⁺ 2026-01-23
ความคิดเห็นจาก Hacker News

  • ไม่นานมานี้เห็นข่าวว่า cURL ยกเลิกโครงการ bug bounty ไปแล้ว เพราะมีรายงานบั๊กปลอมที่สร้างโดย AI ถาโถมเข้ามา
    บทความที่เกี่ยวข้อง: เธรดบน Hacker News, รายงานจาก ETN

    • ถ้ามีทั้งรายงาน แพตช์ และ test case มาครบถ้วนจริง ๆ ต่อให้สร้างด้วย AI ผมก็คิดว่ายังมีค่าพอจะให้รางวัล

  • เริ่มรู้สึกแล้วว่ายุค AI เปิดฉากอย่างจริงจังแล้ว

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

  • คิดว่าโมเดลการเผยแพร่โอเพนซอร์ซได้กลายเป็นโครงสร้างที่ ไม่ยั่งยืน ไปแล้ว
    เดิมทีขบวนการซอฟต์แวร์เสรีมีเป้าหมายเพื่อรับประกันเสรีภาพของผู้ใช้ในการแก้ไขและพัฒนาซอฟต์แวร์ด้วยตัวเอง
    แต่ตอนนี้กลับเกิดวัฒนธรรมที่คาดหวังฟรี ๆ ทั้ง issue tracker, การรีวิว PR, การซัพพอร์ตทางอีเมล ไปจนถึง security patch
    สิ่งเหล่านี้จริง ๆ แล้วเป็นงาน ซัพพอร์ตแบบมีค่าใช้จ่าย และถ้าไม่ใช่งานอดิเรกก็ย่อมต้องมีค่าตอบแทน

    • เมื่อก่อนเคยทำ static site generator ง่าย ๆ ด้วย HapiJS แล้วเอาขึ้น GitHub พอมันถูกแชร์บน Reddit ก็มีทั้ง PR, bug report และคำด่าถาโถมเข้ามา
      ทั้งที่บอกชัดแล้วว่า “ไม่ได้คิดจะซัพพอร์ต” ก็ยังโดนโจมตีไม่หยุด และนั่นก็กลายเป็น โปรเจกต์ OSS แรกและสุดท้ายของผม
    • ลองจินตนาการถึงระบบที่ผู้ใช้สามารถตั้ง เงินรางวัลเล็ก ๆ ให้กับฟีเจอร์ที่อยากได้
      ถ้ามีผู้ใช้หลายคนต้องการฟีเจอร์เดียวกัน กองรางวัลก็จะใหญ่ขึ้น และนักพัฒนาก็เลือกงานนั้นไปทำ
      ทั้งผู้จัดการโครงการและผู้ทดสอบก็รับส่วนแบ่งตามสัดส่วน เป็นโครงสร้างที่ทุกฝ่ายมีแรงจูงใจ
    • ผมไม่เห็นด้วยกับคำพูดที่ว่าผู้ก่อตั้งโอเพนซอร์ซไม่ได้ตั้งใจให้เป็นแบบนี้
      “Bazaar model” ของ Eric S. Raymond และ “กฎของ Linus (คนยิ่งเยอะ บั๊กยิ่งตื้น)” ต่างก็ตั้งอยู่บนสมมติฐานของการร่วมมือกันอย่างเปิดเผยโดยตรง
    • ผมไม่เห็นด้วยกับมุมมองที่มองนักพัฒนา FOSS เป็นเหยื่อ
      คุณแค่ต้องกำหนด ขอบเขตและกฎเกณฑ์ เอง แล้วบล็อกคนที่เสียมารยาทก็พอ
    • การร่วมมือกันผ่าน issue tracker สาธารณะอย่าง GitHub ได้กลายเป็น วัฒนธรรมพื้นฐานของโอเพนซอร์ซ มาสองยุคคนแล้ว

  • ช่วงนี้ผมกำลังช่วย โครงการเอกสารของ OWASP อยู่ และมีนักเรียนอินเดียส่ง PR กับ issue แปลก ๆ ที่สร้างด้วย LLM เข้ามาเป็นจำนวนมาก
    ผมเลยเสนอว่าควรใช้โครงสร้างแบบ Ghostty ที่ให้เริ่มจาก ‘Discussion’ ก่อน แล้วมีแค่ issue ที่ผู้ดูแลอนุมัติเท่านั้นที่แปลงเป็น PR ได้

    • ผมเคยเห็นวัฒนธรรมแบบ ‘fake it till you make it’ ที่นักพัฒนาอินเดียหลีกเลี่ยงการถาม แล้วเดินหน้าต่อไปเลย
    • นักเรียนจำนวนมากส่ง PR ที่เป็นโค้ดจาก LLM เพื่อเอา กิจกรรมบน GitHub ไปใส่เรซูเม่ แต่พอขอให้แก้ไขกลับไม่เข้าใจเลยว่าต้องทำอะไร
      อย่างที่ Torvalds พูดไว้ ผมว่าด้วย LLM แล้ว การดูแลรักษาโค้ดจะกลายเป็นฝันร้ายแน่ ๆ
    • พอมี PR ไร้สาระแบบนี้เยอะขึ้น การหาประเด็นจริงก็ยิ่งยากขึ้น
    • ผมคิดว่าเหตุผลหนึ่งที่ Stack Overflow เสื่อมลง ก็เพราะการ ระเบิดของคำถามคุณภาพต่ำ

  • ครั้งหนึ่งผมเคยส่ง bug report แต่โดน ด่าอย่างหนัก บน Reddit เพราะข้อมูลการทำซ้ำไม่พอ
    หลังจากนั้นผมก็แทบเลิกเล่นโซเชียลมีเดียไปเลย

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

  • ถ้าจะจัดการปัญหา Eternal September กับปัญหาคอนทริบิวต์คุณภาพต่ำที่ LLM สร้างขึ้น ผมกลับคิดว่าจำเป็นต้องมี แรงเสียดทาน (friction) ที่เพิ่มกำแพงทางเข้า
    ตัวอย่างเช่น ให้ผู้มีส่วนร่วมครั้งแรกต้องส่ง รายงานผ่านไปรษณียบัตรที่มี QR code อะไรประมาณนั้น

    • แต่แรงเสียดทานแบบนี้อาจไม่ได้ผล เพราะบ่อยครั้ง พวกสแปมคอนทริบิวต์กลับทนกับมันได้ดีกว่าผู้มีส่วนร่วมจริง

  • ถ้าโปรเจกต์ต้องจมอยู่กับ PR ที่เต็มไปด้วยอีโมจิและข้อผิดพลาด แบบนั้น Bazaar model ก็ยิ่งทำงานได้ยาก

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

  • ทำให้นึกถึงสมัยที่ The Pirate Bay เคยเผยแพร่อีเมลข่มขู่ทางกฎหมายจาก MPAA ต่อสาธารณะ
    ร่องรอยนั้นยังดูได้ใน หน้าตอบโต้ทางกฎหมายของ TPB (เว็บอาร์ไคฟ์)
    วิธีของพวกเขาอาจไม่ได้ผลนัก แต่ก็ยังเหลือไว้ในฐานะ สัญลักษณ์ของการต่อต้าน

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

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

  • ผมคิดว่า GitHub ควรมี คะแนนความน่าเชื่อถือหรือระบบชื่อเสียง ให้ผู้ใช้

    • แต่ GitHub ก็อยู่ใน ฝ่าย AI ของ Microsoft (Microsoft CoreAI) ดังนั้นมีโอกาสมากที่พวกเขาจะยิ่งสนับสนุนพฤติกรรมแบบนี้
      บทความที่เกี่ยวข้อง: รายงานจาก GeekWire
    • การที่ Microsoft จะมาให้ คะแนนทางสังคม กับนักพัฒนาเป็นความคิดที่น่ากลัวมาก
    • ผมกลับมองว่าการทำให้ผู้ใช้ไม่ระบุตัวตนน่าจะดีกว่า เพื่อ ลดแรงจูงใจในการไล่ล่าชื่อเสียง
    • แม้แต่แพลตฟอร์มอย่าง HackerOne ก็มีระบบชื่อเสียง แต่ รายงานคุณภาพต่ำ ก็ยังล้นอยู่ดี
      สุดท้ายบริษัทต่าง ๆ ก็ต้องจ่ายเงินใช้บริการ คัดกรองเบื้องต้น (triage)
      ระหว่างทางก็มักมีคนที่ไม่ใช่ผู้เชี่ยวชาญตัวจริงมาตอบก่อน ทำให้รายงานจริงถูกจัดการช้าลงด้วย
      สถานการณ์ตอนนี้เป็น โครงสร้างที่แย่สำหรับทุกฝ่าย และกำลังแย่ลงเรื่อย ๆ