> yes it's theoretically possible to backdoor git so that it sends valid
> data to some people and invalid data to other people, but since the git
> transport layer isn't encrypted, it would be far easier to do this via a
> man-in-the-middle attack on your network than it would be to compromise
> kernel.org to do this for you.
As long as we're looking at the theoretical possibilities (can you be 100% sure you're not compromised), that argument doesn't really matter. Also, if the aim is to infect a large number of machines with a modified kernel, it certainly would make sense to use a backdoor in git on the server, instead of using a man-in-the-middle attack on a local network.
In this case I personally would be fine with running that kernel and trusting the research of the kernel.org sysadmins. However, for systems with truly critical security levels, I can imagine that's not acceptable.
I would certainly start with assuming that someone hacking kernel.org is very clever and came extremely well prepared, if only because they might have been.
Independent sources for checksums or signatures sound like a viable solution (to someone who knows very little about security or checksums). That may be worth implementing for those administrators who truly depend on 100% secure verification. As for not running make before verifying what you downloaded - that definitely sounds like the responsibility of the person downloading and building the kernel.