We discussed this on IRC yesterday and I think Sune also agreed that this
would be a good idea. We already expand ui.username.

Fixed by http://hg.intevation.org/mercurial/crew/rev/7c9beccb0533
Martin Geisler <mg@aragost.com>
url: expand vars in all [auth] settings (issue2328)

Fixed by http://hg.intevation.org/mercurial/crew/rev/11035185b619
Martin Geisler <mg@aragost.com>
url: expand vars in all [auth] settings (issue2328)

--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:11 EDT  ---

This bug was previously known as _bug_ 2328 at http://mercurial.selenic.com/bts/issue2328

Again hg doesn't expand the environment variables in the auth.prefix.password section in the file .hgrc. Below you can see that although evironment variables are set and $U variable is working, 'hg pull' uses "$X" password literally and not "my_password" from the $X variable. 

# hg --version | head -n 1
Mercurial Distributed SCM (version 2.3.2)

$ cat ~/.hgrc
[auth]
test.prefix = *
test.username = $U
test.password = $X
test.schemes = https http

$ export U=my_user X=my_password
$ echo $X
my_password
aust bin $ echo $U
my_user

$ hg --debug pull
using http://hg.local/test
sending capabilities command
using auth.test.* for authentication
http auth: user my_user, password **
http auth: user my_user, password **
http auth: user my_user, password **
http auth: user my_user, password **
http auth: user my_user, password **
http auth: user my_user, password **
abort: authorization failed

It looks like this behavior was somewhat reverted shortly after that commit was made:

> changeset:   12049:e329c250b0ba
> branch:      stable
> user:        Martin Geisler <mg@aragost.com>
> date:        Fri Aug 13 10:53:10 2010 +0200
> files:       doc/hgrc.5.txt mercurial/url.py
> description:
> url: limit expansion to safe auth keys (Issue2328)
>
> Mads Kiilerich pointed out that 7c9beccb0533 was too eager since the
> prefix and password keys may contain $-signs. So this only add the
> username to the list of keys that are expanded.
>
> This also updates the documentation to match.

Now only username, cert, and key are expanded.

Martin, do you think it's worth supporting this use case?

What if these would be expanded:

auth.password = $X
auth.password = "$X"

And this would not:

auth.password = '$X'

Then it could be possible to use passwords that contain '$' char.

Second solution, for compatibility with existing configs, is to expand only strings in auth.password that start with '$', and not to expand if '$' is not the first symbol.

(In reply to comment #6)

I'm not sure we can do this in a backwards compatible way? Today, you can quote strings with nothing, single, or double quotes and they're all parsed the same. So some people might have passwords with dollor signs and they may have used any of the three kinds of quotes.

I think it's unlikely we'll fix this. If someone wants to argue for it further, please take it to the mailing list.