"This experience has unfortunately made me reconsider my support for curl"
I'm sorry you feel that way, but you need to realize your own role here. We receive AI slop like this regularly and at volume. You contribute to unnecessary load of curl maintainers and I refuse to take that lightly and I am determined to act swiftly against it. Now and going forward.
(cont)
You submitted what seems to be an obvious AI slop "report" where you say there is a security problem, probably because an AI tricked you into believing this. You then waste our time by not telling us that an AI did this for you and you then continue the discussion with even more crap responses - seemingly also generated by AI.
(cont)
By all means, use AI to learn things and to figure out potential problems, but when you just blindly assume that a silly tool is automatically right just because it sounds plausible, then you're doing us all (the curl project, the world, the open source community) a huge disservice. You should have studied the claim and verified it before you reported it. You should have told us an AI reported this to you.
(cont)
What tells me this is AI slop;
1. The wall of text that is too long and unspecific, talking about a potential problem
2. The over-politeness when asked to clarify and provide more info. Humans rarely speak like that.
3. The inability to become specific when asked. It can't point out the flaw exactly, because it does not actually know about any flaw.
(cont)
I'm sorry you feel less enthusiastic about curl now because of this. I hope you after some time in a future will come to reassess what happened here and maybe even understand why we act the way we do.
Now, let's go back to improving curl.
Thanks
@bagder and (without following this specific encounter) the obvious: The way the reporter allegedly changed their opinion on curl should have been a change of opinion on LLMs and "AI".
Yes, there was disappointment and as a result frustration. But please, attribute it to the actual source, namely the tool having generated the slop report and not to the messenger or even the expert, telling you the report is slop.
@bagder yes, exactly. And that's perfectly normal.
It's IMHO also normal, that it's really hard to redirect this disappointment/frustration/pain towards the actual source. Both as the person friendly and cautiously doing it, as well as the person (forcefully) having to re-evaluate their choices.
And usually, denial is the easiest way out. I just hope that one day, it will get better and people start face their own mistakes.
This is something that I admire with the people around curl: Trying to cultivate a culture in which it's okay that mistakes happen, must be fixed and can be learned from.
## Summary: The vulnerability in the program arises from a classic buffer overflow, triggered by the unsafe use of the strcpy() function without bounds checking. The program copies data from a source buffer to a destination buffer, allowing attackers to overflow the buffer if the input string exceeds the buffer's allocated size. This vulnerability can lead to the overwriting of critical memory,...
@bagder @kyle_pegasus Gotcha, no worries Daniel, this is educational enough, thanks!
Also, thanks for all of the work you've done on curl! I genuinely had no idea it was maintained by such a small team before; really reminds me of that XKCD where 90% of the internet relies on some open source project that someone has been thanklessly maintaining, haha.
Hope you enjoy the rest of your day! 
daniel:// stenberg://
Peter Schmidt
gclef
Nils Ballmann
Kyle
NeoFox