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
171–180 of 326 posts
Re: Curl will not accept vulnerability reports during July 2026
#172Earlier 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.
Except if you pay them for a support contract. So there is a way, and it's actually a pretty obvious way.
Re: Curl will not accept vulnerability reports during July 2026
#173Re: Curl will not accept vulnerability reports during July 2026
#174Re: Curl will not accept vulnerability reports during July 2026
#175Earlier quoted context omitted.
Being the only dev in a startup since 2 years without a single day off where I wasn't messaged by my employer I want this. At least I'll have a 3 week out of country trip where I do not bring my laptop later this year...
You should really consider another place to work at, unless you own a massive, measurable chunk of the company in a legally binding way. The only people who should suffer this much are the true busines owners.
Re: Curl will not accept vulnerability reports during July 2026
#176Earlier quoted context omitted.
This is the HTTP/1.1 standard: https://datatracker.ietf.org/doc/html/rfc2616 Then there are also HTTP/2 and HTTP/3. That's just HTTP, curl supports 27 other protocols.
HTTP/1.1 - June 1999 It's not like the standard changed since curl was created
Re: Curl will not accept vulnerability reports during July 2026
#177Today is Jun 15. So, I wonder if somebody + AI can rewrite curl in Rust in 1.5 months. I think it's possible if that person knows all curl features. However, does that person even exist?
Re: Curl will not accept vulnerability reports during July 2026
#178Earlier quoted context omitted.
You don't really though. Sure you can fork it and fix your issue, but then what? Are you going to maintain your fork in perpetuity? Are you going to patch all the software that depends on the code you fixed to use your version instead of upstream? Are you going to get your users to do that too? In most cases this is extremely impractical.
> but then what? Then you send the patch upstream, they incorporate and maintain it for you. Congratulations, you just FOSSed.
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
#179Earlier quoted context omitted.
I'm surprised, typically we don't all take vacation at the same time, but stagger it.
It's not entirely uncommon, even companies like Volkswagen have 3 weeks of summer vacation. Strictly speaking, some people still work there for maintenance, etc. that can't be done while making cars, but the majority is on vacation. I know a handful of companies with a week of mandatory Christmas vacation as well (but there's typically not too many working days between Christmas and New Years' either way).
I don't know if this work would have been offered to staff who turned it down, or if they preferred to have their staff on holiday at the same time.
Re: Curl will not accept vulnerability reports during July 2026
#180For anyone who thinks this might matter for security: * curl is mature enough that the chance of an impactful bug is basically zero * if there is such a bug, I'm sure someone will figure out how to get in touch with Daniel and co * if there is such a bug, it's more important that it gets patched in package managers and rolled out. Upstream releases can wait.
Curl is also something that should be thoroughly sandboxed to begin with, because even if there are no vulnerabilities in curl itself, its a tool for downloading arbitrary data over the internet, and you may well accidentally trigger vulnerabilities in every other part of your environment just by downloading arbitrary data to your shell...