3 điểm bởi GN⁺ 2026-01-23 | 2 bình luận | Chia sẻ qua WhatsApp
  • Nội dung được ghi trong /.well-known/security.txt của dự án mã nguồn mở curl
  • Dự án tiếp nhận các báo cáo về vấn đề bảo mật được phát hiện trong các sản phẩm của mình, nhưng không cung cấp tiền thưởng hay bất kỳ hình thức bồi đáp nào cho các vấn đề được báo cáo
  • Thay vào đó, với các vấn đề đã được xác nhận, dự án sẽ ghi lời cảm ơn và công nhận công lao trong tài liệu
  • Dự án cảnh báo rằng nếu ai đó làm lãng phí thời gian bằng các báo cáo sơ sài hoặc vô nghĩa, họ có thể bị công khai chế giễu và chặn
  • Sử dụng định dạng chuẩn security.txt để tóm tắt ngắn gọn các nội dung cốt lõi của chính sách báo cáo bảo mật

Chính sách báo cáo bảo mật của dự án curl

  • Dự án mã nguồn mở curl tiếp nhận báo cáo về các vấn đề bảo mật trong các sản phẩm do dự án curl tạo ra
    • Có thể gửi báo cáo qua email (security@curl.se) hoặc trang GitHub Security Advisories
  • Dự án nêu rõ không có chính sách thưởng, không cung cấp bồi đáp bằng tiền hoặc bất kỳ hình thức nào khác
    • Thay vào đó, với các vấn đề đã được xác nhận, dự án sẽ ghi lời cảm ơn và công nhận công lao trong các tài liệu liên quan

Cảnh báo đối với các báo cáo không phù hợp

  • Dự án nêu rõ: “Nếu bạn khiến chúng tôi lãng phí thời gian bằng các báo cáo vô dụng, chúng tôi sẽ cấm bạn và công khai chế giễu bạn”
    • Đây là cách diễn đạt cảnh báo rất mạnh nhằm ngăn chặn các báo cáo thiếu chuyên môn hoặc không có căn cứ
    • Nhấn mạnh chất lượng báo cáo và văn hóa báo cáo có trách nhiệm

Quy trình báo cáo bảo mật và thông tin chính thức

2 bình luận

 
slowandsnow 2026-01-24

