Live data from Hacker News

Curl will not accept vulnerability reports during July 2026

daniel.haxx.se

201–210 of 326 posts

Re: Curl will not accept vulnerability reports during July 2026

#201
post #132

Earlier quoted context omitted.

>I can agree with it but I am unsure how much the desperation is out of FOMO or out of real use-cases. I frequently run into people using it, they seem happy with it. I remain highly skeptical about this being a good idea, but I'm quite convinced that many people genuinely really like it and find it useful.

> I frequently run into people using it, they seem happy with it. I remain highly skeptical about this being a good idea, but I'm quite convinced that many people genuinely really like it and find it useful. That can be the case and good for them, at the very least its open source software that they are using and it raises more awareness about them. But I think that we have strayed a bit afar from my main premise tha…

>But the question is if its entirely reasonable as to a project like Curl getting less funding overall, simply because everyone is using curl underneath but the tech is boring (as I think it should be), but this makes everyone think that curl is well-funded when it isn't.

I think the returns fall off really really quickly when you increase investment in a boring, mature project like this.

It might be nice if people sponsored curl more, but the software isn't going to significantly improve because of it.

Re: Curl will not accept vulnerability reports during July 2026

#202
post #197
post #11

For the people here who want to do the same when they are vacation (be completely detached from work): Make it impossible for you to work! Leave your work devices behind! Log out of all accounts, remove 2FA keys after backing them up on paper and tell your partner to not give them back to you for the duration of your vacation, etc. I actually went to a country from which I wasn't allowed to work remotely. Crazy but i…

I think my POV on this is a bit different than what others are expressing… I don’t mind answering the occasional email while on vacation, but I view it as a fair trade - as long as the company doesn’t mind me handling the occasional personal obligation during work hours I don’t mind handling the occasional work obligation during personal hours. If the company wants to be strict about clock in/out hours or taking PTO…

The idea with vacation is that you don't think about work. When I start vacation I disable all the channels that people usually use so that no one asks me even by accident. There needs to be a time when you are completely undisturbed and disconnected. If you are disturbed by work you will think about work while you answer and maybe even after that. That's not good.

I also think you should normalize for yourself and your workplace that there are times when you are not there. If only you can answer a question then there needs to be better documentation. See it as a trail run for when you get hit by a bus. If they will struggle without you then that is a problem that needs to be fixed. If you are always reachable these problems will never surface.

Re: Curl will not accept vulnerability reports during July 2026

#204

Earlier quoted context omitted.

For people who aren’t familiar, Sweden takes summer holidays seriously. 25-30 days + public holidays is a normal amount of annual vacation time, and if an employee requests it and has the time available, it’s basically legally required to allow them to take a four-week contiguous summer break. (See https://www.riksdagen.se/sv/dokument-och-lagar/dokument/sven... )

Not only that but the vacation is real . If someone is off then you should not expect them to answer at all (because if you do you’ll get very disappointed).

This might not be true for Sweden, but Denmark have an interesting rule that makes contacting people in their vacation fairly expensive. If I'm asked to change my plans, my employer needs to compensate me financially. If you get a call and need to work for 30 minutes, then you are entitled to a full replacement day, not just the 30 minutes. For some jobs, interrupting people on vacation simply isn't allowed.

Re: Curl will not accept vulnerability reports during July 2026

#205
post #33

Earlier quoted context omitted.

https://curl.se/libcurl/ Let me Google that for you. supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, HTTP/2, HTTP/3, cookies, user+password authentication (Basic, Digest, NTLM, Nego…

I think the argument was that curl is fairly feature complete (as shown by your list), is there really that many bugs in curl that require immediate attention?

"Featureful" doesn't imply "feature complete". They appear to release minor versions all the time.

https://curl.se/docs/releases.html

If you dig into them you'll see there's lots of features that aren't adding new protocols. But incidentally they added a new protocol in March (mqtt). You'll also see that the list of bug fixes is prolific.

https://curl.se/ch/8.19.0.html

Re: Curl will not accept vulnerability reports during July 2026

#206
post #200
post #187

Earlier quoted context omitted.

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

Coz just about everyone wants to be that one guy in Nebraska thanklessly maintaining this bit of digital infrastructure, apparently? Yeah me neither. I think the only thing that would convince people to move away from curl at this point would be if curl had a heartbleed level vulnerability and failed to fix it quickly.

Individuals don't but lots of companies do, so that they can threaten to rugpull it later if you don't pay them millions.

Re: Curl will not accept vulnerability reports during July 2026

#207
post #187

Earlier quoted context omitted.

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?

We don’t need to speculate do we, there are tons of real non company run OSS projects

Now I personally wish lawyers and plumbers also got into the free work thing but here we are

Re: Curl will not accept vulnerability reports during July 2026

#208

Earlier quoted context omitted.

Sweden has 14 sick days no questions asked before you need a doctors note. The German way of having to call your doctor for a flu note is a little odd to me. You do loose the first day's pay (the meme is that too many people were off sick when there was a world cup finals or something), and then 80% pay.

This is not accurate. In Germany, you usually only have to get a doctor's note at 2 or 3 days, if youre only sick for a day or two you don't need one. And there's an unlimited number of sick days. As long as you have a doctor's note, you still get paid, up to some ridiculous limit at which you might have to get government support instead.

I think at some limit the health insurance pays back the employer, right?

Re: Curl will not accept vulnerability reports during July 2026

#209
post #172
post #81

Earlier quoted context omitted.

Except if you pay them for a support contract. So there is a way, and it's actually a pretty obvious way.

I wonder if the likes of Red Hat, SuSE and Canonical have a support contract as they are commercial redistributors.

Probably not. Why pay someone who's willing to work for free? When he stops working for free, then you pay him. Open source is not exempt from economic principles.

Re: Curl will not accept vulnerability reports during July 2026

#210
post #39

For 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 mature enough that the chance of an impactful bug is basically zero 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...

curl is the sandbox. It exchanges packets with the internet and then outputs a safely sanitized byte stream.
Post reply on HN