|
|
Log in / Subscribe / Register

Stenberg: curl summer of bliss

[Posted June 15, 2026 by jzb]

Daniel Stenberg has announced that curl will not be accepting vulnerability reports from July 1 through August 3, unless the submitter has a paid support contract. He is calling it the "curl summer of bliss".

As previously mentioned, we have been under a huge pressure for the last four months or so. Now we need some rest. We do not expect this deluge to be over.

[...] If you and your Open Source projects also want to participate in the summer of bliss 2026: just do it and let us know! I would of course encourage you to do so. To take care of yourself as a top priority.

The project's issue and pull-request trackers on GitHub will remain open. The planned release date for curl 8.22.0 has been pushed back two weeks to September 2, 2026.


to post comments

Open source avantage

Posted Jun 15, 2026 17:59 UTC (Mon) by proski (guest, #104) [Link]

The good thing about open source is that anyone can change the code and distribute the modification. If something really needs to be fixed during the "summer of bliss", it will be fixed. Not so with proprietary software, no bliss for them.

Of course, you can still report bugs

Posted Jun 16, 2026 9:14 UTC (Tue) by epa (subscriber, #39769) [Link]

As the article notes, the bug tracker is still open, so if you find a security bug you can still report it. The difference is the project will not formally "accept" it with the whole brouhaha of embargoes, CVE numbers, drop-everything-and-fix-it-now. I think that might be the way forward in general, not just for one summer. A Linux kernel vulnerability that can be exploited remotely may still deserve its own web page, catchy name, and mysterious "you are strongly recommended to upgrade" fixes. But a bug in libcurl can just be reported and fixed in the normal way. If you found it with an LLM, anyone else could have found it, and probably already have.

Contracts excluded

Posted Jun 16, 2026 11:16 UTC (Tue) by Karellen (subscriber, #67644) [Link] (8 responses)

Everyone with a paid support contracts will of course still get full and appropriate service even during this period.

Probably worth highlighting. Also, interesting strategy to drive interest in support contracts.

Contracts excluded

Posted Jun 16, 2026 16:14 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (2 responses)

I understand why they're saying this, but it seems unlikely to matter much in practice. How often is a company that wants to pay for a service contract going to find a security bug in the first place? It seems to me that the big point of a service contract is that you're paying somebody else to think about bugs for you, so you probably aren't going to go digging for them in the first place. I guess you might be made aware of a bug if somebody actively exploits it against you, but I would assume the developers would take an active, in the wild bug seriously even if the people reporting it don't have a contract.

Contracts excluded

Posted Jun 16, 2026 16:37 UTC (Tue) by clump (subscriber, #27801) [Link]

This was my thought as well. Likewise, attackers aren't going to get a support contract to report a security issue.

It would be interesting to note if there's a flood of legitimate security issues that get reported after August 3rd.

Contracts excluded

Posted Jun 19, 2026 20:16 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Entities large enough to have a service agreement as well as their own in-house security team (I'm thinking Google here, but I'm other FAANG-tier companies have similar situations) might be able to leverage it.

Contracts excluded

Posted Jun 17, 2026 15:58 UTC (Wed) by muase (subscriber, #178466) [Link] (4 responses)

> Also, interesting strategy to drive interest in support contracts.

Not sure. I mean, it highly depends on what is written in the support contracts etc – but if I as a company pay for support and maintenance, I would definitely not be happy if my contractor announces that they won't accept vulnerability reports (which also implies that they won't fix them, so they also leave me – as a paying customer – vulnerable).

I'm all for
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY
– and if you want professional maintenance, then make it official and pay me. But on the other hand, once there is a support contract, stuff becomes business; and I'm not sure if an implicit "we won't sight vulnerabilities for a month" aka "we might not fix well-known RCEs, even for paying customers" would really be a good selling point.

Contracts excluded

Posted Jun 19, 2026 11:05 UTC (Fri) by jch (guest, #51929) [Link] (2 responses)

> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY

Is that really applicable? Are there no warranties that are required by law, not even in EU countries?

Contracts excluded

Posted Jun 19, 2026 13:47 UTC (Fri) by farnz (subscriber, #17727) [Link]

The EU's implicit warranties can, in virtually all circumstances, be extinguished by fully refunding the customer everything that they've paid for the item and arranging to collect it for disposal (if appropriate to the product class). AFAICT, all the current exceptions to this rule require that you had knowledge of the customer's intended use case, and sold it to them anyway.

The required warranties in the EU all kick in when it's either sold, or (in our post-CRA world) where it's a companion digital element to a sold product. The cURL team are talking about a case where they didn't sell anything, and thus neither of those kick in. As a result, no implicit warranty required by law.

Contracts excluded

Posted Jun 19, 2026 15:29 UTC (Fri) by kleptog (subscriber, #1183) [Link]

> Are there no warranties that are required by law, not even in EU countries?

Warranties are consumer protection law, so don't apply if there is no sale from business->consumer. Since you don't buy OSS it's not an issue (just like the CRA isn't activated either). In B2B transactions, not even statutory warranties apply by default (generally, see local law). This trips up small businesses sometimes.

Warranties on software have always been a bit slippery, since it is licensed rather than bought. Hence why the CRA and the Digital Services Act had to be created to deal with these cases.

Contracts excluded

Posted Jun 19, 2026 20:18 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Couldn't such an entity say "report issues to us and we'll forward them if they're relevant to our use case"?


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds