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

261–270 of 326 posts

Re: Curl will not accept vulnerability reports during July 2026

#261

Post by patmorgan23 »

abc123abc123 wrote: post #155
plantain wrote: post #83

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.

Kinda like how the aerospace industry basically shuts down for the month of December.

Re: Curl will not accept vulnerability reports during July 2026

#262

Post by necovek »

swiftcoder wrote: post #178
spiffyk wrote: 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)...

I believe both are valid: sometimes upstreams are not set up for donations, and sometimes your org will make it easier to submit a patch or to financially sponsor a maintainer.

Re: Curl will not accept vulnerability reports during July 2026

#263

Post by akerl_ »

MatthewWilkes wrote: post #23
rustyhancock wrote: post #15

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.

Reminder that what you're describing is "coordinated disclosure", and that there are in fact plenty of people who consider "full disclosure" to be preferable in some or all cases.

Re: Curl will not accept vulnerability reports during July 2026

#264

Post by fsflover »

romaniv wrote: post #231

What this shows me (again) is that the whole system where vulnerabilities need to be constantly discovered, reported, analyzed, then patched, then the new version distributed to every singe user - again and again - is quite obviously unsustainable. The industry must come up with some alternative system for dealing with bugs and security issues. Currently the industry prefers to play dumb and turn its own failures int…

I think you're right, and the solution is security through compartmentalization. See: https://qubes-os.org.

Re: Curl will not accept vulnerability reports during July 2026

#265

Post by bluGill »

embedding-shape wrote: post #253
bluGill wrote: post #227

Earlier quoted context omitted.

In America we generally ensure there are multiple people who can do the job. Somebody can go on vacation no nobody will know because the backup is just as good. Every once in a while there is an exception. Then that guy says "If your sending me to Australia I'm going to use my vacation to scuba drive the Great Barrier Reef" - and his body is never found. True story, it took months for someone else to figure out every…

> In America we generally ensure there are multiple people who can do the job. Somebody can go on vacation no nobody will know because the backup is just as good. So every single business, everywhere in American, has at least two full-time employees or at least one other backup that is available when you want to vacation and the stores/businesses never close? I'm guessing the ones that don't have that (if they exists…

Not every single one. Most do though.

Stores remain open because they ensure somebody isn't on vacation and thus able to work. They sometimes give extra pay if you work a holiday (this is rare though - generally there is somebody who wants the hours/pay more than this holiday off - they can take time off a different day).

For small business (think a plumber) it is common to arrange a competitor who will take care of your emergency customers needs.

Re: Curl will not accept vulnerability reports during July 2026

#266

Post by altairprime »

RetroTechie wrote: post #255
altairprime wrote: post #239

Earlier quoted context omitted.

Validation, often. Stars and installs make self-worth integer go up, etc. Greed, sometimes. Gotta get those usercounts high to get acquihired / to sell out / to flip on the paid subs for formerly free features. I can’t remember the word for “prosocial through lowering cost to zero” is but sometimes that too.

> I can’t remember the word for “prosocial through lowering cost to zero” is but sometimes that too. Wiktionary: Benevolent, altruistic, unselfish, beneficent, philanthropic, selfless

Philanthropic! Thanks.

Re: Curl will not accept vulnerability reports during July 2026

#267

Post by bluGill »

Cider9986 wrote: post #52
Natsu wrote: post #29

Earlier quoted context omitted.

I worry that this will make the bad guys focus on finding zero days during the month they have free to exploit anything they find, but I don't doubt that they need a break.

Mythos found only one. Would have to be pretty serious bad guys. https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...

Remember though that many other AIs had already run and found issues that were fixed. If you had a time machine and took Mythos back a year it probably would have found a lot more. (if anyone has access to mythos it wouldn't be hard to test - download a release from last year and check)

Re: Curl will not accept vulnerability reports during July 2026

#268

Post by ryandrake »

coldpie wrote: post #240
gacgacgac wrote: post #229

Earlier quoted context omitted.

I'm a senior at a big tech company. You can do this in America too. Just communicate with your manager and set the boundary. "By the way, when I'm on vacation I'm away from devices, so let's coordinate beforehand if there's anything critical path."

100%, and it extends beyond vacations, too. Unless you have a formal on-call arrangement, then any time you spend doing work stuff outside of your work hours is time you are choosing to donate to your company. It's fine if you want to do that, but you don't have to. I work 8-4 every day. I am not contactable outside that window and definitely not contactable on my days off. I haven't worked at a ton of different plac…

In the USA at least, I've found that this kind of "not working means not available" arrangement is easier or harder based on your seniority and the kind of company you work for. I am able to hold the line on this now, 25 years into my career, but it took a long time to get to this point, and I never would have been able to swing it when I was a junior programmer, and when I was working in a hyper-work-obsessed startup.

Back in the early 2000s when I was Junior Engineer Number 32204, and not particularly valuable to my medium sized company in a competitive industry, I could never have gotten away with "Oh, by the way, boss, I am totally unreachable nights and weekends, and don't bring work with me on vacation." But, now, quite a bit more senior in my career and working in a "comfortable" big tech role, it's possible.

Re: Curl will not accept vulnerability reports during July 2026

#269

Post by lokar »

arwineap wrote: post #247
layer8 wrote: post #233

Earlier quoted context omitted.

Why would you personally need the entire internet to receive a fix?

Running a fork is a lot of work. You need your fixes upstreamed so that you don't need to backport other people's fixes

For a couple months? Not a big deal

Re: Curl will not accept vulnerability reports during July 2026

#270

Post by gpm »

jjice wrote: post #256
romaniv wrote: post #231

What this shows me (again) is that the whole system where vulnerabilities need to be constantly discovered, reported, analyzed, then patched, then the new version distributed to every singe user - again and again - is quite obviously unsustainable. The industry must come up with some alternative system for dealing with bugs and security issues. Currently the industry prefers to play dumb and turn its own failures int…

What's the better solution? Also, what's an example of this rent seeking in open source you're talking about?

> What's the better solution?

IMO Writing correct software the first time around - so formal methods.

But the tooling isn't there yet (though lightweight versions, e.g. strong type systems like rust's, are and significantly reduce the security issue load).

Post reply on HN