Check package integrity by "gossiping" hashes amonst all users.

[defuse]

The AUR is insecure because the packages aren't cryptographically signed. When you're using yaourt you have to trust that the PKGBUILD is written to verify the hashes of the files it downloads, and that the hashes inside it are correct. There's a potential for getting a malicious PKGBUILD which installs malware instead of the software you wanted. This isn't yaourt's fault at all, but yaourt can do something to improve security for its users.

Imagine yaourt runs a secure internet-connected central server that stores a hash of the PKGBUILD file, the files the PKGBUILD downloads, and all of the other files that matter, for all of the packages in the AUR. These hashes would be collected in two ways: (1) The central server downloads and computes the hashes itself, and (2) The yaourt tool would by-default send the file hashes it sees as it is installing the package to the central server. If the server sees that the user got a different file hash than the server got or that lots of other users got, then it can send back a warning that the file hasn't been seen before.

This improves security because now, if someone wants to attack you by replacing your PKGBUILD with a malicious one, then they have to also compromise the yaourt server or all other yaourt users at once, which is harder to do and leaves more evidence behind and so is easier to detect, too. The central server can publish logs of all the hashes it has seen to make attacks detectable retrospectively, potentially years after they happen.

If yaourt can pull this off, it could start trend that other package installers will follow. Obviously what I've written above isn't the best and final formulation of the idea. Lots of work and security review needs to go into the design. But I'm curious: How much interest is there in a feature like this?

If there's sufficient interest, the first step is to take a look at similar things like Certificate Transparency and gather all of the lessons-learned from those designs.

[rmarquis]

While an interesting idea, this has nothing to do with yaourt which is a simple download client. If you want to set up a complete centralized server, you probably should add it along the upstream infrastructure.

[defuse]

What I'm proposing is to implement the client functionality described above in yaourt, with some other entity responsible for implementing and maintaining the central server. It's not a great separation of concerns: what should yaourt do if the people running the central server disappear or become unreliable? In other words, if the central server already existed and had a well-documented API, would this be of interest? I guess the best place to get feedback would be on one of the Arch mailing lists, not here.