I think the issue in the repo explains it pretty well: the maintainer's machines were compromised, meaning that any commit under his name could have come from an attacker. It doesn't matter how big or small the diffs are when the person in control of the repo is malicious. Even signed commits would not be safe from this unless he was using a physical signing key (e.g. a yubikey)
Perhaps I'm sorta nitpicking or being overly annoying by pointing this out, but use of a Yubikey wouldn't necessarily help if a malicious process modified the code to be submitted. They'd be signed-but-corrupted commits.
The best safety net I'm aware of is that source code and/or diffs in plaintext (not binaries) are distributed, and that recipients inspect them.
It's reasonable to distribute binaries in addition, although recipients take on risk by using those. That risk can be mitigated in the presence of source code and reproducible builds.
Despite my unbounded sense of optimism about everything in life, something makes me think there might be more situations like this ahead (it's a sign that software is being written and distributed more widely, which is good - and a sign that running tons of arbitrary code on all our machines and internetworking them all might lead to difficult-to-answer questions around compromise).
So to harness that optimism again: it's a challenge and an opportunity to build the correct collaboration and analytical tools to audit codebases quickly and effectively in a distributed environment.
