4 ms·

Curl seems to becoming one of the favourite things to demo AI finding vulns. Curl is going to end up incredibly secure.

by graemep 1mo ago

pixl97 1mo ago
Thank goodness because curl is a load bearing structure to the backend of the internet.
bluGill 1mo ago
Curl has a well earned reputation for high quality code. If you find something there it means you are good. There is a lot of software where finding a vulnerability mostly means you bothered to look and are not completely stupid. Nobody is going to be impressed if you find an issue with something that everybody already knows is poorly coded.
- mynameisash 1mo ago
  > Curl has a well earned reputation for high quality code. SQLite also has a very good reputation. I vaguely recall hearing about one SQLite vulnerability discovered via AI, but I thought it turned out to be a nothingburger. A quick search turned up CVE-2025-6965[0,1], published on 2025-07-15, which affects SQLite < 3.50.2 (versions published before 2025-05-29[2]). I'm not much of a security nerd, but my naive reading of this implies that it was already known and fixed as of the time of the CVE; in other words, the AI discovery didn't seem particularly helpful (though one could argue that it did successfully discover a CVE). Has AI found many/any other vulnerabilities in SQLite? [0] https://cybersecuritynews.com/sqlite-0-day-vulnerability/ https://cybersecuritynews.com/sqlite-0-day-vulnerability/ [1] https://nvd.nist.gov/vuln/detail/cve-2025-6965 https://nvd.nist.gov/vuln/detail/cve-2025-6965 [2] https://sqlite.org/releaselog/3_50_2.html https://sqlite.org/releaselog/3_50_2.html
  - bluGill 1mo ago
    Hard to say what AI has been used in SQLite unless someone is talking. My impression is the maintainer doesn't talk about this type of thing much, but maybe I'm wrong.
  - selicos 1mo ago
    Tailscale worked with them on an issue they found, not a vulnerability: https://tailscale.com/blog/sqlite-wal-reset-bug https://tailscale.com/blog/sqlite-wal-reset-bug
- crote 1mo ago
  Its vulnerability overview page[0] also helpfully lists which were caused by the use of C. The fact that even an extremely-high-quality codebase like Curl is still encountering things like use-after-free issues is pretty damning for the people clamoring that it is perfectly possible for skilled programmers to write safe C. If even Daniel Stenberg can't consistently write safe C code, I think we can assume that nobody can. Either you switch to a memory-safe language like Rust, or you adopt a high-cost runtime checker like Fil-C, or you'll have to live with a never-ending series of memory safety vulnerabilities. [0]: https://curl.se/docs/security.html https://curl.se/docs/security.html
  - eviks 1mo ago
    Where is your extreme assessment coming from?
    - crote 1mo ago
      It isn't very extreme, in my opinion. I am only making one claim, and it's a rather modest one: Memory safety bugs aren't any different from other bugs. The "you're holding it wrong" crowd has been claiming that memory safety bugs are a skill issue for ages now, and that the issue is overblown and can be solved by having programmers suck less. Curl provides the counterexample to this. Its main developer seems to be quite skilled, as reiterated by the various AI audits it is a very solid codebase, yet it still suffers from memory safety vulnerabilities. If the "you're holding it wrong" crowd is right, we're faced with a contradiction. Is Curl secretly a poor-quality codebase which has managed to fool the community until now? Is Daniel Stenberg uniquely susceptible to writing memory safety bugs, negating his otherwise-seemingly-decent programming skills? Is he perhaps intentionally introducing memory safety bugs to make C look bad? In other words: if memory safety bugs are indeed a different breed altogether and are completely avoidable if we try hard enough, why are they still hitting Curl? I posit that they are not: if you are writing unsafe code, you will introduce memory safety bugs. You can avoid them altogether by switching to inherently-safe languages like Go or Kotlin, by catching them at compile time like Rust, or by catching them at runtime like Fil-C. Or you can ignore the problem altogether and keep writing C like we've been doing for decades, but that means you will keep shipping memory safety vulnerabilities - like we've been doing for decades.
floxy 1mo ago
Anyone care to guesstimate how much effort there would be in creating an actually-secure curl and openssl? Using something like Common Lisp or Lean, instead of C.

