Hmm, after thinking some more, I think there is a missing link where we rely only on CAs - at least with nix flakes, you have to trust that github.com is actually serving the real nixpkgs repository whenever you nix flake update.
If that is MITM’d, nix will blindly trust any hashes served up by the attacker in subsequent builds, and users would be unlikely to spot the changes (unless they think it’s weird that a package that usually doesn’t build is building, but that also just happens from time to time if hydra fails). Package signatures are irrelevant in this case, because nix will never download anything from the cache here, it just runs a build.
Debian doesn’t rely on this trust, since an impersonator could not provide correct signatures for any substituted packages, unless the initial installation was compromised and included false certificates, and it won’t just build stuff it cannot substitute, but that seems much more prone to being discovered.
I have to admit that I never looked closely enough at how nix channels are hosted to know if there are other signatures there, but I don’t believe there are.
This isn’t a weakness in the same vein as what we’d usually consider in the context of build security and reproducibility, so I can see how this would be overlooked, or hand-waved as “we can trust CAs”. Commit signatures could indeed help mitigate such an attack. Maybe this is what @SpiderUnderUrBed means?
I’ve never been involved in whatever groups consider the threat model for NixOS, so I might be missing details, but I do know that there’s a general assumption that GitHub is not malicious.