> 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!
It supports almost every file-related networking protocol under the sun and a few more just for fun. (https://everything.curl.dev/protocols/curl.html)
Meanwhile 99.8% of users (assuming) just use it for HTTP.
Here's a few complex protocols I bet many do not know that curl supports:
- SMB
- IMAP
- LDAP
- RTMP
- RTSP
- SFTP
- SMTP
At the very least, this magnifies the cost of dealing with AI slop security reports and sometimes also the risk for users.