Commit signing can help to mitigate that.[0] Note that GitHub now offers the ability to add your GPG public key to your profile and show whether a commit is signed with that key or not. I find this more dangerous than useful: if an attacker compromises the account and adds his/her key, and adds a malicious commit, GitHub would show it as verified.
Do you know how the signing requirements work on GitHub when accepting a pull request on a repo requiring signed commits, when the pull request is from a fork where someone is not signing their commits? Must the commit to the fork be signed in order for the pull request to be merged, or is it possible for the main repo to merge an unsigned commit while signing it themselves in the process?
I can see requiring every commit on the primary repo to be signed, but it's a larger nightmare to accept pull requests from forks if they are also forced to sign their commits.
What's ultimately important for trust is that the maintainers (or whomever you are to trust) sign commits. They may choose to pass this responsibility down the line a bit (e.g. how Linus has his "lieutenants"), but if some random contributor does or does not sign a commit, do we care? Are they in the maintainers' web of trust? What benefit does verifying their identity actually have with respect for the project?
So in that case, a maintainer may decide to just review the patches and sign the merge commit.
That contributor may want to _assert_ their identity---e.g. have their signed commit committed to the repository to show that they actually did that work---but that's a different issue.
There are several reasons, but not specifically to do with code signing. Code in a distro repo has been at least cursorily checked to make sure the install script (or "scriptlets" in something like an RPM specfile) doesn't do anything awful. Some of that's automated, some of it's manual, but at least it's there. An exploit would have to get past both the author and the distro gatekeepers to become operative. With code on GitHub, it only has to get past the committer - who might, unlike distro packagers, be totally clueless about security or even basic bash-scripting safety rules. That's just too easy IMO.
That is basically the same as trusting `apt install`. We just hope apt repo maintainers have higher levels of opsec.
Most trust on a typical Ubuntu install, for example, is still chained back to an TLS download of an ISO (or maybe torrent file). That bootstraps your repo public keys.
I have done this before. But if you are actually MiTM downloading the GPG sums from the same source as your ISO is a little pointless. That is the problem, how do you bootstrap the trust? It all still just goes back to TLS and the CA.
You can check the sums over time and acquire them using multiple connections to verify they are all the same to gain a higher level of confidence, but this is actually annoying for someone with a high level of technical skill and basically impossible for most people. I only do this for things that require the highest levels of operational security, like, say, if I am setting up a system to sign certificates in a CA or something.
A slightly easier approach is to strip down your CAs to a bare minimum in your browser config, and double check the certificates being presented on TLS download sites. You can still be owned by a MiTM if the CAs actively collude with a nation state and have given them signing keys, but... there isn't much to do about that. The options really aren't that great in terms of really verifying things.
https://github.com/blog/1068-public-key-security-vulnerabili...
Commit signing can help to mitigate that.[0] Note that GitHub now offers the ability to add your GPG public key to your profile and show whether a commit is signed with that key or not. I find this more dangerous than useful: if an attacker compromises the account and adds his/her key, and adds a malicious commit, GitHub would show it as verified.
[0]: https://mikegerwitz.com/papers/git-horror-story