On Tue, Apr 14, 2015 at 10:08 PM, Michael Snoyman <michael@snoyman.com> wrote:


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.

Perhaps this is not really doable, but I was thinking there should be a proposal for a specification for trusted revisions. These are integration details for Hackage just as the current proposal has some implementation about a distributed package service.

I actually think the easiest way to make revisions secure with Hackage is to precisely limit what can be revised. If one can only change an upper bound of an existing dependency that greatly limits the attack vectors.