> Isn't the scope of curl/libcurl a bit too big?

No.

From this year's curl user survey, whilst HTTP/S is the majority use, more than 10% of users are using FTP and WebSockets and 5% still using telnet!

https://curl.se/docs/survey/2025-1.1/

> The survey was announced on the curl-users and curl-library mailing lists (with reminders), numerous times on Daniel’s Mastodon (@[email protected]) on LinkedIn and on Daniel’s blog (https://daniel.haxx.se/blog). The survey was also announced on the curl web site at the top of most pages on the site that made it hard to miss for visitors.

It's not hard to imagine how that would miss the 99.x% users who just want to download an HTTP/S resource after reading an instruction on some web page.

I’m sure the case could be made before a more focussed project, but I think this is orthogonal to bad (or stupid) actors using AI to overwhelm bug reporting channels.

The issue highlighted in the article is people using AI to invent security problems that don’t exist. That doesn’t go away, no matter much you stripped down or simplify the project.

I’d bet an AI writing tool will happily generate thousands of realistic looking bug reports about a “Hello World” one-liner.

I guess you are saying that we should build another tool, or fork curl and then remove non-http stuff. Then the world should transition from curl oneliners to, say, qurl oneliners.

You can always use another library with more limited use-cases if you're worried about scope. There are thousands of libraries for making HTTP requests, many of which are language-specific and much more ergonomic than libcurl.

However, curl/libcurl would cripple itself and alienate a good portion of its userbase if it stopped supporting so many protcols, and specific features of protocols.

There's a similar argument made all the time: "I only use 10% of this software". But it doesn't mean they should get rid of the other 90% and eliminate 100% of someone else's use of 10% of the software...

And the real trouble is, there's there's no guarantee that your bargain with the devil would actually reduce the number of false reports, or reduce the time needed to determine they're false. It does not appear that the report submitters directly correlate to size of attack surface. The example AI slop includes several reports that don't even call curl code, and yet the wording claims that they do. There's no limit to the scope of bad reports!

I think there is a solid argument to be made that less than one in a thousand of curl users ever use anything besides HTTP/S.