That process should include signing commits by *two developers*. This is really not a lot of work as a code-review is already done, but more significantly helps fend off a lot of compromised repository issues.
There are just a few simple rules to follow: Review the commit on your own equipment, and sign it. That way an attacker will have to compromise two physically different repositories.
.
http://mikegerwitz.com/docs/git-horror-story.html
This is a change that doesn't need any new development, just a procedure change.
Wrt Hackage, simply signing packages is going to improve things, but what would be way more awesome would be to have multiple people sign off on the difference between two releases.
What I mean is that whenever somebody reviews a new release of some package (the diff from a previous release), the work they did should ideally be represented as a signature on that release, or the "commit" that is the diff between the two releases. Git can handle this sort of trust issues, but a simple signature scheme will not.
Now if a large security-conscious corporation starts using packages from Hackage, they will already have a security team that does code reviews. With a simple signature scheme, the output from their security team will not be possible to use on Hackage.
I for one would be much more likely to trust packages signed by the signature by someone who has found numerous security flaws in various packages on Hackage, than some random developer. One signature might mean "this is my release, if you trust my machine,repository, +++". Another signature might mean "the security team of X Corp has done a security review at level Y. This is cleared for production use.". Simply supporting the first signature is no good.
So if we really want to fix this, I suggest moving a large part of the trust infrastructure off of hackage and into git or similar systems that have better support for dealing with trust.