HN Debrief

Curl will not accept vulnerability reports during July 2026

  • Open Source
  • Security
  • Infrastructure
  • Workplace

Daniel Stenberg said curl will stop accepting vulnerability reports for July 2026 so the maintainers can actually take a vacation. The carveout is explicit: paying support customers still get coverage. That made the post read less like a quirky holiday notice and more like a line in the sand about what free users are, and are not, owed from a piece of software that sits deep in the Internet’s plumbing.

If your product depends on volunteer-maintained infrastructure, treat upstream availability as a risk you own. Budget for support contracts, internal patching capacity, or a fallback plan instead of assuming free 24/7 security response.

Discussion mood

Strongly supportive, with admiration for the bluntness and for maintainers protecting their time. The only sustained unease was about how much critical infrastructure still depends on a few people without guaranteed coverage.

Key insights

  1. 01

    A pricing signal, not just a vacation notice

    The paid-support carveout changes the meaning of the announcement. It is a deliberate market signal to companies that want guaranteed response times. Free use stays free, but availability now has a price tag. That makes the post an unusually direct attempt to turn dependency into funding instead of goodwill.

    If you run revenue-critical systems on curl, this is your prompt to decide whether support belongs in your vendor budget. If not, be honest that you are self-insuring and staff accordingly.

      Attribution:
    • vessenes #1
    • ed_elliott_asc #1
    • Nnnes #1
    • 4ndrewl #1
  2. 02

    Shipping the fix is harder than writing it

    For serious curl users, the real bottleneck is often not producing a patch. It is getting that patch through package managers, firmware updates, downstream applications, and deployed devices. That is why “just fix it yourself” only solves the first mile. The hard part is ecosystem distribution and adoption.

    Measure your dependency response plan by time-to-deploy, not just time-to-patch. If you cannot roll out emergency updates quickly, upstream responsiveness is only part of your exposure.

      Attribution:
    • matthewdgreen #1
    • toast0 #1
    • alibarber #1
  3. 03

    Forking is viable only if you already own maintenance

    Several comments cut through the romantic version of forking. Keeping a private or semi-private security fork is realistic when your team already carries operational responsibility for the software. It is not a casual escape hatch for organizations that have neither maintainers nor release processes. In practice, the ability to fork is agency for prepared users, not comfort for unprepared ones.

    Do not put “we can always fork it” in a risk plan unless you have named people and a release path behind that claim. Otherwise buy support or reduce the dependency surface.

      Attribution:
    • spiffyk #1
    • necovek #1 #2
    • megous #1
  4. 04

    Forced absence exposes hidden bus factors

    The vacation side conversation landed on a useful organizational point. Unreachable vacations are not only humane, they are a resilience test. Banks even require lockout vacations for some roles because continuous access can hide fraud or operational fragility. If the business breaks when one person disappears for two weeks, that was already a critical failure mode.

    Use vacations like a fire drill. Rotate ownership, document recovery paths, and prove that teams can function without their key person before an actual emergency does it for you.

      Attribution:
    • blauditore #1
    • alibarber #1
    • oasisbob #1
  5. 05

    curl is rarely the end of the trust boundary

    One useful security reminder was that curl usually just moves untrusted data to the next tool. The danger often sits in whatever you do after download, such as piping to bash, rendering a PDF, or handing content to another parser. Treating curl itself as the whole security boundary misses where many real exploits land.

    Review the full chain after download, not only curl itself. Sandboxing, content validation, and safer post-processing matter more than assuming the transport step is the whole problem.

      Attribution:
    • inigyou #1
    • swiftcoder #1 #2
  6. 06

    Other projects may copy the policy

    This was not just a one-off curl quirk. libexpat and uriparser immediately said they would follow the same July 2026 security break. That suggests maintainers see this as a reusable pattern for drawing labor boundaries, not a personal exception.

    Expect more critical open source projects to make availability conditional or seasonal. Track maintainer policies the same way you track licenses and release cadences.

      Attribution:
    • spyc #1

Against the grain

  1. 01

    More money may not change much for curl

    One skeptical line held that curl is a boring, mature project with diminishing returns to extra investment. The claim is not that maintainers should go unpaid. It is that throwing much more money at a stable codebase may not buy proportionally better software or fewer bugs, so the funding story is not as simple as “critical project equals underfunded emergency.”

    Separate two questions in your planning: whether maintainers deserve support and whether extra spend materially improves your risk. Support contracts may be about guaranteed access, not about accelerating product evolution.

      Attribution:
    • insumanth #1
    • l23k4 #1
  2. 02

    Support contracts can look like pressure tactics

    A minority read the paid exception as coercive. The uncomfortable angle is that withholding free vulnerability intake while preserving paid access can feel like monetizing insecurity, even if the underlying labor claim is fair. That reaction matters because buyers may see the move less as boundary-setting and more as leverage.

    If you run an open source business, expect support monetization around security to trigger trust concerns. Be explicit about what paid support buys and what free users can still count on.

      Attribution:
    • okeuro49 #1
    • geraldcombs #1
  3. 03

    Europe-wide shutdowns are not universal

    The long vacation theme resonated, but some pushed back on the idea that all of Europe casually disappears for a month. Full-company closures happen in some sectors and countries, but they are not a universal norm for white-collar software work. That matters because part of the praise was cultural projection rather than something specific to curl.

    Do not generalize regional work norms too quickly when you design support expectations. Ask vendors and upstream projects about their actual coverage model instead of inferring it from country stereotypes.

      Attribution:
    • teruakohatu #1
    • my-next-account #1
    • breakingcups #1

In plain english

bus factor ↩
A measure of how vulnerable a project is to losing key people, often framed as how many people could disappear before the project stalls.
libexpat ↩
A widely used open source library for parsing XML data.
SLA ↩
Service level agreement, a contract that defines support and response commitments such as uptime or issue response times.
uriparser ↩
An open source library for parsing and handling Uniform Resource Identifiers.

Reference links

curl policy and background

Other projects adopting the policy

Vacation and labor norms

Security and compartmentalization

  • Qubes OS
    Suggested as an example of compartmentalization as a more sustainable way to contain software vulnerabilities.

Videos and lighter references