Making cabal-install SSL capable

Michael Snoyman michael at
Tue Apr 28 16:13:47 UTC 2015

On Tue, Apr 28, 2015 at 5:32 PM Herbert Valerio Riedel <hvriedel at>

> On 2015-04-28 at 15:50:26 +0200, Michael Snoyman wrote:
> [...]
> >> PS: We shouldn't forget that there's also an existing deployed
> >>     cabal-install user-base we can't get rid off so easily, which may
> >>     still leak unencrypted basic-auth credentials for the years to
> >>     come. Just saying...
> > I agree on that front. I think that Hackage should turn away all uploads
> > that aren't TLS-secured, and should make that change ASAP.
> Well, even if you do that, you can only reject the upload-request
> *after* the http client has already leaked the basic-auth credentials
> over a non-secured http channel... :-/
> So the only thing this measure would buy us IMHO is that CLI users would
> get an incentive to upgrade their cabal-install tooling (if they use
> e.g. `cabal upload`), but it wouldn't protect against accidentally
> falling back to an older cabal-install version picked up by accident
> (and then again compromising the credentials). I.e. this measure on its
> own wouldn't remove the unsecured basic-auth eavesdropping attack-window
> completely, only make it smaller.
> Cheers,
>   hvr

Your analysis is accurate. There are some interesting approaches we could
take to further mitigate things. For example: newer versions of
cabal-install could automatically set an incorrect username/password in the
~/.cabal/config file, and create a new set of fields
(ssl-username/ssl-password?) that it would recognize.

A more radical approach would be to have Hackage simply turn off port 80.
But that's probably too extreme; having a 301 redirect from HTTP to HTTPS
is really necessary for a good user experience, and even that redirect
would still expose the password vulnerability window.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the cabal-devel mailing list