Making cabal-install SSL capable

[Duncan Coutts]

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.

Yeah.

> 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:

https://github.com/haskell/cabal/pull/2563

> 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
attacks).

Duncan