2 điểm bởi GN⁺ 4 giờ trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Dự án mã nguồn mở curl sẽ tạm ngừng tiếp nhận và xử lý báo cáo lỗ hổng trong suốt tháng 7/2026 để bảo đảm thời gian nghỉ ngơi cho các maintainer
  • Biểu mẫu gửi trên HackerOne sẽ dừng từ 00:00 CEST ngày 1/7/2026 và mở lại vào 09:00 CEST ngày 3/8/2026
  • Các báo cáo bảo mật và lỗ hổng gửi tới địa chỉ email bảo mật cũng sẽ không được xử lý, và curl nhìn chung không nhận báo cáo lỗ hổng qua email
  • Biện pháp này khiến lịch phát hành 8.22.0 lùi 2 tuần, được điều chỉnh sang ngày 2/9/2026
  • Các khách hàng có hợp đồng hỗ trợ trả phí vẫn nhận đầy đủ dịch vụ trong giai đoạn này, còn bộ theo dõi issue và pull request trên GitHub vẫn mở như bình thường

Lịch chính và phạm vi áp dụng

  • Trong giai đoạn Mùa hè hạnh phúc của curl, dự án curl sẽ không tiếp nhận hay xử lý bất kỳ báo cáo lỗ hổng nào trong suốt tháng 7/2026
    • Thời điểm bắt đầu là 00:00 CEST ngày 1/7/2026
    • Thời điểm tiếp nhận trở lại là 09:00 CEST ngày 3/8/2026
  • Biểu mẫu gửi trên HackerOne sẽ dừng từ ngày 1/7/2026 và có thể gửi lại vào thứ Hai, ngày 3/8
  • Địa chỉ email bảo mật cũng sẽ không thể là kênh xử lý báo cáo bảo mật và lỗ hổng trong thời gian này
    • Những vấn đề mà bạn cảm thấy cần phải báo cho dự án curl trong giai đoạn này cũng sẽ phải chờ
    • curl nhìn chung không nhận báo cáo lỗ hổng qua email, và điều này vẫn giữ nguyên cả trong kỳ nghỉ lẫn sau đó

Ảnh hưởng vận hành và ngoại lệ

  • Kỳ nghỉ thực sự

    • Các maintainer của curl dự định tận dụng quãng thời gian bớt áp lực này để tận hưởng mùa hè, đi bộ ngoài trời nhiều hơn và nghỉ xả hơi
    • Một số maintainer có thể sẽ ghé thăm những nơi khác trong giai đoạn này
    • Cũng có thể sẽ có thêm thời gian cho việc sửa lỗi hoặc làm mã mới, và điều đó được xem là công việc thú vị
  • Tác dụng phụ

    • Để có thời gian xử lý các issue có thể tích tụ vào đầu tháng 8, ngày phát hành 8.22.0 sẽ lùi thêm 2 tuần
    • 8.22.0 hiện được lên lịch phát hành vào ngày 2/9/2026
  • Sự gia tăng báo cáo lỗ hổng

    • Dự án curl đã chịu áp lực lớn trong khoảng 4 tháng vừa qua
    • Hiện tại họ cần nghỉ ngơi và không kỳ vọng đợt đổ vào số lượng lớn này sẽ sớm chấm dứt
  • GitHub

    • Bộ theo dõi issuepull request của curl trên GitHub vẫn mở và hoạt động như bình thường
  • Các dự án mã nguồn mở khác

    • Nếu các dự án mã nguồn mở khác cũng muốn tham gia Mùa hè hạnh phúc 2026, chỉ cần triển khai và báo cho phía curl biết
    • Việc ưu tiên chăm sóc chính mình được khuyến khích
  • Người xấu không nghỉ

    • Người xấu có thể không nghỉ, nhưng các maintainer của curl thì có
  • Tình huống khẩn cấp

    • Dù có tình huống khẩn cấp, các maintainer của curl cũng sẽ đọc vào tháng 8
    • Nếu muốn được đọc sớm hơn thì cần có hợp đồng hỗ trợ
  • Ngoại lệ theo hợp đồng

    • Tất cả những người có hợp đồng hỗ trợ trả phí vẫn sẽ nhận được dịch vụ đầy đủ và phù hợp trong giai đoạn này

