
On Wed, Apr 15, 2015 at 8:02 AM Greg Weber
On Tue, Apr 14, 2015 at 9:50 PM, Michael Snoyman
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