Curl seems to becoming one of the favourite things to demo AI finding vulns. Curl is going to end up incredibly secure.

by graemep 1mo ago

Curl seems to becoming one of the favourite things to demo AI finding vulns. Curl is going to end up incredibly secure.

pixl97 1mo ago

Thank goodness because curl is a load bearing structure to the backend of the internet.

bluGill 1mo ago

Curl has a well earned reputation for high quality code. If you find something there it means you are good. There is a lot of software where finding a vulnerability mostly means you bothered to look and are not completely stupid. Nobody is going to be impressed if you find an issue with something that everybody already knows is poorly coded.

mynameisash 1mo ago
> Curl has a well earned reputation for high quality code. SQLite also has a very good reputation. I vaguely recall hearing about one SQLite vulnerability discovered via AI, but I thought it turned out to be a nothingburger. A quick search turned up CVE-2025-6965[0,1], published on 2025-07-15, which affects SQLite < 3.50.2 (versions published before 2025-05-29[2]). I'm not much of a security nerd, but my naive reading of this implies that it was already known and fixed as of the time of the CVE; in other words, the AI discovery didn't seem particularly helpful (though one could argue that it did successfully discover a CVE). Has AI found many/any other vulnerabilities in SQLite? [0] https://cybersecuritynews.com/sqlite-0-day-vulnerability/ https://cybersecuritynews.com/sqlite-0-day-vulnerability/ [1] https://nvd.nist.gov/vuln/detail/cve-2025-6965 https://nvd.nist.gov/vuln/detail/cve-2025-6965 [2] https://sqlite.org/releaselog/3_50_2.html https://sqlite.org/releaselog/3_50_2.html
- bluGill 1mo ago
  Hard to say what AI has been used in SQLite unless someone is talking. My impression is the maintainer doesn't talk about this type of thing much, but maybe I'm wrong.
- selicos 1mo ago
  Tailscale worked with them on an issue they found, not a vulnerability: https://tailscale.com/blog/sqlite-wal-reset-bug https://tailscale.com/blog/sqlite-wal-reset-bug
crote 1mo ago
Its vulnerability overview page[0] also helpfully lists which were caused by the use of C. The fact that even an extremely-high-quality codebase like Curl is still encountering things like use-after-free issues is pretty damning for the people clamoring that it is perfectly possible for skilled programmers to write safe C. If even Daniel Stenberg can't consistently write safe C code, I think we can assume that nobody can. Either you switch to a memory-safe language like Rust, or you adopt a high-cost runtime checker like Fil-C, or you'll have to live with a never-ending series of memory safety vulnerabilities. [0]: https://curl.se/docs/security.html https://curl.se/docs/security.html
- eviks 1mo ago
  Where is your extreme assessment coming from?
  - crote 1mo ago
    It isn't very extreme, in my opinion. I am only making one claim, and it's a rather modest one: Memory safety bugs aren't any different from other bugs. The "you're holding it wrong" crowd has been claiming that memory safety bugs are a skill issue for ages now, and that the issue is overblown and can be solved by having programmers suck less. Curl provides the counterexample to this. Its main developer seems to be quite skilled, as reiterated by the various AI audits it is a very solid codebase, yet it still suffers from memory safety vulnerabilities. If the "you're holding it wrong" crowd is right, we're faced with a contradiction. Is Curl secretly a poor-quality codebase which has managed to fool the community until now? Is Daniel Stenberg uniquely susceptible to writing memory safety bugs, negating his otherwise-seemingly-decent programming skills? Is he perhaps intentionally introducing memory safety bugs to make C look bad? In other words: if memory safety bugs are indeed a different breed altogether and are completely avoidable if we try hard enough, why are they still hitting Curl? I posit that they are not: if you are writing unsafe code, you will introduce memory safety bugs. You can avoid them altogether by switching to inherently-safe languages like Go or Kotlin, by catching them at compile time like Rust, or by catching them at runtime like Fil-C. Or you can ignore the problem altogether and keep writing C like we've been doing for decades, but that means you will keep shipping memory safety vulnerabilities - like we've been doing for decades.

floxy 1mo ago

Anyone care to guesstimate how much effort there would be in creating an actually-secure curl and openssl? Using something like Common Lisp or Lean, instead of C.