Now, if I get it right, you want to allow anyone to upload foo-1.0.1 to hackage and let user sort it out if he trusts this update. It will never work: for all we know about security, when asked "do you trust this package's signature?" user will either get annoyed, shrug and click "Yes", or if paranoid, get annoyed and go away. He is just does not know enough to make decisions you are asking him to make. And adding vector implementation with something malicious in it's build script just became a matter of "cabal upload". If you build such a system, you have to provide it with reasonable set of defaults, and it is where "we are in business of key distribution" thing raises its head again.
The above all sounds reasonable to me. Note however that, not that I'm convinced that this is a good default, but the default here could well be: "trust whatever was added to the notepad by Hackage on behalf of some authenticated user". That gets us back to today's status quo. We can do better of course, but just to say that this "notepad" can be completely transparent to end users, depending only on tooling. One way to know what is added by Hackage is to have Hackage sign whatever it writes in the notepad, using some key or certificate that the tooling trusts by default. That's really the baseline. As I said, we can do much better. At least with the central notepad approach, we're pushing policy about what packages to trust down to end user tooling, which can be swapped in and out at will, without having some central entity dictate a weaker and redundant policy. I agree with Gershom's sentiment that the policy for what to trust should be left open. It should be left up to the user. One family of policies, already discussed in this thread, is a GPG WoT. That family of policies may or may not fly for all users, I don't know, but at least the tooling for that already exists, and it's easy to put in place. Another family is implementations of The Update Framework suggested by Duncan here: https://groups.google.com/d/msg/commercialhaskell/qEEJT2LDTMU/_uj0v5PbIA8J I'm told others are working along similar lines. It'd be great if those people came out of the woodwork to talk about what they're doing in the open. And since clearly there's interest in safer package distribution, formulate proposals with a comment about how it fares to address a specific threat model, such as the 9 attacks listed in this paper (same authors as links posted previously in this thread twice): ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf That list of attacks is a superset of the attacks listed by Michael previously. Not all policies will address all attacks in a way that's entirely satisfactory, but at least with the central notepad we can easily evolve them over time.