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

Duncan Coutts duncan at well-typed.com
Thu Apr 16 12:02:31 UTC 2015


On Wed, 2015-04-15 at 00:07 -0400, Gershom B wrote:
> So I want to focus just on the idea of a “trust model” to hackage
> packages.

Good. I think TUF has a good answer here.

> Now, how does security fit into this? Well, at the moment we can
> prevent packages from being uploaded by people who are not authorized.
> And whoever is authorized is the first person who uploaded the
> package, or people they delegate to, or people otherwise added by
> hackage admins via e.g. the orphaned package takeover process.

As Michael rightly points out, though the hackage server does this, it
doesn't generate any cryptographic evidence for it. TUF solves that part
with its "target key delegation" information. It's the formal metadata
for who is allowed to upload what. So if we implement this part of TUF
then we no longer have to rely on the hackage server not getting hacked
to ensure this bit.

[...]
>  that attempts a _much simpler_ guarantee — that e.g. the person who
> signed a package as being “theirs” is either the same person that
> signed the prior version of the package, or was delegated by them (or
> hackage admins).

That's what TUF's target key system provides. There's a target key held
by the hackage admins (and signed by the root keys) that is used to sign
individual author keys and delegation information to say that this key
is allowed to sign this package.

So it's not a guarantee that the package is good, or that the author is
a sensible person, but it is formal evidence that that person should be
in the maintainer group for that package.

Then because TUF makes it this relatively lightweight it's fully
automatic for end users because the chain (not web) of trust is trivial.

> In my mind, the key elements of such a system are that it is
> orthogonal to how code is distributed and that it is opt-in/out.

Yes, our TUF adaptation for Hackage includes the author keys being
optional (and TUF is designed to be adapted in this way). Once you
opt-in for a package then the delegation information makes clear to
clients that they must expect to see an individual package signature. So
you can have a mixture of author-signed packages and not, without
downgrade attacks. The target key delegation information makes it clear.

-- 
Duncan Coutts, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/



More information about the Haskell-Cafe mailing list