Money Tree Browser ที่มอบเงินรางวัลบั๊กของ Chromium

 (lyra.horse)
2 คะแนน โดย GN⁺ 2024-01-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

แนะนำ Chromium Money Tree Browser

  • Chromium Money Tree Browser เป็นเว็บไซต์ที่เชื่อมโยงรางวัลจาก Chrome VRP (โปรแกรมเงินรางวัลบั๊ก) เข้ากับการเปลี่ยนแปลง (การแก้ไข) ของไฟล์เฉพาะ
  • เว็บไซต์นี้สร้างขึ้นอย่างเรียบง่ายมาก และไม่ควรคาดหวังประสบการณ์ผู้ใช้หรือความแม่นยำของข้อมูลมากนัก
  • เงินรางวัลบั๊กจะถูกแบ่งตามไฟล์ ตัวอย่างเช่น หากการแก้บั๊กมูลค่า $1000 มีการเปลี่ยนแปลงไฟล์ 5 ไฟล์ แต่ละไฟล์จะได้รับการจัดสรร $200
  • ข้อมูลอ้างอิงจากข้อมูลจนถึงช่วงต้นเดือนพฤศจิกายน 2023

ความเห็นของ GN⁺

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

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

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

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

  • ความสนใจต่อสิ่งที่คล้ายกับฟีเจอร์ที่นักพัฒนาอยากสร้างมานาน

    • มีการพิจารณาถึงประโยชน์ของวิธีคำนวณความเป็นไปได้ที่การเปลี่ยนแปลงที่กำหนดจะก่อปัญหา โดยอิงจากการเปลี่ยนแปลงในอดีตที่เกิดขึ้นกับไฟล์หรือบางส่วนของไฟล์
    • ให้คะแนนความเสี่ยงกับการเปลี่ยนแปลงแต่ละรายการ แล้วเชื่อมคะแนนนี้เข้ากับ PR (Pull Request) เพื่อบอกผู้รีวิวโค้ดว่าจุดใดต้องระวังเป็นพิเศษ และใช้เป็นสัญญาณเน้นการเปลี่ยนแปลงที่เสี่ยงตอน deploy
    • การติดตามส่วนของโค้ดเดิมเมื่อโค้ดถูกเลื่อนขึ้นหรือลงเพราะมีการแทรก/ลบ เป็นเรื่องยาก อัลกอริทึมที่อิงแค่เลขบรรทัดอาจมีปัญหา
    • ชี้ให้เห็นว่าแม้ทำงานในระดับไฟล์อย่างเดียวก็อาจมีประโยชน์มากพอแล้ว

  • การชี้ว่ามีแพตช์บางส่วนในไลบรารี third-party ที่หายไป

    • ดูเหมือนว่าจะมีแพตช์บางส่วนในไลบรารี third-party (เช่น ffmpeg) ที่ตกหล่นไป แพตช์เหล่านี้มักถูกจัดการ upstream ก่อน ทำให้ติดตามได้ยาก

  • การดูบั๊กจำนวนมากใน Chrome UI และตั้งข้อสังเกตเรื่องปัญหา use-after-free กับข้อมูลที่ประสิทธิภาพของการจัดการหน่วยความจำแบบแมนนวลไม่ได้สำคัญนัก

    • มีข้อสังเกตเกี่ยวกับปัญหา use-after-free ที่เกิดขึ้นในโค้ดอย่างวงจรชีวิตของกล่องโต้ตอบ "เลือกไฟล์" ทั้งที่ประสิทธิภาพของการจัดการหน่วยความจำแบบแมนนวลในโค้ดลักษณะนี้ไม่ได้สำคัญมาก
    • ชี้ว่าในโค้ดประเภทนี้ การใช้ pointer ที่ฉลาดกว่าแต่ช้ากว่าเสมออาจดีกว่า
    • มีการกล่าวถึงว่าประเภทอย่าง raw_ptr<T> ดูถูกออกแบบมาเพื่อช่วยเรื่องนี้ และอาจป้องกัน crash ที่เกิดใน [2] ได้สำเร็จจริง
    • มีความเสียดายที่ในโปรเจ็กต์ไม่มีวิธีสลับไปใช้คนละ dialect ระหว่างโค้ดที่ไวต่อประสิทธิภาพกับโค้ดที่ไม่จำเป็นต้องกังวลเรื่องประสิทธิภาพมากนัก
    • มีการตั้งคำถามว่าการผสมสองภาษาที่ต่างกันเพื่อแยกส่วนที่ไวต่อประสิทธิภาพออกจากส่วนที่มี async state มากและมีโอกาสผิดพลาดสูง จะคุ้มค่าหรือไม่

  • คำชมต่อประสิทธิผลของการทำภาพข้อมูลและข้อสังเกตเรื่องการใช้ CPU

    • เป็นการทำภาพข้อมูลที่เรียบร้อยมาก พร้อมระบุว่าเมื่อขยายพื้นที่ดู การใช้ CPU ค่อนข้างสูง
    • คาดว่าทีม Chrome น่าจะมีเครื่องมือคล้ายกันใช้ภายใน และเห็นว่าน่าจะมีประโยชน์ต่อการทำความเข้าใจ attack surface

  • คำชมต่อไอเดียและการลงมือทำ พร้อมสอบถามเรื่องข้อมูลดิบ

    • ชื่นชมว่าไอเดียน่าสนใจและทำออกมาได้ดี
    • มีการถามว่าสามารถเข้าถึงข้อมูลดิบได้หรือไม่ และกล่าวถึงความคุ้มค่าของการลองทำแบบ sunburst หรือ tree map

  • ข้อเสนอว่าไม่ควรรวมไฟล์บางประเภท

    • มีข้อเสนอเชิงรายละเอียดว่าไม่ควรรวมไฟล์ DEPS, AUTHORS, BUILD.gn

  • ข้อเสนอให้ถ่วงน้ำหนักตามจำนวนบรรทัดโค้ดที่เปลี่ยน

    • มีความเห็นว่าน่าสนใจหากถ่วงน้ำหนัก 'เงิน' ที่จัดสรรให้บั๊กตามจำนวนบรรทัดโค้ดที่เปลี่ยน
    • หากไฟล์ A เปลี่ยน 10 บรรทัดและไฟล์ B เปลี่ยน 1 บรรทัด ก็เสนอให้ไฟล์ A ได้รับ 'เงิน' 1/11 เนื่องจากเป็นส่วนหลักของบั๊ก

  • คำขอฟีเจอร์แสดงรางวัลเฉลี่ยรายไฟล์

    • มีการขอฟีเจอร์ที่แสดงรางวัลเฉลี่ยรายไฟล์ในแต่ละโหนด

  • ไอเดียการแสดงจำนวนเงินแบบ normalized ตามจำนวนบรรทัดโค้ด

    • มีข้อเสนอเกี่ยวกับเวอร์ชันที่แสดงจำนวนเงินแบบ normalized ตามจำนวนบรรทัดโค้ด

  • คำชมต่อข้อมูลเชิงภาพที่ช่วยชี้ว่าควรโฟกัสความพยายามตรงไหน

    • มีการประเมินว่ายอดเยี่ยมมากที่ให้ข้อมูลเชิงภาพว่าควรทุ่มความพยายามไปที่จุดใด