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.
Curl will not accept vulnerability reports during July 2026
181–190 of 326 posts
Re: Curl will not accept vulnerability reports during July 2026
#182A 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'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
#183Earlier 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.
Re: Curl will not accept vulnerability reports during July 2026
#184Earlier 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?
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
#185I read one sentence into this and knew directly that the developer must’ve been Swedish!
Re: Curl will not accept vulnerability reports during July 2026
#186Earlier 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)...
Re: Curl will not accept vulnerability reports during July 2026
#187Earlier 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.
Re: Curl will not accept vulnerability reports during July 2026
#188Earlier 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.
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
#189Earlier 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…
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
#190Earlier 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.
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.