[kashyapc]

You make excellent points; I agree. Especially, a non-maintainer with a high-quality contribution gaining trust. Many times, (tired) maintainers are forced to "rubber-stamp" and merge such high-quality patches. It could be due to any number of (valid) reasons—a CVE fix, an involved performance fix that will take you weeks to load up on the context, enabling a hardware feature that's under semi-NDA, you just trust their work too well, maintainer fatigue, etc.

What I'm saying is, in context of critical-path software, the identity of maintainers vs non-maintainers matters more. I'm not naively claiming that it'll "solve" the problem at hand, just that it's another layer in defense. For a critical software, you shouldn't be able to simply submit a "patch"[1] such as:

  tests: Add-binary-blob-with-a-subtle-backdoor.xz

  Signed-off-by: "Anonymous Rabbit" <[e-mail]>

Commit it yourself, brazenly push it into Linux distros, and then anonymously sign off into the sunset with no trace. I'm sure you'll agree that there's a world of difference between a deeply entrenched, critical libray and a random user-space application.

It's a messy situation. How much, if at all, "clever tech" can mitigate this human "trust issue" is an open problem for now.

[1] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=cf44e4b7f5d