Comment by zdw | Hacker News Reader

Comment by zdw | Hacker News Reader

Two comments:

1. Signing should be different from source integrity. For example, signing the manifest that contains a bunch of hashes should be sufficient - you don't necessarily need to sign the entire compressed package. Newer package management systems like the Illumos IPS work this way (which is not without it's faults). The veneration of the "church of tarball" needs to go away - we've been living in a DVCS world for the past few years and it's awesome compared to the dark ages of before.

2. We need some sort of heuristics to help make decisions. For example - a diff between versions is much easier to audit, and having statistics on contributors might be quite useful. For example, red flags might go up if a previously slow moving project had a massive number of commits with a new developer - this might just be new blood getting into a project, or a maliciously intended merge.

In the end, eyeballs are needed. We need to make it easier for those eyeballs to go further on less.

1. Yes absolutely. I tried to not talk about specific signing implementations because this was mostly about that simply signing isn't enough, you need a trust model.

2. I'm actually a PyPI admin, a pip core developer, and one of the folks working in the python packaging space. This sort of heuristics is something I absolutely want to add. Right now I'm mostly focused on closing huge gaps in security wise (prior to 1.3.x pip downloaded everything over HTTP, PyPI did not have a trusted SSL cert, etc). But Yes! Making it easier for eyeballs is a good thing.

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.

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.

How do you think gpg works?

having statistics on contributors might be quite useful.

So you are proposing harvesting & storing stats on contributors indefinitely to help track down criminal intent? This sounds familiar.

Reply on news.ycombinator.com