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.
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.
mikegerwitz|8 years ago
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
developer2|8 years ago
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.
notacoward|8 years ago
sneak|8 years ago
The code is what we are trying to verify, not that someone claiming to be user x published it.
bitexploder|8 years ago
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.