- Việc bảo trì curl đã trở thành công việc toàn thời gian kết hợp giữa giá trị công ích, thách thức kỹ thuật và mục tiêu chất lượng, và đã kéo dài ở mức khoảng 50 giờ mỗi tuần
- curl là thư viện và công cụ truyền tải có cơ sở cài đặt khoảng 30 tỷ bản, nên áp lực rất lớn vì không được để các thất bại bảo mật lan tới người dùng
- Hiện tốc độ báo cáo bảo mật đổ vào cao hơn 4~5 lần so với năm 2024, gấp đôi năm 2025, và trung bình hơn một báo cáo mỗi ngày nên cần xử lý ngay lập tức
- Công việc xử lý bảo mật bao gồm xác minh tuyên bố, đánh giá mức độ nghiêm trọng, viết bản vá, xác định thời điểm được đưa vào, viết khuyến cáo và trao đổi với nhà nghiên cứu cùng đội bảo mật
- Trước bản phát hành sắp tới đã có 12 lỗ hổng đã được xác nhận đang chờ xử lý, cho thấy giới hạn của hỗ trợ về tài chính và nhân lực ngay cả khi phải chịu áp lực chưa từng có
Trách nhiệm với curl và bảo trì dài hạn
- Công việc mã nguồn mở không phải để kiếm tiền hay theo đuổi cuộc sống hào nhoáng, mà được tiếp tục vì ý nghĩa xã hội, lợi ích công cộng và thách thức kỹ thuật để làm cho mọi thứ vận hành cho tất cả mọi người
- Công việc với curl đã trở thành toàn thời gian từ năm 2019, thường tiêu tốn khoảng 50 giờ mỗi tuần, kéo dài cả ban ngày lẫn đêm muộn, ngày thường lẫn cuối tuần
- Mục tiêu của curl là trở thành thư viện và công cụ truyền tải tốt nhất có thể, đồng thời là một dự án hàng đầu về chất lượng, hiệu năng và bảo mật trong thế giới mã nguồn mở
- curl không phải dự án của riêng một người, và sẽ không có curl như hôm nay nếu không có các thành viên trong nhóm, nhưng nhiều người vẫn gắn curl rất mạnh với cá nhân Daniel Stenberg
- Những lời chỉ trích nhắm vào curl được cảm nhận như lời chỉ trích nhắm vào các quyết định và lựa chọn mà chính mình đã ủng hộ hoặc trực tiếp đưa ra, và curl đã trở thành một dự án cá nhân làm thay đổi cuộc đời vĩnh viễn
- Cuối năm 2026, dự án curl sẽ kỷ niệm 30 năm, và số lượt cài đặt curl trên toàn thế giới được nhắc tới ở mức khoảng 30 tỷ
Sự thay đổi của môi trường báo cáo bảo mật
- Trong vài năm gần đây, môi trường báo cáo bảo mật của curl đã chuyển từ sự khó chịu với LLM ngu ngốc sang báo cáo AI rác, kết thúc chương trình bug bounty, rồi tới sự hỗn loạn chất lượng cao bắt đầu khoảng tháng 3/2026
- Mỗi khi các thất bại bảo mật lớn lặp lại trong sản phẩm Internet, hạ tầng phần mềm và mã nguồn mở, áp lực lại tăng lên vì curl hiện diện ở khắp nơi, và những chuyện như vậy không được phép xảy ra với curl hay người dùng của nó
- Dự án curl đã từng bước giảm khả năng để lọt hoặc chìm các lỗi bằng cách bổ sung thêm kiểm tra, thử nghiệm và hướng dẫn
Mức xác minh cao nhưng rủi ro vẫn còn
- Sau sự việc Mythos chỉ tìm thấy một vấn đề mức độ thấp trong lần quét đầu tiên, nhận định rằng curl là một trong những phần mã được rà soát, fuzzing và xác minh nhiều nhất ở mức có thể tưởng tượng được đã liên tục được nhắc lại
- Tình trạng này không phải ngẫu nhiên hay may mắn, mà là kết quả của hàng chục năm làm việc bền bỉ, chú ý đến chi tiết và cải tiến lặp lại không ngừng
- Việc được rà soát và xác minh nhiều không có nghĩa là không có bug hay vấn đề bảo mật; curl là hàng trăm nghìn dòng mã C thực hiện mạng song song ở mức cao trên nhiều giao thức, hệ điều hành và kiến trúc CPU
- Mỗi khi vấn đề được phát hiện, quy trình sửa lỗi và phát hành bản vá lại tiếp diễn
- Cơ sở cài đặt toàn cầu khoảng 30 tỷ bản có nghĩa là curl rất có thể xuất hiện nhiều lần trong điện thoại, máy tính bảng, ô tô, TV, máy in, máy chơi game và thiết bị nhà bếp
- Trước đây, các dự án từng khiến cả thế giới chao đảo vì bug lớn sẽ thu hút sự chú ý, và một số đã nhận được tài trợ cùng nhân lực để thuê nhiều kỹ sư toàn thời gian
Lượng báo cáo bảo mật chưa từng có
- Hiện tốc độ báo cáo bảo mật đổ vào cao hơn 4~5 lần so với năm 2024, gấp đôi năm 2025, và trung bình nhận hơn một báo cáo mỗi ngày
- Chất lượng báo cáo hiện cao hơn rất nhiều so với trước đây, và phần lớn được viết rất chi tiết, rất dài
- Vì báo cáo tiếp tục đổ đến nên phải xử lý chúng gần như ngay khi nhận được; nếu không xử lý với tốc độ tương đương tốc độ đổ vào, danh sách vấn đề bảo mật tiềm ẩn sẽ tiếp tục chồng chất
- Một danh sách vấn đề bảo mật tiềm ẩn không thể kiểm soát tạo ra gánh nặng tinh thần
- Hiện phần lớn thời gian được dùng để xử lý danh sách các vấn đề bảo mật được báo cáo trên HackerOne
- Các công việc chính gồm xác minh tuyên bố, đánh giá mức độ nghiêm trọng, viết bản vá, xác định thời điểm bug được đưa vào, hiểu lỗ hổng, viết khuyến cáo bảo mật chi tiết, và giao tiếp với các nhà nghiên cứu bảo mật cũng như đội bảo mật curl
Áp lực lên sức khỏe và cả nhóm
- Lần đầu tiên, người bạn đời đã lo ngại về thời gian làm việc và tình trạng mất cân bằng giữa công việc với cuộc sống, và những người xung quanh cũng lo về việc làm sao có thể chịu nổi lượng đổ vào khổng lồ này cùng nguy cơ kiệt sức
- Mối lo cho các thành viên trong nhóm cũng tăng lên, và có thể sắp phải giảm thời gian làm việc để có khoảng nghỉ thở trong thời gian tới
- Tình hình hiện tại là áp lực mà dự án curl và các thành viên đội bảo mật chưa từng trải qua trước đây
- Xử lý vấn đề bảo mật là công việc ưu tiên rất cao, vượt lên trên mọi việc khác của dự án, và không thể bỏ qua vì tinh thần trách nhiệm, lương tâm và niềm tự hào với công việc
- Vì curl là phần mềm được triển khai trên các thiết bị toàn cầu, cảm giác nghĩa vụ phải sửa các vấn đề bảo mật bên trong nó là rất mạnh
- Trước bản phát hành sắp tới, khi chu kỳ phát hành mới đi được khoảng một nửa, đã có 12 lỗ hổng đã được xác nhận, tức là 12 công bố CVE đang chờ
- Đây là kỷ lục mới của dự án, và cũng có nghĩa năm 2026 sẽ chạm mốc 30 CVE công khai trước cả khi đi qua nửa năm
- Nếu xu hướng này tiếp diễn, tổng số CVE của curl được công bố trong cả năm 2026 được dự đoán sẽ ít nhất gấp đôi con số đó
Hỗ trợ cần thiết và những giới hạn mang tính cấu trúc
- Trong ngắn hạn, khối lượng việc đã quá lớn nên đã ở vào tình trạng quá muộn để nhận trợ giúp ngay lập tức
- Nếu nhiều công ty đang sử dụng và phụ thuộc vào curl hoặc libcurl trong phần mềm và dịch vụ thương mại tài trợ thêm, có thể trả chi phí cho nhiều nhà phát triển hơn để chia sẻ khối lượng công việc
- Một con đường hỗ trợ khác là thông qua các hợp đồng hỗ trợ để người sử dụng lao động thanh toán chi phí
- Đã có những khách hàng hỗ trợ theo cách này, nhờ đó một số thành viên có thể làm việc toàn thời gian với curl
- Tuy vậy, không có nhiều kỳ vọng rằng thay đổi có ý nghĩa trong lĩnh vực này sẽ sớm xảy ra, và ngay cả trong tình huống chưa từng có cùng giai đoạn khó khăn hơn, cuối cùng có lẽ vẫn phải tự mình đi qua cơn bão
- Dự án curl không thuộc sở hữu của công ty nào và cũng không nằm dưới bất kỳ tổ chức bảo trợ nào
- Cấu trúc này đôi khi khiến tài nguyên trở nên thiếu hụt, nhưng đồng thời cũng đem lại mức tự do và linh hoạt tối đa
- Tiêu chuẩn hành động của dự án là làm cho curl tốt nhất có thể vì thế giới và vì những người dùng curl
Mặt tích cực và tình trạng hiện tại
- Việc sửa bug và vấn đề tự nó đã là điều tốt, và mỗi vấn đề được báo cáo đồng nghĩa với một vấn đề sẽ được sửa
- Càng nhiều báo cáo, curl càng trở thành sản phẩm tốt hơn
- Các lỗ hổng curl được phát hiện trong vài năm gần đây đều được đánh giá ở mức LOW hoặc MEDIUM, và gần như không có lỗ hổng cực kỳ nghiêm trọng nào được tìm thấy
- Điều đó không có nghĩa là sẽ không còn xuất hiện mức HIGH trong tương lai, nhưng ít nhất hiện tại đó là trạng thái hiếm gặp
- CVE curl có mức độ nghiêm trọng cao gần đây nhất là CVE-2023-38545, được công bố vào tháng 10/2023
- Hiện đội curl đang chịu áp lực và đôi khi có thể phản hồi chậm
1 bình luận
Ý kiến trên Lobste.rs
Mong Daniel và những người khác vượt qua tình huống khó khăn này mà không gây ảnh hưởng xấu lớn đến sức khỏe hay gia đình
Tuy vậy, diễn biến của chuyện này có lẽ sẽ khá thú vị. Đây không phải lần đầu một phương pháp phân tích tự động mới đột nhiên tìm ra nhiều lỗ hổng trong nhiều dự án FOSS, và lúc này có cảm giác khá giống khi greybox fuzzing xuất hiện vào thập niên 2010. Có vẻ có ba khả năng: A) các nhà phát triển đưa LLM vào quy trình nghiên cứu bảo mật, số lỗ hổng mới mà LLM tìm được giảm mạnh, còn các lỗ hổng nằm ngoài tầm với của LLM vẫn tiếp tục được tìm thấy, giống kịch bản của fuzzer. B) giống A nhưng sau khi LLM quét qua thì việc tìm lỗ hổng gần như dừng hẳn, tức kịch bản “LLM giải quyết xong nghiên cứu bảo mật”. C) ở các dự án lớn như curl, lỗ hổng vẫn tiếp tục được phát hiện với tỷ lệ cao, và số lỗi trong các dự án hàng trăm nghìn dòng mã về thực chất là vô hạn, tức kịch bản “sự báo thù của Tony Hoare”
Một ảnh chụp của một codebase cụ thể chỉ có thể chứa hữu hạn lỗi bảo mật. Khi không gian tìm kiếm lỗi bảo mật bị vét cạn, làn sóng này sẽ lắng xuống, và sau đó có lẽ chỉ còn dần dần xuất hiện các lỗi đến từ việc merge mã, test harness mới hoặc cải thiện mô hình
Về kịch bản C đối với dự án curl, tôi cho rằng các lỗi được tìm thấy có mức độ nghiêm trọng thấp vì trước đây tiêu chuẩn về kiểm thử bảo mật và các kỹ thuật tìm lỗi truyền thống đã ở mức cao. Điều này cho thấy đầu tư liên tục vào việc tìm lỗi về lâu dài vẫn luôn mang lại kết quả. Dù hôm nay hay trong tương lai dùng phương pháp phát hiện nào cũng vậy
Mượn lời Marcus Hutchins thì “nút thắt chưa bao giờ là việc tìm lỗi, mà là quyết định của tổ chức không đầu tư vào các nhà nghiên cứu bảo mật”. LLM chỉ khiến khoản đầu tư đó rẻ hơn, còn các tổ chức vốn dĩ cũng đã có thể đầu tư nhiều hơn để tìm được nhiều lỗi hơn. Cuối cùng vẫn là quyết định chính sách
Các công ty tạo ra công nghệ LLM đang phá hủy không chỉ thế giới tự nhiên mà cả thế giới phần mềm. Giá phần cứng tăng vọt khiến ngay cả điện toán cá nhân cũng bị đe dọa, và các nhà phát triển mã nguồn mở thiện chí làm vì muốn làm cũng vậy
Có vẻ họ có vô hạn tiền để hạ thấp và làm hỏng các dự án mã nguồn mở do cộng đồng quản lý, nhưng lại hoàn toàn không có tiền để xử lý hậu quả của việc đó, điều này thật thú vị
Tôi cho rằng điều này chứng minh Zig đã đúng. CVE do LLM phát hiện thì cứ mặc kệ, để ai muốn xử lý thì xử lý
Tôi biết đó không hẳn là trọng tâm chính xác, nhưng vấn đề của CVE do LLM tạo ra là bất kỳ ai khác dùng cùng công cụ đó có lẽ cũng có thể tìm ra đúng như vậy. Nếu thực sự phát hiện được vấn đề nghiêm trọng, điều đó có nghĩa là nhiều người hơn có thể dùng nó để tạo ra thứ gì đó gây hại
Tất nhiên điều này không có nghĩa nó áp dụng y hệt cho các vấn đề mức độ thấp hoặc không liên quan bảo mật đang tràn vào curl. Dù vậy, vẫn phải thực sự đánh giá vấn đề nào có mức ưu tiên cao, và như thế lại quay về bước một
Zig vẫn đang được phát triển tích cực, và chẳng hạn mỗi khi cụ thể hóa các tính năng như biên dịch gia tăng hay I/O bất đồng bộ, khả năng cao là vừa đưa thêm lỗi mới vào vừa loại bỏ các lỗi vốn có do triển khai trước đó chưa hoàn thiện
Ở giai đoạn phát triển này, nếu ai đó chạy thứ như Mythos trên Zig với cách tiếp cận kiểu “hãy tìm mọi lỗi và đừng mắc sai lầm nào”, sẽ có một lượng báo cáo khổng lồ đổ ra, nhưng toàn bộ số đó có thể về thực chất là vô dụng đối với chúng tôi. Giá trị chính của báo cáo lỗi lúc này là nó phát tín hiệu rằng có người dùng bị chặn ở một trường hợp sử dụng cụ thể, và nếu quyết định ưu tiên thì chúng tôi có thể gỡ chặn cho người dùng đó
Điều đó không có nghĩa trạng thái này sẽ kéo dài mãi. Nhiều tính năng quan trọng của compiler đang dần hoàn thiện, và khi ổn định thì việc tìm và sửa mọi lỗi sẽ trở thành ưu tiên cao nhất. Đến lúc đó, việc lỗi đã được biết đến sẽ trở nên quan trọng bất kể được phát hiện bằng cách nào, nhưng vấn đề đó sẽ được xử lý vào thời điểm ấy
Trong lúc này, chính sách đơn giản là cấm LLM
Tôi hiểu việc cấm các đóng góp từ LLM nhưng không đồng ý. Lỗ hổng bảo mật vẫn là lỗ hổng bất kể nó được phát hiện bằng cách nào
Tôi cho rằng cách Daniel đang làm là tốt nhất. Sửa những lỗi có thể sửa để người dùng an toàn hơn, đồng thời cho thấy cái giá của việc đó rất lớn và kêu gọi hỗ trợ. Có lẽ ông ấy sẽ không đọc được bình luận này, nhưng tôi cũng muốn ủng hộ và khuyên ông ấy giới hạn khối lượng công việc để ưu tiên sức khỏe thể chất và tinh thần. Phần lớn thế giới sẽ hiểu, và có lẽ chỉ một thiểu số sẽ phàn nàn
Có vẻ ở đây đang thiếu hai điểm cốt lõi. 1) Công ty LLM hay Project Zero không phải là bên đưa lỗi bảo mật đó vào mã. 2) Việc sửa lỗi bảo mật không phải vì công ty LLM hay Project Zero mà là vì người dùng. Khi lỗi bảo mật bị khai thác, người chịu thiệt là người dùng
Đặc biệt với các lỗi do LLM phát hiện, đã có tín hiệu rằng ở nhiều dự án mã nguồn mở, những người khác dùng cùng LLM cũng đang gửi các báo cáo trùng lặp. Vì vậy nếu bên phòng thủ buông tay thì phải giả định rằng bên tấn công cũng sẽ biết về các lỗi do LLM phát hiện
“Tôi ghen tị với những dự án từng phát hành những lỗi khủng khiếp làm cả thế giới bốc cháy trong một thời gian. Họ đã nhận được sự chú ý, và một số đã có được tài trợ và sức mạnh tài chính để có nhân sự và thuê nhiều kỹ sư toàn thời gian. Đôi khi tôi nghĩ có lẽ sẽ tốt hơn nếu chúng tôi cũng từng có một cái như vậy”
Chuyện này cũng xảy ra ở nhiều nơi làm việc. Các đội thất bại thì được bổ sung nhân lực, còn các đội làm tốt thì vì không để xảy ra chuyện tồi tệ nên lại phải làm nhiều việc hơn với ít người hơn
Không rõ có phù hợp với dự án như curl hay không, nhưng liệu đóng băng tính năng trong một khoảng thời gian để chỉ tập trung vào các báo cáo lỗi/CVE đổ vào có giúp ích không?
Nếu tập tính năng đã cố định thì số lỗi/CVE tiềm ẩn là hữu hạn, và khi sửa dần có vẻ sẽ tiến gần về 0
Dù sao cũng chúc họ may mắn. Chắc chắn đây không phải giai đoạn dễ dàng khi phải bảo trì một phần mềm quan trọng đến vậy
Theo thứ tự, tác động tới mức độ hài lòng của nhà phát triển là tăng, giữ nguyên, rồi giảm
Đóng băng tính năng là công cụ tuyệt vời để hoàn tất một bản phát hành cho tốt, nhưng không phải là công cụ tốt để giảm áp lực cho các nhà phát triển tự định hướng công việc của mình