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 _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