2 bình luận

 
Ý kiến trên Hacker News
  • Tiêu đề đã che mất điểm chính. Đây là cách vừa có kỳ nghỉ hè, vừa khuyến khích các hợp đồng hỗ trợ doanh nghiệp để tiếp tục được hỗ trợ
    Hình như đây là lần đầu tôi nghe về một mô hình kinh doanh gắn mã nguồn mở/hỗ trợ/kỳ nghỉ hè như vậy, và tôi thấy thích nó

    • Tôi thích ý tưởng này, và mã nguồn mở cũng có thể thử áp dụng lịch kiểu 6 tháng hỗ trợ công khai + 6 tháng hỗ trợ doanh nghiệp
      Mã nguồn mở sẽ có thêm nguồn tài trợ, còn doanh nghiệp có thể nhận hỗ trợ rẻ hơn so với việc tuyển nhân viên toàn thời gian chỉ vì một dự án mã nguồn mở cụ thể
    • Tôi cứ tưởng hợp đồng hỗ trợ doanh nghiệp không có thật của curl là cách để lịch sự bảo mấy nhân viên giấy tờ ngớ ngẩn biến đi: https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquir...
    • Đây là một cách tiếp cận cực kỳ không-châu-Âu. Các công ty châu Âu thường phớt lờ cả khách hàng trả tiền từ tháng 5 đến tháng 8
  • Câu “bọn xấu sẽ không nghỉ, nhưng chúng tôi thì nghỉ” mang lại một cảm giác tính người rất đáng quý trong thời đại phi nhân tính này

    • Tôi còn thích hơn vì có vẻ vẫn có cách giải quyết nếu thực sự cần sửa gấp
      Kiểu như “nếu có hợp đồng hỗ trợ thì chúng tôi sẽ đọc sớm hơn”
    • Tôi lo phe xấu sẽ tập trung tìm zero-day để tự do khai thác các lỗ hổng mà họ phát hiện trong suốt một tháng đó. Dù vậy, tôi không nghi ngờ chuyện họ cần nghỉ ngơi
  • Với những người muốn hoàn toàn tách khỏi công việc khi đi nghỉ, tốt nhất là phải khiến mình không thể làm việc được nữa
    Kiểu như để lại thiết bị công việc, đăng xuất khỏi mọi tài khoản, sao lưu khóa xác thực hai yếu tố ra giấy rồi loại bỏ nó, và nhờ bạn đời không trả lại trong kỳ nghỉ. Tôi thậm chí từng tới một quốc gia không cho phép làm việc từ xa. Nghe có vẻ điên, nhưng đúng là nghiêm túc như vậy. Nói từ kinh nghiệm của một cựu nghiện việc

    • Một trong những lý do tôi rời Bắc Mỹ sang châu Âu là vì điều này được bình thường hóa ở đó. Khác biệt văn hóa là rất lớn
      Ở Đức, nếu đang nghỉ phép thì coi như không thể liên lạc. Bạn bị xem như không tồn tại trên đời cho đến khi quay lại, không đọc email và để thiết bị ở văn phòng. Ngoài ra nếu bị ốm trong kỳ nghỉ thì bạn được hoàn lại ngày nghỉ, vì ngày nghỉ là để nghỉ ngơi và hồi phục
    • Góc nhìn của tôi hơi khác. Thỉnh thoảng trả lời email trong kỳ nghỉ cũng không sao, miễn là công ty cũng chấp nhận việc thỉnh thoảng tôi xử lý việc riêng trong giờ làm, như vậy mới là trao đổi công bằng
      Nếu công ty soi giờ vào/ra quá chặt, hoặc bắt dùng nghỉ phép có lương cho mọi việc riêng 30 phút, hoặc nếu công việc liên tục vượt quá 40 giờ mỗi tuần, thì tôi cũng sẽ dừng làm việc “ngoài giờ”. Nhưng nếu công ty hợp lý thì tôi cũng có thể cư xử hợp lý
    • Một trong những điều hay khi tôi làm ở ngân hàng là kỳ nghỉ khóa quyền truy cập. Bộ phận kiểm toán quan tâm đến việc nhân viên có thể tiếp tục can thiệp hay không, nên ai có quyền hạn từ một mức nào đó trở lên đều phải nghỉ liên tục N ngày trong khi quyền đăng nhập bị vô hiệu hóa
      Đây là công cụ rất tốt để phát hiện bus factor ẩn
    • Cái này có vẻ như quá nhiều việc bổ sung. Nếu có thể, cứ giữ mọi thứ công việc chỉ trên laptop/máy tính công việc, rồi để nó ở nhà hoặc ở văn phòng là được
      Không cần phải đăng nhập/đăng xuất trên 20 tài khoản
    • Công ty tôi tình cờ ép điều này, và hóa ra lại rất tốt
      Trước đây tôi có thể dùng VPN+RDC từ laptop hay desktop cá nhân để kết nối vào desktop ở văn phòng và làm việc từ xa. Giờ thì tôi được cấp laptop, nhưng xác thực từ xa không hoạt động, và công ty cũng không định sửa vì còn ưu tiên khác. Thế nên nếu không mang theo cái laptop đó thì tôi hoàn toàn không thể làm việc, mà khi đã mang thiết bị cá nhân rồi thì tôi cũng chẳng mang thêm laptop công ty nữa. Nếu tôi cũng không mang thiết bị cá nhân, thì ngay từ đầu đã không phải tình huống mang theo bất kỳ laptop nào rồi
      Tôi không nghĩ mình là người nghiện việc, nhưng tôi thuộc kiểu sẽ căng thẳng 24/7 nếu cảm thấy mình có thể giúp được. Việc hoàn toàn không thể làm việc ngoài văn phòng thật sự giúp ích. Theo nghĩa đen là tôi không thể làm gì cả, và đặc biệt khi đó là do công ty tạo ra như vậy, tôi cũng không còn bị căng thẳng theo cùng kiểu nữa
      [1] Ngoài thiết bị kết nối VPN và thiết bị MFA trên một chiếc điện thoại cũ, không có bất kỳ thứ gì liên quan đến công việc như Teams hay email chạm vào thiết bị cá nhân của tôi
      [2] Tôi để một chiếc điện thoại cũ nhỏ đã khôi phục cài đặt gốc, chỉ cài một tài khoản Google giả và ứng dụng MFA
  • libexpat (“Expat”) và uriparser cũng đang theo kỳ nghỉ bảo mật của curl, và từ hôm nay đến trước 2026-08-01 sẽ không nhận báo cáo lỗ hổng mới
    [1] https://github.com/libexpat/libexpat/issues/1277
    [2] https://github.com/uriparser/uriparser/issues/323

  • Với những ai cho rằng việc này có thể ảnh hưởng đến bảo mật, curl đã đủ trưởng thành để khả năng xuất hiện lỗi nghiêm trọng gần như bằng 0, và ngay cả nếu có lỗi như vậy thì kiểu gì cũng sẽ có ai đó tìm được cách liên hệ với Daniel và nhóm của ông ấy; quan trọng hơn là bản vá phải được đưa vào trình quản lý gói và phân phối
    Bản phát hành upstream có thể chờ được

    • Đó chính là mấu chốt. Họ sẽ không nhận báo cáo lỗ hổng. Họ đang đi nghỉ
    • Ngay cả khi bản thân curl không có lỗ hổng, curl vẫn là công cụ tải dữ liệu Internet tùy ý, nên về nguyên tắc nó phải luôn nằm trong sandbox chặt chẽ
      Chỉ riêng việc tải dữ liệu tùy ý vào shell cũng có thể vô tình chạm phải lỗ hổng ở mọi phần khác của môi trường
  • Không thể không vỗ tay cho quyết định này. Những người duy trì dự án mã nguồn mở tự do gần như luôn quá tải mà nhận lại rất ít bù đắp, và giờ vì LLM gánh nặng quản lý pull request còn tăng vọt hơn nữa
    Chỉ riêng việc họ vẫn tiếp tục hỗ trợ người dùng trả tiền cũng đã là quá đủ

  • Tôi đồng cảm với các maintainer, nhưng rốt cuộc điều này lại cho thấy chúng ta đang phụ thuộc không có phương án dự phòng vào một số ít cá nhân làm việc gần như miễn phí
    Thông thường các tổ chức sẽ sắp lịch nghỉ lệch nhau để tránh chuyện này. Họ buộc phải làm vậy vì khách hàng yêu cầu. Ở đây mọi người đều là khách hàng của curl, nhưng thực tế lại cũng không hẳn vậy. Tôi thấy đây là một vùng xám kỳ lạ và không lành mạnh, chẳng tốt cho ai cả. Việc ngay cả curl cũng không đủ khả năng tài chính để bố trí trực on-call trong một tháng vừa đáng ngạc nhiên vừa đáng buồn

    • Điều đáng kinh ngạc của phần mềm nguồn mở tự do là, nếu không có maintainer, bạn vẫn có toàn bộ quyền và toàn bộ mã nguồn, nên có thể tự sửa hoặc trả tiền cho ai đó sửa
      Mối quan hệ này chỉ trở nên không lành mạnh khi người ta trộn không có bảo hành với những kỳ vọng phi thực tế rồi áp đặt chúng lên dự án
    • Thực ra là có. Cuối bài có nói rằng nếu có hợp đồng hỗ trợ thì họ vẫn phản hồi và cũng xử lý các vấn đề bảo mật
      Ý chính của bài cũng có vẻ gần với việc nếu cần hỗ trợ thì hãy mua hợp đồng hỗ trợ
    • Có mà
      “Tất nhiên, mọi người có hợp đồng hỗ trợ trả phí vẫn nhận được dịch vụ đầy đủ và phù hợp ngay cả trong giai đoạn này”
    • Bài viết nói rất rõ rằng nếu có hợp đồng hỗ trợ trả phí thì chế độ on-call vẫn được duy trì như bình thường
    • Dù lo ngại về kịch bản này, tôi nghĩ người đó cũng sẽ không tự bỏ tiền ra để trả cho việc có người trực on-call
  • Hệ thống hiện tại, nơi chúng ta phải liên tục phát hiện lỗ hổng, báo cáo, phân tích, vá, rồi phát hành phiên bản mới cho mọi người dùng, rõ ràng là không bền vững
    Ngành này cần tìm ra một hệ thống thay thế để xử lý bug và vấn đề bảo mật. Còn hiện giờ ngành công nghiệp dường như thích giả vờ không thấy, rồi biến thất bại của chính mình thành cơ hội trục lợi địa tô

    • Vậy giải pháp tốt hơn là gì?
      Và ví dụ về kiểu trục lợi địa tô mà bạn nói trong nguồn mở là gì?
    • Tôi nghĩ nhận định đó đúng, và giải pháp là bảo mật bằng cách phân vùng/cô lập. Tham khảo: https://qubes-os.org
  • Chỉ cần đọc một câu là tôi biết ngay nhà phát triển này là người Thụy Điển

    • Nói cho những ai chưa quen thì Thụy Điển rất nghiêm túc với kỳ nghỉ hè. 25~30 ngày nghỉ phép mỗi năm + ngày lễ là chuyện bình thường, và nếu nhân viên có số ngày nghỉ có thể yêu cầu và sử dụng, thì việc cho nghỉ hè liên tục 4 tuần gần như là yêu cầu theo luật
      Tham khảo: https://www.riksdagen.se/sv/dokument-och-lagar/dokument/sven...
    • Là người Na Uy, tôi cũng nghĩ y như vậy. Ở Na Uy thì về cơ bản tháng 7 là dừng lại hết
    • Tôi cũng bật cười y hệt. Công ty chính của tôi cũng có văn phòng ở Thụy Điển, và kỳ nghỉ hè của họ đúng là huyền thoại
      Công ty còn có cả văn phòng ở Mỹ nữa, và cú sốc văn hóa của người Mỹ thì lần nào nhìn cũng thấy mới mẻ
    • Tôi đã nghĩ ngay đó là người ấy. Hiếm có ai khát sự chú ý đến mức giống người đó
  • Ở châu Âu, ví dụ như Đức, 20~30 ngày nghỉ phép có lương và nghỉ ốm không giới hạn là điều bình thường. Nếu nghỉ ốm quá 3 ngày thì cần giấy xác nhận của bác sĩ
    Nếu bạn bị ốm trong kỳ nghỉ thì những ngày nghỉ đó sẽ được hoàn lại. Nếu đang nghỉ mà đột ngột phải làm việc thì khoảng thời gian đó không thể bị tính là thời gian nghỉ. Nhìn chung bạn không thể bị sa thải mà không có thời hạn báo trước, nên mức độ ổn định việc làm cao hơn, và ngay cả khi thất nghiệp vẫn có trợ cấp, vì vậy chỉ cần có quỹ khẩn cấp khoảng 6.000 USD là đã rất ổn định. Điều đó có dẫn tới việc người kém năng lực không bị sa thải không? Không hẳn. Họ vẫn có thể bị sa thải, chỉ là sau đó bạn phải xử lý thêm khoảng một tháng nữa thôi. Đó không phải cái giá quá lớn
    Vì sao điều này khả thi và ai là người trợ cấp? Chỉ là mọi người đều đóng góp vài phần trăm thu nhập để duy trì hệ thống này. Chỉ với vài phần trăm, vài đô la, bạn gần như không còn phải lo chuyện chết đói hay vô gia cư
    Các bạn cũng có thể có một hệ thống như vậy nếu biết bỏ phiếu, xuống đường và sử dụng nền dân chủ để làm cho cuộc sống của mọi người tốt lên thay vì tệ đi

 
