On 2015-04-28 at 18:13:47 +0200, Michael Snoyman wrote:

[...]

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

Now that you mention that; the typical default config entry looks like:

  remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive

For a TLS-capable cabal-install (for which I'll assume it'll use digest-auth), I'd suggest (as a strawman proposal -
so please criticize!) that it

 a) when creating a default-config, write

    remote-repo: hackage.haskell.org:https://hackage.haskell.org/packages/archive

 b) if a cabal upload operation is performed,

      1) if remote-repo points to a http:// url, Warn the user in a
         visible scary way that can't easily be ignored that he/she
         should switch to a https:// url; however,
         proceed w/ the requested operation using digest-auth

      2) if remote-repo points to a https:// url, operate w/o warning
         (could use basic-auth instead of digest-auth, if we wanted to
         avoid an additional round-trip at the HTTP-layer)

 c) for non-authorised operations, emit less-scary warnings as a
    friendly reminder to update the repo-url to a https:// capable one

So once a the cabal-config file points to a https://,  url, the risk of
older non-TLS-capable cabal-installs leaking credentials via unencrypted
HTTP would be solved (at the expense of older cabal-install versions not
being able to communicate via https:// urls at all...)


Cheers,
  hvr