71–74 of 74 posts
Earlier quoted context omitted.
This is entirely reductive. I have written a substantial enough C codebase used in the real world that uses C string handling functions. I did that because the codebase needed zero dependencies other than libc. Yet as far as anyone who's looked at the code can tell, there are no vulnerabilities because I learned how to use realloc() and grow the allocation if needed before calling the string handling functions. It's…
Has the code been fuzzed and subject to static analysis as well?
I use scan-build, but I also used to use Coverity until they had that vulnerability a few months back.
[1]: https://git.yzena.com/gavin/bc/src/branch/master/manuals/dev...
Earlier quoted context omitted.
> The vulnerability would be buried. Greg is extremely, consistently reluctant to issue CVEs without security engineers bending over backwards. From https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-... I'd paraphrase his philosophy as kernel developers should fix bugs (without requiring they be security-related or worrying about CVE assignment), users should run a recent stable/long-term kernel.
LTS is a noble effort but leaves quite a lot to be desired, and doesn't really change the fact that Greg (and others) have multiple decades of history hiding vulns and pushing back on CVEs.
Earlier quoted context omitted.
LTS is a noble effort but leaves quite a lot to be desired, and doesn't really change the fact that Greg (and others) have multiple decades of history hiding vulns and pushing back on CVEs.
Have you watched the talk? Greg talks a lot about the flaws with CVEs.