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

251–260 of 326 posts

Re: Curl will not accept vulnerability reports during July 2026

#251

Post by [deleted] »

spiffyk wrote: post #186
swiftcoder wrote: post #178

Earlier quoted context omitted.

> 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)...

Fair, but it is less of a burden than just submitting a report with no proposed fix. Also, submitting quality patches regularly seems to be a good way to eventually become a maintainer, provided that both sides are interested (cURL generally is – at least that seemed to be the vibe at the last year's cURL Up event I attended).

[deleted]

Re: Curl will not accept vulnerability reports during July 2026

#252

Post by steveklabnik »

colinsane wrote: post #248
dxxvi wrote: post #174

Today 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?

curl used to have rust in it, dropped it 1.5 yrs ago. AI doesn't help with the hard parts here i don't think. https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/

They dropped the hyper backend, but that wasn’t the only Rust code in tree.

Re: Curl will not accept vulnerability reports during July 2026

#253

Post by embedding-shape »

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

Earlier quoted context omitted.

> That is not ignoring but announcing a delay. 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?

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), just never have vacation, or how does that work? Sounds like a fever-dream, but I guess if that's what your experience tells you.

Re: Curl will not accept vulnerability reports during July 2026

#254

Post by IshKebab »

megous wrote: post #218
IshKebab wrote: post #77

Earlier 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.

Yes, you can maintain your fork for perpetuity if you can't/will not get your changes upstream. Why is that a problem? If you're using any complicated FOSS professionally and you have SLA with your customers to say fix issues within day or two you don't have a choice anyway.

> Why is that a problem?

Because it's a ton of unnecessary work. And because of the other reasons I said.

> If you're using any complicated FOSS professionally and you have SLA with your customers to say fix issues within day or two you don't have a choice anyway.

This is true. I always try to upstream patches anyway though.

Re: Curl will not accept vulnerability reports during July 2026

#255

Post by RetroTechie »

altairprime wrote: post #239
t-writescode wrote: post #140

Earlier quoted context omitted.

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?

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

Re: Curl will not accept vulnerability reports during July 2026

#256

Post by jjice »

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?

Re: Curl will not accept vulnerability reports during July 2026

#257

Post by necovek »

IshKebab wrote: post #254
megous wrote: post #218

Earlier quoted context omitted.

Yes, you can maintain your fork for perpetuity if you can't/will not get your changes upstream. Why is that a problem? If you're using any complicated FOSS professionally and you have SLA with your customers to say fix issues within day or two you don't have a choice anyway.

> Why is that a problem? Because it's a ton of unnecessary work. And because of the other reasons I said. > If you're using any complicated FOSS professionally and you have SLA with your customers to say fix issues within day or two you don't have a choice anyway. This is true. I always try to upstream patches anyway though.

How do you define unnecessary work if this is... necessary for you?

You are already benefiting from getting the tool/library/system for free, so you can still compare writing the thing you need (necessary?) from scratch or adapting the FOSS solution — maintenance comes with both options.

When you invest enough and are lucky, someone else might just fix the thing for you or pick it up and maintain it for you — but do not count on it, and you are good.

Re: Curl will not accept vulnerability reports during July 2026

#258

Post by necovek »

IshKebab wrote: post #77
necovek wrote: post #22

Earlier quoted context omitted.

You'd be surprised to learn this about free and open source software, but if a maintainer is unavailable, you have both full rights and full source code to... wait for it... fix it yourself (or pay someone to)! There is something unhealthy in this relationship only if you project "no warranty" into unrealistic expectations.

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.

We are talking about a case when maintainer is unavailable to do the work: what would happen if this was a proprietary dependency and the maintainer is gone (eg. bankrupt, moved on, incapacitated...)?

There is nothing unusual about this, businesses face this all the time, the only difference is that you do have some agency with FOSS.

What's the alternative when it is not FOSS? Eg. build it yourself from scratch (and maintain it too), or move to a competing product.

Re: Curl will not accept vulnerability reports during July 2026

#260

Post by oasisbob »

patates wrote: 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…

Lock-out vacations were one of my favorite things about being at a bank. Auditors cared about the ability for employees to keep a thumb on the scale, so it was a policy requirement that all workers with a certain amount of access needed to take an uninterrupted vacation of N days, with login ability disabled.

Fantastic tool for shaking out hidden bus factors.

Post reply on HN