Making cabal-install SSL capable

Duncan Coutts duncan.coutts at
Tue Apr 28 14:58:36 UTC 2015

On Mon, 2015-04-27 at 23:55 -0400, Gershom B wrote:
> So there are many discussions over various hackage security schemes,
> and there are a variety of takes on the different elements of how we
> could make package distribution more secure.
> However, everyone seems to agree that it would be unambiguously better
> if the cabal install executable were able to communicate over ssl.


> I looked at the previous discussion on this topic [1], and it seems
> that HsOpenSSL and tls were both considered. I don’t have any
> experience with how cross-platform compatible HsOpenSSL is (i.e. if it
> is sufficiently easy to use for both Windows and OS X that we can just
> encourage people to “cabal install cabal-install” and things will just
> work). I don’t know if anyone else can speak to this? Furthermore, of
> course, redistributing cabal-install binaries could potentially be
> more of a pain with links to external c libraries. I’m not quite sure
> how much an issue this would be. Meanwhile, tls is certainly
> cross-platform, but there is the question about how trustworthy it is,
> as it is not nearly as widely used and vetted as openssl.

Right. I don't have any great suggestion there. This is what has
prevented us getting anywhere in the past.

> Also, we have the option of simply shelling out to curl, wget, or the
> appropriate powershell command (on windows 7 or above you get those by
> default).

I think that's quite a reasonable 90% solution. I was looking at
implementing this the other day after talking about it with Michael.
When looking at the code I noticed (as did Michael) that rather
embarrassingly the current code is actually using basic auth, when it
should have been using digest auth. I've sent a PR:

> So rather than rely on either HsOpenSSL or tls, we could also teach
> cabal to probe for one of the appropriate executables on first run,
> save that configuration, and warn if no such executable is available
> (allowing the user to fall back to http with warnings indefinitely).

I don't even think it needs any saved configuration. Cabal is pretty
good at probing for and running exes.

> I would like to pursue getting SSL into cabal by any of these three
> avenues. What do people feel about the relative tradeoffs of these
> options? Honestly, I lean towards simply using the tls package,
> because https is ultimately only going to be a complimentary aspect of
> our security architecture plans and not central to it. And a
> pure-haskell dependency is the most logical approach. If people find
> too much fault with that approach, I would be inclined to shell out as
> the next option, with HsOpenSSL as the last option only because I
> worry about too many “unknown unknowns” of the sort I listed above.
> But if others have more experience with these approaches, proposals
> are welcome!

My suggestion is that in the short term we use an external curl binary
if it happens to be available, and fallback to digest auth if not.
If/when we are in a position to have dependencies on decent http(s)
libraries then we should use those.

Also, for those users without curl (or without an HTTPS-enabled
version), the digest auth can be improved. We can use digest auth with
the "auth-int" QoP, which includes replay protection and integrity
protection of the message body (ie the .tar.gz). It's not as good as
TLS, but digest auth (with "auth" or "auth-int" QoP) isn't actually
known to be broken yet. (It's an oldish standard that relies on MD5, but
has both server and client nonces to protect against chosen plaintext


More information about the cabal-devel mailing list