[StilesCrisis]

Chromium is pretty aggressively fuzzed. There aren't a lot of dark corners that can't be reached via a sufficiently aggressive fuzzer.

[anematode]

Not sure about that one. Fuzzers have a hard time creating certain narrow preconditions that a manual review can find.

[bastawhiz]

Google, to their credit, has invested a TON of money into both manual review and also fuzzers. Every major fuzzing project I've read about in the last few years has been at least funded in part by Google.

[UncleMeat]

They’ve gotten way better at this over the last decade with coverage guided execution.

[anematode]

Well, yes and no. For example, coverage-guided fuzzers won't reliably find the taken branch in

  if (hash(x) == 0x12345678) {

  }

Of course this is contrived, but you can imagine something similar where it requires a delicate setup for that branch to be taken at all, that a human (or these days, an LLM) can find straightforwardly.

[yalok]

is Google using LLM-guided fuzzers that can inspect the code first?

[elternal_love]

Short answer: no. Long answer: There is a lot of Research about fuzzing, and there is a lot of incremental progress. We are not even at half here...

[qingcharles]

That's true, but isn't Chromium one of the largest and most complicated code bases in history? If you removed the drivers from Linux, which probably 99.9% aren't used in any specific hardware, then Chromium is far more LOC than the Linux kernel core even.

[Imustaskforhelp]

Chromium has so many LOC's of code and so much large in their size that it bypasses github limits.

What I mean by this is that github has a limit (in my understanding) on the sizes of public repos.

Chromium bypasses that & this is the reason why if you fork Chromium, you can get unlimited storage in github iirc

Github gets to start really wonky when you do this tho (iirc)

I can be wrong, I usually am but wanted to share this fact to just share the absurd scale of how large chromium is.