[Haskell-cafe] [haskell-infrastructure] Improvements to package hosting and security

[Gershom B]

On April 15, 2015 at 9:27:55 AM, Michael Snoyman (michael at snoyman.com) wrote:
> I think the above was clear enough, but in case it's not, here's an
> example. Take the yesod-core package, for which MichaelSnoyman and
> GregWeber are listed as maintainers. Suppose that we have information from
> Hackage saying:
>  
> yesod-core-1.4.0 released by MichaelSnoyman
> yesod-core-1.4.1 released by FelipeLessa
> yesod-core-1.4.2 released by GregWeber
> yesod-core-1.4.2 cabal file revision by HerbertValerioRiedel
>  
> How do I know:
>  
> * Which signatures on yesod-core-1.4.0 to trust? Should I trust
> MichaelSnoyman's and GregWeber's only? What if GregWeber wasn't a
> maintainer when 1.4.0 was released?
> * How can 1.4.1 be trusted? It was released by a non-maintainer. In
> reality, we can guess that FelipeLessa used to be a maintainer but was then
> removed, but how do we know this?
> * Similarly, we can guess that HerbertValerioRiedel is granted as a trustee
> the right to revise a cabal file.
> * But in any event: how do we get the GPG keys for any of these users?
> * And since Hackage isn't enforcing any GPG signatures, what should we do
> when the signatures for a package don't exist?
>
> This is just one example of the impediments to adding package signing to
> the current Hackage system.

None of this makes sense to me. You should trust whoever’s keys you choose to trust. That is your problem. I can’t tell you who to trust. How do you get the GPG key? Well that is also your problem. We can’t implement our own service for distributing GPG keys. That’s nuts.

Why should your trust in a package be based on if a “maintainer” or a “non-maintainer” released it? That’s a bad criteria. How can I trust 1.4.0? Perhaps somebody paid you a lot of money to insert a hole in it. I trust it if I trust _you_, not if I trust that you were listed as “maintainer” for a fragment of time.

I think you are confusing the maintainer field to mean something other than it does — which is simply the list of people authorized at some point in time to upload a package. 

In the future, we can at first optionally, and then later on a stricter basis encourage and then enforce signing. I think this is a good idea.

But, and here we apparently disagree completely, it seems to me that everything else is not and should not be the job of a centralized server.

Now, on this count:

> we have no insight right now into how Hackage makes decisions about who's allowed to upload and revise packages.

This is weird. “Hackage” doesn’t make decisions. People do. Hackage is just a program, run on a machine. It enforces permissioning. Those permissions can be viewed. So I can tell you who the trustees are, who the admins are, and who the maintainers are for any given package. If any of that information about how these permissions are granted, by whom, and when, is not logged (and some that should be currently isn’t I’ll grant) then we can amend the codebase to log it. If we wish, we can make the log verifiable via an audit trail. We can also make admin actions verifiable. This is precisely what carter proposed (with my amendment).

On

> We have no idea how to make a correspondence between a Hackage username and some externally-verifiable identity (like a GPG public key). In that world: how can we externally verify signatures of packages on Hackage?

My proposal again is simple — treat the hackage username as a convenience, not as anything fundamental to the verification model. Treat verification entirely independently. Assume I have a GPG key for Michael Snoyman. How do I know a certain version of yesod is due to him? I don’t need to ask Hackage at all. I just check that he signed it with his key. That’s all that matters, right?

—Gershom