Support HTTP authentication for updating package lists and downloading packages

[eamsden]

Users running private Hackage instances may wish to reverse proxy though a server that provides HTTP authentication. Cabal should be configurable with per-repository usernames and passwords to provide to repository servers when asked for authentication. This, in conjunction with #2760, would provide a great deal more security for users running private Hackage instances.

[23Skidoo]

Cabal should be configurable with per-repository usernames and passwords to provide to repository servers when asked for authentication.

IIRC this is implemented in HEAD.

[eamsden]

@23Skidoo can you point to a commit? I found the one for adding HTTPS support but not the one for doing auth on cabal update and downloading packages...

[23Skidoo]

I was thinking of #2627.

not the one for doing auth on cabal update and downloading packages...

Right, this is not implemented.

[eamsden]

I've opened pull request #2764 which fixes the call to wget so that passwords are not filtered from the URL. This allows the use of http-transport: wget and username/password info in the repo url. @23Skidoo would you mind looking at it and merging it?

[DemiMarie]

Sending the password in the URL is a very bad idea — much infrastructure assumes that URLs are not confidential and they are almost certain to be logged, etc. Instead, the password must be sent separately from the URL. Furthermore, sending a password over plaintext HTTP should be disabled.

[23Skidoo]

Sending the password in the URL is a very bad idea

Right. The top-level username and password fields should be deprecated and made a part of the repository section.

[ezyang]

Do we have anyone committed to making this happen for 2.0? This doesn't seem like a blocker.

[23Skidoo]

Do we have anyone committed to making this happen for 2.0?

Don't think so.

[fgaz]

Is this fixed by #7630?

[gbaz]

I think it was half-fixed already (for wget) and now that fixes it with curl, which should suffice!

Note that the above concern about passwords not getting sent in the url is fine, afaik -- i.e. they're specified in the url in the syntax, but the transport handling handles them separately.