Exists a opened bug report about the problem which this patch is suposed to fix: http://bugs.winehq.org/show_bug.cgi?id=5625
Can someone give some comments for what this pach wasn't applied?
Thanks, Augusto Arcoverde da Rocha
On Thu, 3 Aug 2006, Augusto Arcoverde da Rocha wrote:
Exists a opened bug report about the problem which this patch is suposed to fix: http://bugs.winehq.org/show_bug.cgi?id=5625
Can someone give some comments for what this pach wasn't applied?
As far as I can see the patch seems to assume that the $http_proxy environment variable simply contains the hostname of the proxy. But I believe that its format is more along the lines of 'http://user@hostname:port/', user and port being optional. There may also be a way to specify a password ('user%password@...'?).
On Thu, 2006-08-10 at 13:33 +0200, Francois Gouget wrote:
There may also be a way to specify a password ('user%password@...'?).
Format is: [user[:password]@]hostname[:port]
Hi,
Dimi Paun wrote:
On Thu, 2006-08-10 at 13:33 +0200, Francois Gouget wrote:
There may also be a way to specify a password ('user%password@...'?).
Format is: [user[:password]@]hostname[:port]
If I google for http_proxy, I always find this additionally prefixed by "http://". Some have even an additional slash at the end. (This is also the format which works here with Lynx and wget.)
Note that one should also support no_proxy (comma separated list of hostnames, e.g. "il" (matching e.g. ".mil" and ".il"), ".winehq.org" etc.)
Maybe ftp_proxy should be supported as well?
Tobias
Hummmm...
Then a better approach would be avoid environment variables, as this seems to be a Wine development directive, and use the right format for the proxy configuration string.
Can someone point more questions about Wine proxy configuration which could improve that patch?
Regards, Augusto Arcoverde da Rocha
Hi,
Augusto Arcoverde da Rocha wrote:
Hummmm...
Then a better approach would be avoid environment variables, as this seems to be a Wine development directive, and use the right format for the proxy configuration string.
I disagree. I think it makes sense to support general environment variables (such as http_proxy, no_proxy, EDITOR, DISPLAY, USER, HOME, BROWSER, etc.). I do agree that it make sense to keep the number of Wine specific environment variable low, though.
Currently, my http_proxy is used by wget, lynx, w3m, Firefox (SUSE build, probably not in mozilla.org's build) and some more. I thus think it should be also used by Wine. (I don't know, whether one should also support a registry string to overwrite $http_proxy.)
Tobias
On 8/10/06, Tobias Burnus burnus@gmx.de wrote:
Hi,
Augusto Arcoverde da Rocha wrote:
Hummmm...
Then a better approach would be avoid environment variables, as this seems to be a Wine development directive, and use the right format for the proxy configuration string.
I disagree. I think it makes sense to support general environment variables (such as http_proxy, no_proxy, EDITOR, DISPLAY, USER, HOME, BROWSER, etc.). I do agree that it make sense to keep the number of Wine specific environment variable low, though.
Yes, it's supported but isn't a standart and has no guaranties to exists on all architectures as Alexander said in a reply in this list (I can't remember now).
IMHO, the current password exposition is a ugly thing: $ export http_proxy=http://user:__%3E%3E**password**<<__@host.dom:8080
I think would be preferable hide the password typing and don't storing it in a file like system register, maintaining it in the memory only. Perhaps getting the password altrougt some interactive process which hide the password.
Currently, my http_proxy is used by wget, lynx, w3m, Firefox (SUSE build, probably not in mozilla.org's build) and some more. I thus think it should be also used by Wine. (I don't know, whether one should also support a registry string to overwrite $http_proxy.)
Storing the password on a file only generates more efforts and considerations about permissions and security pratices, again IMHO. But the proxy variables are practically omnipresent indeed.
Regards, Augusto Arcoverde da Rocha
Hi,
Augusto Arcoverde da Rocha schrieb:
IMHO, the current password exposition is a ugly thing: $ export http_proxy=http://user:__%3E%3E**password**<<__@host.dom:8080
I wouldn't worry to much about a PROXY password. I mean who can access files and environment variables? Basically only you and the administrator of your system.
I think the bigger problem is that guessed 99% of all proxies, which ask for passwords, transmit them in clear. (I think there is no SSL protocol or digest protocol which is widely supported.)
(Our university's computation centre offers a password-proxy access using the username/password. I'm slightly reluctant to save that password on my laptop and I'm fully against transmitting it with every HTTP request. Thus I'm using a ssh tunnel with localhost:8080 as proxy.)
I think would be preferable hide the password typing and don't storing it in a file like system register, maintaining it in the memory only. Perhaps getting the password altrougt some interactive process which hide the password.
Well, exactly that you get if you add the following into your .bashrc:
printf 'Enter Password for the HTTP PROXY: ' stty -echo read pass stty echo echo "" http_proxy="http://$USER:$pass@hostname:port/" export http_proxy
Otherwise: Many programs automatically ask for a password if protcol://user@hostname:port/ didn't succeed. (At least Mozilla does so for the proxy.) I wouldn't be surprised if the Internet Explorer did the same. (It does for ftp://foo@bar.com/).
Tobias
On Thu, 10 Aug 2006, Augusto Arcoverde da Rocha wrote: [...]
Yes, it's supported but isn't a standart and has no guaranties to exists on all architectures as Alexander said in a reply in this list
$http_proxy and $ftp_proxy may not be very well documented but they are defacto standards and as such it would be good to support them in Wine.
IMHO, the current password exposition is a ugly thing: $ export http_proxy=http://user:__%3E%3E**password**<<__@host.dom:8080
I think would be preferable hide the password typing and don't storing it in a file like system register, maintaining it in the memory only. Perhaps getting the password altrougt some interactive process which hide the password.
Storing the password in an environment variable is ok as there's no way for other users to access it. Besides, changing that would require changing the $http_proxy standard so which is a completely separate issue.
I think the important issue at hand is that currently Wine completely ignores the user's proxy settings stored in $http_proxy.
On 8/11/06, Francois Gouget fgouget@free.fr wrote:
On Thu, 10 Aug 2006, Augusto Arcoverde da Rocha wrote: [...]
Yes, it's supported but isn't a standart and has no guaranties to exists on all architectures as Alexander said in a reply in this list
$http_proxy and $ftp_proxy may not be very well documented but they are defacto standards and as such it would be good to support them in Wine.
Logicaly is almost impossible to prove the inexistence of something, however to prove the existence of something, is enough to show a single occurrence of that thing.
Then I need to ask you where is the documentation for proxy variables standards to send it to the Subversion community: http://svn.haxx.se/dev/archive-2003-07/1672.shtml
Just kidding ;P
Now, thinking better, I need to agree with those who defend the proxy environment variables on Wine, is almost a standard and is widely used. I don't see any good reasons to not support them on Wine.
But, I have read in somewhere a reply from Alexander about avoiding environment variables. However, I can't find this message again.
Regards, Augusto Arcoverde da Rocha
On Fri, 11 Aug 2006, Augusto Arcoverde da Rocha wrote: [...]
But, I have read in somewhere a reply from Alexander about avoiding environment variables. However, I can't find this message again.
Maybe you are thinking about the one in which he argues against introducing new obsucure Wine-specific environment variables. I think that was was about something like WINECONSOLEBACKEND.
But this is different since it is not about defining Wine-specific environment variables, but making good use of the ones that exist already.
-
Augusto Arcoverde da Rocha -
Dimi Paun -
Francois Gouget -
Tobias Burnus -
Tobias Burnus