Skip to main content


I now get to argue with a user who insists he found a security problem in curl because

curl_mfprintf(stdout, "%x %x %x %x");

reads bad memory.

Never a dull moment.

in reply to TTimo

@TTimo in a way yes, in another way no. In the 90s there really was not a lot of alternatives.
in reply to daniel:// stenberg://

I will admit that adding this function to the library API was a bad idea, but that's a decision we are stuck with through the decades since we don't break the ABI
in reply to daniel:// stenberg://

I almost asked if you had written about ABI stability ... before realizing I mistyped my google query and then I discovered you wrote a *length* about it. For anyone coming who is similarly curious, this is the blog entry @bagder wrote last week about ABI breakages, which I missed:

daniel.haxx.se/blog/2024/10/30…

Thank you for sharing your thoughts on this.

daniel:// stenberg:// reshared this.

in reply to daniel:// stenberg://

return -2?

Or have you looked into #pragma warning stuff to warn on deprecated interfaces?

Can't support the ABI in infinity...

in reply to daniel:// stenberg://

maybe consider adding a "regrets=no" flag (defaulting to yes) that fixes regrets that would break the ABI?
in reply to daniel:// stenberg://

Seriously! :blobthinkingeyes: I always thought that it was very ingenious, way of handling things. Then How would you structure curl differently? if you were to do it all over again?
This entry was edited (2 weeks ago)
in reply to daniel:// stenberg://

The docs (curl.se/libcurl/c/curl_mprintf…) state:

"We discourage users from using any of these functions in new applications."

Maybe it could be stronger? Perhaps:

> "These functions are deprecated, but not removed due to ABI backwards compatibility. We STRONGLY discourage anyone from using these functions in new applications, and encourage existing uses to move to <SUGGESTION>. No bug reports, security or otherwise, will be accepted against these functions."

in reply to daniel:// stenberg://

CURL* uninit_1;
CURLoption uninit2;
char* uninit_3;
curl_easy_setopt(uninit_1, uninit_2, uninit_3);

Very unsafe API, much bug bounty received. Right?

in reply to daniel:// stenberg://

now this report is disclosed: hackerone.com/reports/2819666

For educational purposes

in reply to daniel:// stenberg://

That "Additionally, I have another topic I would like to discuss, and here it is.", followed by nothing, almost tastes like an LLM wrote (parts) of the text.
in reply to Bredroll

@Bredroll I suppose when you don't quite understand what you are talking about and you really want to claim an issue and get a reward?
in reply to daniel:// stenberg://

I suppose it also potentially tells us about thier attitude to compiler warnings and undefined behaviour..