News for hackers. Stuff that matters.
Re:Why Package Signing is not the Holy Grail by zobzu on Wednesday July 24, 2013 @03:00AM (#6094838)
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.

Re:Why Package Signing is not the Holy Grail by donaldstufft on Wednesday July 24, 2013 @03:29AM (#6094905)
There's a difference between signing a tarball in it's entirety (in which case you'd get only one checksum) and checksumming every file inside the tarball and then signing that file.
Re:Why Package Signing is not the Holy Grail by zobzu on Sunday August 04, 2013 @08:25PM (#6157723)
How do you think gpg works?