Có lẽ cách duy nhất là đóng trang GitHub Issues vì những báo cáo được gửi lên một cách vô tội vạ

 
GN⁺ 2026-01-23
Ý kiến trên Hacker News
  • Gần đây tôi thấy tin cURL đã bỏ chương trình bug bounty vì bị ngập trong các báo cáo lỗi giả do AI tạo ra
    Bài liên quan: thảo luận trên Hacker News, bài ETN

    • Nếu báo cáo, bản vá, và cả test case đều được chuẩn bị tử tế thì tôi nghĩ vẫn đáng được thưởng, kể cả nếu nó do AI tạo ra
  • Tôi đang cảm nhận rõ rằng thời đại AI đã thực sự bắt đầu

    • Đây là điều ai cũng đã dự đoán, thậm chí tôi còn ngạc nhiên vì nó bùng lên muộn đến thế
  • Tôi cho rằng mô hình phân phối phần mềm nguồn mở đã trở thành một cấu trúc không bền vững
    Ban đầu phong trào phần mềm tự do là để bảo đảm người dùng có quyền tự sửa và cải thiện phần mềm
    Nhưng giờ đây đã hình thành một văn hóa kỳ vọng miễn phí vào issue tracker, review PR, hỗ trợ qua email, thậm chí cả vá bảo mật
    Thực chất đây là công việc hỗ trợ có trả phí, và nếu không phải sở thích thì cần có đền bù

    • Trước đây tôi từng làm một trình tạo static site đơn giản bằng HapiJS rồi đưa lên GitHub, nhưng khi nó lan sang Reddit thì PR, báo cáo lỗi, và cả lời lăng mạ đổ tới dồn dập
      Dù tôi đã nói rõ là “không có ý định hỗ trợ”, chỉ trích vẫn trút xuống, và đó cũng là dự án OSS đầu tiên lẫn cuối cùng của tôi
    • Tôi hình dung một hệ thống nơi người dùng có thể treo khoản thưởng nhỏ cho tính năng họ muốn
      Nếu nhiều người cùng muốn một tính năng thì quỹ thưởng sẽ tăng lên, và nhà phát triển sẽ chọn việc đó để làm
      PM và tester cũng nhận một tỷ lệ nhất định, tạo ra cấu trúc mà ai cũng có động lực
    • Tôi không đồng ý với ý kiến rằng những người sáng lập nguồn mở không hề định hướng tới mô hình như vậy
      “Mô hình Bazaar” của Eric S. Raymond và “định luật Linus (nhiều con mắt thì lỗi sẽ nông)” đều dựa trên tiền đề cộng tác công khai
    • Tôi phản đối cách nhìn xem các nhà phát triển FOSS như nạn nhân
      Họ có thể tự đặt ra ranh giới và quy tắc, rồi chặn những người bất lịch sự
    • Cộng tác qua issue tracker công khai như GitHub đã trở thành văn hóa nền tảng của nguồn mở suốt hai thế hệ rồi
  • Gần đây tôi đang giúp dự án tài liệu hóa OWASP, và sinh viên Ấn Độ đang đổ lên hàng loạt PR và issue vô nghĩa do LLM tạo ra
    Tôi đề xuất cần một cấu trúc như Ghostty: bắt đầu bằng ‘Discussion’ trước, rồi chỉ những issue được maintainer chấp thuận mới được chuyển thành PR

    • Tôi từng thấy ở các dev Ấn Độ một văn hóa ‘fake it till you make it’: né tránh câu hỏi và cứ làm tiếp
    • Nhiều sinh viên gửi PR bằng code LLM để có hoạt động GitHub cho CV, nhưng khi yêu cầu chỉnh sửa thì họ hoàn toàn không hiểu gì
      Như Torvalds đã nói, nhờ LLM mà việc bảo trì code có vẻ sẽ thành ác mộng
    • Khi các PR vô nghĩa kiểu này tăng lên, việc tìm ra issue thật sẽ trở nên khó hơn
    • Tôi nghĩ một trong những lý do Stack Overflow suy tàn cũng là do câu hỏi chất lượng thấp bùng nổ
  • Có lần tôi gửi một báo cáo lỗi nhưng bị chỉ trích nặng nề trên Reddit vì thiếu thông tin tái hiện
    Sau chuyện đó tôi gần như ngừng hẳn hoạt động trên mạng xã hội

    • Nhóm curl thường lịch sự yêu cầu thêm thông tin, nên nếu bạn không phản hồi đầy đủ thì việc đóng issue là điều dễ hiểu
    • Maintainer phải vật lộn để tìm lỗi thật giữa vô số báo cáo sai
      Cần nhớ rằng chỉ trích là nhắm vào báo cáo chứ không phải vào cá nhân
    • Nhóm curl thực ra còn khá khoan dung, và những lời công kích trên Reddit không liên quan gì đến cộng đồng chính thức
    • Trớ trêu thay, ngay cả phản ứng trong thread này cũng đang nói về những trải nghiệm “không thể tái hiện”
  • Để giải quyết vấn đề đóng góp chất lượng thấp do Eternal September và LLM tạo ra, tôi nghĩ ngược lại cần tăng ma sát (friction) ở đầu vào
    Ví dụ như người đóng góp lần đầu phải gửi báo cáo bằng bưu thiếp có mã QR chẳng hạn

    • Nhưng kiểu ma sát này có thể lại vô tác dụng, vì những người spam đóng góp thường chịu đựng nó giỏi hơn cả người đóng góp thật
  • Khi một dự án phải vùng vẫy trong đống PR đầy emoji và lỗi sai, mô hình Bazaar sẽ ngày càng khó vận hành

    • Tôi nhớ tới định luật Brandolini
      Việc thông tin chưa được kiểm chứng tràn lan không chỉ là vấn đề của nguồn mở mà là vấn đề của toàn xã hội
      Văn hóa của chúng ta vẫn chưa có được hệ miễn dịch trước thông tin giả
  • Nó làm tôi nhớ đến thời The Pirate Bay từng công khai các email đe dọa pháp lý từ MPAA
    Có thể thấy dấu vết đó ở trang phản hồi pháp lý của TPB (web archive)
    Cách làm của họ không hẳn hiệu quả, nhưng đã trở thành một kiểu biểu tượng của sự phản kháng

  • Trong một dự án nguồn mở nổi tiếng do bạn tôi duy trì, sinh viên đại học Trung Quốc nộp báo cáo lỗ hổng bảo mật giả để làm bài tập
    Phần lớn đều không thể tái hiện, nên chỉ làm lãng phí thời gian của maintainer
    Ngoài ra, do khác biệt cấu hình giữa các bản phân phối, đôi khi lỗ hổng thực tế lại phát sinh từ cấu hình gói chứ không phải từ mã upstream
    Ngay cả trên subreddit Kryptos K4 cũng tràn ngập các bài “đã giải được rồi!” do LLM tạo ra, và vi phạm lần đầu là bị ban ngay
    Tôi lo rằng việc gian lận bài tập bằng AI giờ đã lan ra mọi lĩnh vực

    • Là con người, chúng ta không nên đánh mất niềm vui của việc học và trưởng thành
      Dù AI có phát triển đến đâu thì giá trị của tự học vẫn không thể thay thế
    • Với Kryptos K4, dù LLM biết toàn bộ dữ liệu, nó vẫn không đưa ra được bất kỳ ý tưởng mới nào
      Cuối cùng LLM không phải tư duy sáng tạo, mà chỉ là công cụ tự động hoàn thành được tăng cường
    • Ở Trung Quốc, chuyện sinh viên y khoa không tự viết luận văn mà thuê người viết hộ làm ô nhiễm các tạp chí học thuật là khá phổ biến
    • Rốt cuộc, gian lận trong học thuật sẽ chảy ra thị trường, và chừng nào còn động lực tài chính thì chuyện này sẽ không dừng lại
  • Tôi nghĩ sẽ tốt nếu GitHub gán cho người dùng một điểm tin cậy hoặc hệ thống uy tín

    • Nhưng GitHub hiện thuộc bộ phận AI (Microsoft CoreAI), nên rất có thể họ lại khuyến khích kiểu hành vi này
      Bài liên quan: bài GeekWire
    • Ý tưởng Microsoft chấm điểm xã hội cho developer là một điều kinh khủng
    • Ngược lại, tôi nghĩ tốt hơn là ẩn danh hóa người dùng để giảm động cơ theo đuổi danh tiếng
    • Các nền tảng như HackerOne cũng có hệ thống uy tín, nhưng báo cáo chất lượng thấp vẫn tràn lan
      Cuối cùng các công ty lại phải trả tiền cho dịch vụ triage trung gian
      Trong quá trình đó, người phản hồi đầu tiên đôi khi không phải chuyên gia thực sự, khiến báo cáo thật bị xử lý chậm
      Tình hình hiện tại là một cấu trúc tệ cho tất cả mọi người, và đang ngày càng xấu đi