1. When you sign a file.. oh snap. It generates a checksums and signs the checksum. That's how signing works. Thats exactly the same as what you propose. In fac

1. When you sign a file.. oh snap. It generates a checksums and signs the checksum. That's how signing works. Thats exactly the same as what you propose. In fact.. the way you propose and without a custom implementation of the signing algorithm, its generally going to generate a hash of the list of hashes and then sign that. Slower, more memory. The only advantage is if you need to remotely sign a file locally. You can gain time by not having to transfer the file if you sign only the list of hashes (and of course, you've to trust that they've been transported properly, so your trust is less perfect, because further away from the original) 2. The heuristic is the number of signatures you trust. Having thumbs up/down just makes bots happy. As for malicious merge, yes "eyeballs" are the "only decently reliable solution", but not only this is mission impossible, they'll probably still miss some smart backdoors in the code. All you need is an off by one.. (or what not..) You can however sign commits, and blame whoever introduced the issue whenever its discovered/public (and decide if it was a legit error or not) Note: its still a good idea to have automatic checks so that all the "easy stuff" is filtered out, of course.