Ý kiến trên Lobste.rs
  • “Kẻ xấu không bao giờ nghỉ”, nhưng dù vậy chúng ta vẫn nên nghỉ
    Chúc kỳ nghỉ vui vẻ, hoàn toàn xứng đáng. Những ai đang cảm thấy áp lực cũng nên cân nhắc nghỉ phép

  • Vì kẻ xấu cũng đâu gửi trước báo cáo lỗ hổng, nên việc trực chờ có lẽ cũng không làm thay đổi mối đe dọa này
    Cá nhân tôi còn thấy 4 tuần nghỉ phép hơi ngắn, nhưng có thể là vì tôi nghĩ quá kiểu Pháp

    • Có vẻ Daniel đang kín đáo nhắc đến khái niệm industrisemester của Thụy Điển
      Thông thường vào tháng 7, các nhà máy sản xuất ở Thụy Điển cho phần lớn nhân viên nghỉ phép, còn nhà máy thì được kiểm tra, bảo trì và sửa chữa trong thời gian đó. Đến nay vẫn có nhiều người cố sắp xếp kỳ nghỉ hằng năm trong vòng một tháng sau hạ chí, và theo luật thì hạ chí rơi vào thứ Bảy trong khoảng 20~26 tháng 6
    • Cũng không hẳn là nghỉ hoàn toàn. Anh ấy nói vẫn sẽ phản hồi nếu có vấn đề hợp đồng hỗ trợ, nên thực tế còn ngắn hơn nữa :-D
  • Chúc anh ấy tận hưởng kỳ nghỉ :)
    Chỉ là có thể anh ấy chưa nhận ra mình đã chọc vào tổ ong vì bài viết khoe khéo rằng Mythos chỉ tìm ra đúng một lỗi

    • Biết đâu lý do thật sự mà chính phủ Mỹ chặn quyền truy cập vào mô hình Anthropic mới nhất là để cho Daniel được nghỉ phép
    • So sánh đó có vẻ không hợp lắm. Daniel đã bị cả bầy ong vây quanh suốt nhiều năm rồi, và ai cũng đang mải xây dựng danh tiếng để giành lấy curl CVE chính thống
  • Thật vui khi thấy điều này. Mong rằng đây sẽ là động lực để các maintainer mã nguồn mở khác cũng ưu tiên sức khỏe tinh thần của mình

  • Tôi thích điều này. Ước gì các dự án khác cũng làm theo cách này