Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Curl will not accept vulnerability reports during July 2026

daniel.haxx.se

Post reply on HN
Print view View original

301–310 of 326 posts

Re: Curl will not accept vulnerability reports during July 2026

#301

Post by akerl_ »

theandrewbailey wrote: post #192
vessenes wrote: post #44

The headline buried the lede -- this is a way to get some summer vacation (niiice) AND encourage enterprise support contracts, which will still have availability. I don't think I've heard of this particular open source / support / summer vacation business model before but I like it!

Here I was thinking that cURL's (non-existent) enterprise support contracts were a polite way to tell brain-dead paper pushers to GTFO: https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquir...

https://curl.se/support.html

What do you mean by non-existent?

Re: Curl will not accept vulnerability reports during July 2026

#302

Post by ffaccount2 »

teruakohatu wrote: post #117
naturalmovement wrote: post #100

Earlier quoted context omitted.

It can honestly be annoying, if you're not privvy to it. I remember years ago needing urgent support for some bespoke European hardware we were developing software for. When we called support, we were greeted with a phone message stating the company was closed for the entire month due to vacation. This was not a one-man operation; the whole office closed for a summer holiday. We thought it was a joke. Needless to say…

My advice is don’t ever buy anything that might need support from New Zealand between 24 Dec and 5 Jan. The entire country is just about closed (other than non-niche consumer stores). Many companies force staff to take vacation days during this time, and there are four (yes four!) public holidays during this period.

Four? Poland has five! (Counting 6th Jan)

Re: Curl will not accept vulnerability reports during July 2026

#303

Post by ffaccount2 »

sevenzero wrote: post #175
vkazanov wrote: post #82

Earlier quoted context omitted.

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.

I don't, but I enjoy a lot of perks that I would not get anywhere else. Thats why I stay. Basically work when I want, where I want. 100% remote if I choose to do so. Very flexible days off (maybe that's also why I am contacted a lot during those days). Almost no meetings, and relatively good pay.

>Very flexible days off (maybe that's also why I am contacted a lot during those days).

But... That's not how days off work.

Re: Curl will not accept vulnerability reports during July 2026

#304

Post by zvr »

jayd16 wrote: post #249
nicbou wrote: post #58

Earlier quoted context omitted.

One of the reasons I left North America for Europe is that such things are normalised. The cultural difference is staggering. In Germany, if you are on vacation, you are simply not available. You are dead to the world until you return. Emails do not get read, and devices get left at the office. Another neat thing is that if you get sick on vacation, you get your vacation days back, because vacation days are for resti…

> if you get sick on vacation, you get your vacation days back, This slightly blew my American mind but it makes sense. What about getting sick on calendar holidays?

No, you don't get the holidays back -- nor do you get weekends, if you're sick.

On the other hand, I've been in a company where there were long discussions about whether the extra day on leap years is a working day or a vacation day...

Re: Curl will not accept vulnerability reports during July 2026

#305

Post by zamadatix »

rustyhancock wrote: post #182
MatthewWilkes wrote: post #23

Earlier quoted context omitted.

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.

Disclosing an actively used exploit is is usually not treated the same as a typical vulnerability report.

Re: Curl will not accept vulnerability reports during July 2026

#306

Post by niij »

swiftcoder wrote: post #225
inigyou wrote: post #210

Earlier quoted context omitted.

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

curl is only the sandbox if you don't then do anything with the byte stream. Pipe it to bash? game over Pipe it to less/more? Better hope your distro keeps those patched Open the file in a browser or PDF reader? Hey, look at all this shiny new attack surface!

curl is not anti-virus.

Re: Curl will not accept vulnerability reports during July 2026

#307

Post by bigiain »

bityard wrote: post #293
fragmede wrote: post #283

Earlier quoted context omitted.

Lawyers have a term for it, pro bono, and they do it for good causes. Turns out they're as human as software engineers.

> Turns out they're as human as software engineers. Lawyers start out as humans but something about going into law school and then private practice, and feeding them after midnight turns them into... something else entirely.

Arguably the same is true for some software engineers. One minute they're a good friend that you respect, next thing you know they're building killbots or AI non consensual porn generators or surveillance platforms that are illegal for government agencies to operate. Perhaps it happens more often to lawyers?

Re: Curl will not accept vulnerability reports during July 2026

#308

Post by bigiain »

mc32 wrote: post #219
zaphirplane wrote: post #207

Earlier quoted context omitted.

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

Plumbers are realistic and don’t live on ideals. They set their rates and set their hours. Lawyers; well if if only people behaved we could have nice things in life, but here we are with people trying to screw each other and misbehave… Digital assets or work are a bit different in that making a second copy is trivial. It’d be different if every computer in the world were bespoke and needed its own bespoke software. S…

Now I'm imagining a plumber who fixes a drain, then stands up a "fix drain as a service" website where people can put their credit cards in and their drain gets fixed remotely at effectively zero marginal cost to the plumber.

(And then, of course, the plumber gets VC money to expand the business and the drain fix becomes a drain fix subscription, and if you cancel or your credit card expires all your drains instantly block back up again.)

Re: Curl will not accept vulnerability reports during July 2026

#309

Post by inigyou »

swiftcoder wrote: post #300
inigyou wrote: post #275

Earlier quoted context omitted.

Well yeah, that's true for any sandbox. If you pipe stuff outside of the sandbox, outside of any sandbox, and run it there, then you're not running it in a sandbox.

Right, but nobody actually uses curl as the end destination, right? You use it to download something so that you can run another tool on it. And as such, you need to already be sandboxing the tool (since it processes untrusted data you received over the internet).

How would sandboxing curl help with vulnerabilities in your pdf reader?

Re: Curl will not accept vulnerability reports during July 2026

#310

Post by [deleted] »

akerl_ wrote: post #301
theandrewbailey wrote: post #192

Earlier quoted context omitted.

Here I was thinking that cURL's (non-existent) enterprise support contracts were a polite way to tell brain-dead paper pushers to GTFO: https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquir...

https://curl.se/support.html What do you mean by non-existent?

[deleted]
Post reply on HN