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

[Mathieu Boespflug]

> Now, if I get it right, you want to allow anyone to upload foo-1.0.1
> to hackage and let user sort it out if he trusts this update. It will
> never work: for all we know about security, when asked "do you trust
> this package's signature?" user will either get annoyed, shrug and
> click "Yes", or if paranoid, get annoyed and go away. He is just does
> not know enough to make decisions you are asking him to make. And
> adding vector implementation with something malicious in it's build
> script just became a matter of "cabal upload".
> If you build such a system, you have to provide it with reasonable set
> of defaults, and it is where "we are in business of key distribution"
> thing raises its head again.

The above all sounds reasonable to me. Note however that, not that I'm
convinced that this is a good default, but the default here could well
be: "trust whatever was added to the notepad by Hackage on behalf of
some authenticated user". That gets us back to today's status quo. We
can do better of course, but just to say that this "notepad" can be
completely transparent to end users, depending only on tooling. One
way to know what is added by Hackage is to have Hackage sign whatever
it writes in the notepad, using some key or certificate that the
tooling trusts by default.

That's really the baseline. As I said, we can do much better. At least
with the central notepad approach, we're pushing policy about what
packages to trust down to end user tooling, which can be swapped in
and out at will, without having some central entity dictate a weaker
and redundant policy.

I agree with Gershom's sentiment that the policy for what to trust
should be left open. It should be left up to the user. One family of
policies, already discussed in this thread, is a GPG WoT. That family
of policies may or may not fly for all users, I don't know, but at
least the tooling for that already exists, and it's easy to put in
place. Another family is implementations of The Update Framework
suggested by Duncan here:

https://groups.google.com/d/msg/commercialhaskell/qEEJT2LDTMU/_uj0v5PbIA8J

I'm told others are working along similar lines. It'd be great if
those people came out of the woodwork to talk about what they're doing
in the open. And since clearly there's interest in safer package
distribution, formulate proposals with a comment about how it fares to
address a specific threat model, such as the 9 attacks listed in this
paper (same authors as links posted previously in this thread twice):

ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf

That list of attacks is a superset of the attacks listed by Michael
previously. Not all policies will address all attacks in a way that's
entirely satisfactory, but at least with the central notepad we can
easily evolve them over time.