Money Tree Browser cung cấp tiền thưởng lỗi cho Chromium

Giới thiệu Chromium Money Tree Browser

• Chromium Money Tree Browser là một trang web liên kết phần thưởng từ Chrome VRP (chương trình tiền thưởng lỗi) với các thay đổi (sửa đổi) trong những tệp cụ thể.
• Trang này được tạo ra rất đơn giản, vì vậy tốt nhất là không nên kỳ vọng vào trải nghiệm người dùng hay độ chính xác của dữ liệu.
• Tiền thưởng lỗi được chia theo từng tệp; ví dụ, nếu để sửa một lỗi trị giá $1000 mà có 5 tệp được thay đổi, thì mỗi tệp sẽ được phân bổ $200.
• Dữ liệu dựa trên thông tin tính đến đầu tháng 11 năm 2023.

Ý kiến của GN⁺

• Chromium Money Tree Browser là một công cụ thú vị giúp các nhà phát triển và nhà nghiên cứu bảo mật hình dung những tệp nào đã được sửa trong chương trình tiền thưởng lỗi của Chrome, và phần thưởng tương ứng đã được phân bổ như thế nào.
• Trang này cung cấp góc nhìn về cách phần thưởng cho các bản sửa lỗi được tính toán, đồng thời có thể hữu ích cho việc chia sẻ thông tin giá trị trong cộng đồng bảo mật.
• Dù nên hạ thấp kỳ vọng về trải nghiệm người dùng hay độ chính xác dữ liệu, trang này vẫn có thể góp phần nâng cao nhận thức về các lỗ hổng bảo mật trong dự án mã nguồn mở và tạo động lực để các nhà phát triển coi trọng bảo mật hơn.

[GN⁺]

Ý kiến trên Hacker News

• Sự hứng thú với một tính năng tương tự thứ mà các nhà phát triển đã muốn xây dựng từ lâu

  • Suy ngẫm về tính hữu ích của một phương pháp tính toán khả năng một thay đổi nhất định có thể gây ra vấn đề, dựa trên các thay đổi đã từng xảy ra trong quá khứ của một tệp hoặc một phần cụ thể của tệp.
  • Gán điểm rủi ro cho từng thay đổi, rồi liên kết điểm này với PR (Pull Request) để báo cho người review code biết phần code nào cần chú ý thêm, đồng thời dùng làm tín hiệu nhấn mạnh các thay đổi rủi ro khi triển khai.
  • Việc theo dõi cùng một phần code khi nó bị dịch chuyển lên xuống do chèn/xóa là khó. Thuật toán chỉ dựa trên số dòng có thể gây vấn đề.
  • Gợi ý rằng chỉ cần làm ở cấp độ tệp cũng có thể đã đủ hữu ích.

• Chỉ ra rằng có vẻ đã bỏ sót các bản sửa trong một số thư viện bên thứ ba

  • Có vẻ một số bản sửa phát sinh trong thư viện bên thứ ba (ví dụ: ffmpeg) đã bị bỏ sót. Những bản sửa như vậy thường được xử lý ở upstream trước nên khó theo dõi.

• Khi xem nhiều lỗi trong UI của trình duyệt Chrome, nảy sinh suy nghĩ về các vấn đề use-after-free trên dữ liệu mà hiệu năng của quản lý bộ nhớ thủ công không thực sự quan trọng

  • Quan sát về các vấn đề use-after-free xảy ra trong những đoạn code như vòng đời của hộp thoại "chọn tệp", dù hiệu năng của quản lý bộ nhớ thủ công trong đó không quan trọng.
  • Gợi ý rằng trong những đoạn code như vậy, có thể luôn tốt hơn nếu dùng các con trỏ thông minh hơn nhưng chậm hơn.
  • Nhắc đến việc các kiểu như raw_ptr<T> dường như được tạo ra để giúp xử lý điều này, và có khả năng đã thực sự ngăn được vụ crash xảy ra ở [2].
  • Đáng tiếc là trong dự án không có cách nào để chuyển đổi giữa các dialect khác nhau cho phần code nhạy cảm về hiệu năng và phần code không cần quá coi trọng hiệu năng.
  • Suy nghĩ về việc liệu có gần như đáng giá khi trộn hai ngôn ngữ khác nhau để phân tách rõ phần nhạy cảm về hiệu năng với phần có nhiều trạng thái bất đồng bộ, nơi rất dễ phát sinh lỗi.

• Khen ngợi hiệu quả của phần trực quan hóa và chỉ ra mức sử dụng CPU

  • Trực quan hóa rất gọn gàng, nhưng đề cập rằng mức sử dụng CPU có phần cao khi mở rộng các vùng.
  • Kỳ vọng rằng đội Chrome có lẽ đang dùng công cụ tương tự nội bộ, và cho rằng nó sẽ hữu ích để hiểu bề mặt tấn công.

• Khen ý tưởng và cách thực thi, đồng thời hỏi về dữ liệu thô

  • Khen rằng ý tưởng rất hay và cách thực hiện cũng tốt.
  • Đề cập đến việc liệu có thể truy cập dữ liệu thô hay không, và liệu có đáng để thử sunburst hoặc tree map không.

• Đề xuất không đưa vào một số loại tệp nhất định

  • Góp ý chi tiết rằng không nên đưa các tệp DEPS, AUTHORS, BUILD.gn vào.

• Đề xuất gán trọng số theo số dòng code đã thay đổi

  • Cho rằng sẽ thú vị nếu gán trọng số cho số "tiền" phân bổ cho lỗi theo số dòng code đã thay đổi.
  • Đề xuất cách tính: nếu 10 dòng ở tệp A và 1 dòng ở tệp B bị thay đổi, thì tệp B sẽ nhận 1/11 số "tiền" vì tệp A chiếm phần lớn của lỗi.

• Yêu cầu tính năng hiển thị phần thưởng trung bình theo từng tệp

  • Yêu cầu có tính năng hiển thị phần thưởng trung bình theo từng tệp trên mỗi node.

• Ý tưởng về phiên bản hiển thị số tiền đã được chuẩn hóa theo số dòng code

  • Đề xuất một phiên bản hiển thị số tiền sau khi chuẩn hóa theo số dòng code.

• Khen ngợi hiểu biết trực quan về những khu vực cần tập trung nỗ lực

  • Đánh giá rằng việc cung cấp hiểu biết trực quan về nơi nên tập trung nỗ lực là rất tuyệt.