How I, a beginner developer, read the tutorial you, a developer, wrote for me (anniemueller.com) 09:27  ↑ 106 HN Points

Errate mithilfe von 4 historischen Ereignissen das gesuchte Jahr. Ein von Wordle und Geschichten aus der Geschichte inspiriertes Spiel.

<p>I have talked about old curl bugs before, but now we have a new curl record.</p> <p>When we announced the security flaw <a href="https://curl.se/docs/CVE-2024-11053.html">CVE-2024-11053</a> on December 11, 2024 together with the release of <a data-id="26066" data-type="post" href="https://daniel.haxx.se/blog/2024/12/11/curl-8-11-1/">curl 8.11.1</a> we fixed a security bug that was introduced in a curl release <strong>9039</strong> days ago. That is close to twenty-five years.</p> <p>The previous record holder was <a href="https://curl.se/docs/CVE-2022-35252.html">CVE-2022-35252</a> at 8729 days.</p> <p>Now at <a href="https://curl.se/docs/security.html">161 reported CVEs</a>, the <em>median</em> time a security problem has existed in curl until fixed is <strong>2583</strong> days, a little over seven years.</p> <h2 class="wp-block-heading">Age</h2> <p>We know the age of every single curl security problem because every time we have a confirmed one, I spend a significant time and effort digging through the source code history to figure out in which exact commit the problem was introduced.</p> <p>(This is also how we know that almost every CVE we have ever announced was introduced by <em>my</em> mistakes.)</p> <h2 class="wp-block-heading">What’s Wrong?</h2> <p>I don’t think anyone is doing anything wrong here. I think it illustrates the difficulty and challenges involved. There are a lot of people looking at curl code all the time. We run tests and analyzers on the code, all the time. In fact, in November 2024 alone, we had CI jobs running on GitHub alone at 9.17 CPU days per day. Meaning that on average more than nine machines were running curl tests and builds to help us verify that it works as intended.</p> <p>Apart from that, we of course have all the human individual testers, security researchers and the Google OSS-Fuzz project that are fuzzing curl non-stop and have been doing so for the last 6-7 years.</p> <p><em>Security is hard.</em> I mean really really hard.</p> <p>I have no immediate ideas how to find the next such bug other than the plain old: add more test cases for scenarios and setups not previously tested. That is hard, difficult and quite frankly quite boring work that nobody in particular wants to do nor fund someone else to do.</p> <h2 class="wp-block-heading">Enough eyeballs</h2> <p>I think we all agree by now that not all bugs are shallow. Or perhaps we can’t ever truly get enough eyeballs. Or maybe the saying works, just that it needs an addendum</p> <p class="has-text-align-center"><em>Given enough eyeballs <strong>and time</strong>, all bugs are shallow</em></p> <h2 class="wp-block-heading">Learn from each mistake</h2> <p>It is often said, and it is true, that you learn from mistakes. The question is only what exactly to learn from each and every reported security vulnerability. Each new one always feels like a unique stupid mistake that was a one-off that <em>surely</em> will not happen again because that situation is now gone and we have no other like that.</p> <h2 class="wp-block-heading">Not a C mistake</h2> <p>Let me also touch this subject while talking security problems. This bug, the oldest so far in curl history, was a plain logic error and would not have been avoided had we used another language than C.</p> <p>Otherwise, about 40% of all security problems in curl can be blamed on us using C instead of a memory-safe language. 50% of the high/critical severity ones.</p> <p>Almost all of those C mistakes were done before there even existed a viable alternative language – if that even exists now.</p> <h2 class="wp-block-heading">Graphs</h2> <p>I decided to not sprinkle graph images in the post this time. You can find data and graphs for all my claims in here in the <a href="https://curl.se/dashboard.html">curl dashboard</a>.</p>