<div dir="ltr">+1. Oddly enough, I was just in the process of filing a bug report related to this on something I discovered yesterday, namely that `cabal upload` uses HTTP basic authentication over HTTP, exposing username/password to anyone sniffing the connection.<br><div><br></div><div>I offered Duncan last week that I'd port cabal-install over to http-client/http-client-tls to add SSL support. That offer still stands.</div></div><br><div class="gmail_quote">On Tue, Apr 28, 2015 at 6:55 AM Gershom B <<a href="mailto:gershomb@gmail.com">gershomb@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
However, everyone seems to agree that it would be unambiguously better if the cabal install executable were able to communicate over ssl.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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).<br>
<br>
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!<br>
<br>
—Gershom<br>
_______________________________________________<br>
cabal-devel mailing list<br>
<a href="mailto:cabal-devel@haskell.org" target="_blank">cabal-devel@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel</a><br>
</blockquote></div>