Live data from Hacker News

Curl will not accept vulnerability reports during July 2026

daniel.haxx.se

181–190 of 326 posts

Re: Curl will not accept vulnerability reports during July 2026

#181

Earlier quoted context omitted.

I liked the idea as well, maybe OSS should adopt 6 months availability and 6 months for enterprise support schedule. This way both could benefit, OSS gets more funding, enterprise gets support (cheaper than hiring full-time employee for specific OSS)

Until someone races to the bottom to do 12 months of availability.

That’s just the status quo.

Re: Curl will not accept vulnerability reports during July 2026

#182

A curious approach, but I like it! Wonder if this means just publishing vulnerablities without contact with curl team would be responsible (you have no other path to tell vulnerable users)

I think very few people would consider that to be responsible disclosure. The common practice is to allow 90 days as a minimum.

I think I'd personally develop a minimal patch and then publically disclose.

I'm not sure it's be reasonable to leave an actively exploited critical bug until August. Nor would I be too interested in playing middle man or paying for support from curl to get it out.

Re: Curl will not accept vulnerability reports during July 2026

#183

Earlier quoted context omitted.

I liked the idea as well, maybe OSS should adopt 6 months availability and 6 months for enterprise support schedule. This way both could benefit, OSS gets more funding, enterprise gets support (cheaper than hiring full-time employee for specific OSS)

Until someone races to the bottom to do 12 months of availability.

Ah yes, people will just be clamoring to use hURL

Re: Curl will not accept vulnerability reports during July 2026

#184

Earlier quoted context omitted.

Until someone races to the bottom to do 12 months of availability.

Races to the bottom to … do work exclusively for free and not make any money out of the hopes that they become the most popular OSS toolkit, with an end goal of … what?

> at they become the most popular OSS toolkit, with an end goal of … what?

Look at how any "FOSS + VC + for-profit" company in the last 5-10 years worked out, and you'll see the playbook.

Re: Curl will not accept vulnerability reports during July 2026

#186
post #85

Earlier quoted context omitted.

> but then what? Then you send the patch upstream, they incorporate and maintain it for you. Congratulations, you just FOSSed.

> Then you send the patch upstream, they incorporate and maintain it for you Firing patches upstream is still adding burden to the (likely already over-burdened) maintainers. In an ideal world, if you want a patch upstreamed, you would be contributing to upstream maintenance (or at least donating to the upstream maintainers)...

Fair, but it is less of a burden than just submitting a report with no proposed fix. Also, submitting quality patches regularly seems to be a good way to eventually become a maintainer, provided that both sides are interested (cURL generally is – at least that seemed to be the vibe at the last year's cURL Up event I attended).

Re: Curl will not accept vulnerability reports during July 2026

#187

Earlier quoted context omitted.

I liked the idea as well, maybe OSS should adopt 6 months availability and 6 months for enterprise support schedule. This way both could benefit, OSS gets more funding, enterprise gets support (cheaper than hiring full-time employee for specific OSS)

Until someone races to the bottom to do 12 months of availability.

A race to the bottom of… unpaid work that eliminates the paid work? Can you elaborate?

Re: Curl will not accept vulnerability reports during July 2026

#188

Earlier quoted context omitted.

It's an extremely un-European approach. European companies normally ignore their paid customers too from May to August.

Incorrect. In europe, either july or august, is the informally agreed upon "vacation month" which means that both customers and vendors scale down and go on vacation, and work slows down to very low levels. That means you need a lot less employees than usual in order to provide for the customers that do not go on vacation.

To be fair, at least in Spain, things get really slow during the summer, basically from May to the end of August, even if "officially" everything is just "slow and closed" during August. During August, anything productive is basically impossible to get done, the months around are still slower than the rest of the year.

Of course, "European companies normally ignore their paid customers too from May to August" is factious, but there is a slight hint of truth in there, in that things generally is slower, at least in the South/West countries I'm more familiar with.

Re: Curl will not accept vulnerability reports during July 2026

#189

Earlier quoted context omitted.

In Poland smaller companies tell you outright: this and that person is on vacation, but plese call back in 2 weeks. Bigger companies will often ignore you and drag your problem through the vacation time.

> tell you outright That is not ignoring but announcing a delay. Bigger companies may have only limited number of people checking the mailboxes in july and august, that doesn't excuse not sending a small reply announcing delays but I guess they take it so much for granted they don't realize other continents aren't used to those kinds of delays. However in May and June every company is totally operational ( that doesn…

> That is not ignoring but announcing a delay.

I think maybe with the American PoV of "the customer is always right", that might basically feel like a slap and the face and being ignored. Of course, we should understand that every human needs to rest during the year, but if you don't have that opportunity yourself by law, maybe you're less knowing about that being a thing in other more modern countries?

Re: Curl will not accept vulnerability reports during July 2026

#190
post #108
post #72

Earlier quoted context omitted.

> if there is such a bug, I'm sure someone will figure out how to get in touch with Daniel and co No, that is the point, they are not going to accept your vuln report. They are taking a holiday.

There's a pretty big difference between a random report submitted via email, and, say, a close friend of the maintainers letting them know a serious vuln was found and they should login.

Curl maintainers are clearly going to still be using computers to provide support for paid customers.

But the message is pretty clear: if you’re not a paid customer, you are not getting patches or support from upstream during this month.

Plan accordingly.

Post reply on HN