the heap overflow I reported to skerry, and why @kernel_karl is the gold standard

since this topic is usually about maintainers behaving badly or companies being awful, here is the opposite, because it deserves saying out loud.

last year I was fuzzing C JSON parsers for fun (yes, that is my idea of fun) and I found a heap buffer overflow in skerry, the little parser Karl maintains and that, as his bio says, half your companies vendor and never thank. a malformed deeply nested input could write past the end of a buffer. the kind of thing that is a crash at best and worse at worst, and skerry is embedded in a LOT of places.

I emailed Karl privately with a minimal reproducer and an asan trace. here is what "responsible maintainer" looks like, for the companies reading who think an unpaid Swede owes them a 24 hour SLA:

• 4 hours later: a reply. not "thanks we take security seriously", an actual reply with the exact line of code and why the bounds check was off by one.
• same night: a patch on a private branch, with a new fuzzing test case built from my reproducer so it can never come back.
• next morning: a CVE requested, a coordinated date set, and a credit line with my handle spelled correctly, which never happens.
• he asked ME when I wanted it public, not the other way around.

this is a man with two co-maintainers and zero budget doing textbook coordinated disclosure in an evening, for free, better than vendors with a security team and a bug bounty platform. the difference is not money. it is that he actually reads his inbox and cares about the thing he made.

so the next time a maintainer is "slow" on your issue, remember most of them are doing this after their day job and their kids are asleep. Karl, I still owe you a beer. the overflow was a good one though, admit it.