On Wed, Apr 15, 2015 at 8:02 AM Greg Weber <greg@gregweber.info> wrote:
On Tue, Apr 14, 2015 at 9:50 PM, Michael Snoyman <michael@snoyman.com> wrote:
Yes, I think you've summarized the security aspects of this nicely. There's also the reliability and availability guarantees we get from a distributed system, but that's outside the realm of security (unless you're talking about denial of service).

Is it possible to separate out the concept of trusted revisions from a distributed hackage (into 2 separate proposals) then?
If Hackage wanted to it could implement trusted revisions. Or some other (distributed or non-distributed) package service could implement it (as long as the installer tool knows to check for revisions there, perhaps this would be added to Chris's signing tooling).
 

It would be a fundamental shift away from how Hackage does things today. I think the necessary steps would be:

1. Hackage ships all revisions to cabal files somehow (personally, I think it should be doing this anyway).
2. We have a list of trustees who are allowed to edit metadata. The signing work already has to recapture that information for allowed uploaders since Hackage doesn't collect GPG keys
3. Every time a revision is made, the person making the revision would need to sign the new revision

I'm open to other ideas, this is just what came to mind first.

Michael