On Wed, Apr 15, 2015 at 8:02 AM Greg Weber <[email protected]> wrote:
> On Tue, Apr 14, 2015 at 9:50 PM, Michael Snoyman <[email protected]> > 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
_______________________________________________ haskell-infrastructure mailing list [email protected] http://community.galois.com/mailman/listinfo/haskell-infrastructure
