hackage, cabal-get, and security

[Isaac Jones]

"S. Alexander Jacobson" <alex at alexjacobson.com> writes:

> My solution in SearchPath (released yesterday) is to rely on a
> combination of HTTPS and links.
>
> The user selects module directories that they trust.  They access that
> directory via HTTPS.  The module directory maps module names to
> package/module URLs.  The user can decide that they only want to
> retrieve via HTTPS.

Since I believe your model is destributed, there aren't any attacks
between the packager and the server.  Well, there are, of course (how
does the packager get the package onto their web site) but that's
outside your system, so that's fine.

I'm not sure how you handle "hijacking" of a package.  I'm guessing
you leave it up to the end user to decide who the real maintainer of
the package is.

> This is effectively a web of trust model, but the only key management
> needed is getting an SSL cert from a CA like Verisign or Thawte.

How does one generate a signed SSL certificate?  It's very costly,
isn't it?

> The open question here is whether it is easier to convince people to
> serve modules via HTTPS web servers or whether they prefer gnupg key
> management. A reason to believe that the former will be preferable to
> the later is that people can easily delegate SSL hosting to
> others. Delegating gnupg key management is non-trivial.

I'm not sure how delegating comes into it; maybe another way to say
this is that getting https working properly is so hard that you have
to get someone else to do it ;)

I wanted hackage to have a pretty secure chain between the packager
and the end-user, without the need for outside sysadmins, outside CAs,
or outside methods for moving the package to the web server.

The "web of identity / trust" would be much better if we had an
official central authority like a CA, though, rather than an ad-hoc
one.

peace,

  isaac