On Thu, 30 Jan 2014 22:01:18 +0000 Matt matt@pagan.io wrote:
Here is one of the Mumble developers' take on the issue:
I don't know where @zanethomas's post went, but I just want to clarify what needs to be done here, and what's wrong.
By default, Qt's proxy support can route hostname resolution through the proxy if a hostname is used when creating the socket.
However, in Mumble, we use QHostAddress to resolve addresses ahead of time in a lot of places (for example, the server list), which causes the DNS requests to not go through the proxy.
We need some kind of abstraction on top of QHostAddress that allows us to route the hostname lookups via the user's selected proxy. That, or we need to upstream a Qt patch that allows QHostAddress to resolve through the application's QNetworkProxy.
...Something along those lines.
Matt, What are you thinking about this?
On Thu, Feb 6, 2014 at 6:06 PM, Matt matt@pagan.io wrote:
On Thu, 30 Jan 2014 22:01:18 +0000 Matt matt@pagan.io wrote:
Here is one of the Mumble developers' take on the issue:
I don't know where @zanethomas's post went, but I just want to clarify what needs to be done here, and what's wrong.
By default, Qt's proxy support can route hostname resolution through the proxy if a hostname is used when creating the socket.
However, in Mumble, we use QHostAddress to resolve addresses ahead of time in a lot of places (for example, the server list), which causes the DNS requests to not go through the proxy.
We need some kind of abstraction on top of QHostAddress that allows us to route the hostname lookups via the user's selected proxy. That, or we need to upstream a Qt patch that allows QHostAddress to resolve through the application's QNetworkProxy.
...Something along those lines.
Source: https://github.com/mumble-voip/mumble/issues/1033 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Andrew F -
Matt