Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#11110 closed defect (fixed)

Pidgin appears to leak DNS for Jabber accounts

Reported by: ioerror Owned by: deryni
Milestone: 2.8.0 Component: XMPP
Version: Keywords: jabber security privacy
Cc: schwindp

Description (last modified by ioerror)

While sniffing my local network connection (wlan0) to debug a network failure, I found that when I start pidgin, it leaks DNS for two jabber accounts. Here's the text summary of a packet dump performed by Wireshark:

1 0.000000 192.168.1.35 89.150.129.4 DNS Standard query SRV _xmpp-client._tcp.jabber.ccc.de

2 0.033425 89.150.129.4 192.168.1.35 DNS Standard query response SRV 5 0 5222 jabberd.jabber.ccc.de

3 3.035413 192.168.1.35 89.150.129.4 DNS Standard query AAAA stun.l.google.com

4 3.066871 89.150.129.4 192.168.1.35 DNS Standard query response

5 3.066973 192.168.1.35 89.150.129.4 DNS Standard query AAAA stun.l.google.com

6 3.098772 89.150.129.4 192.168.1.35 DNS Standard query response

7 3.098836 192.168.1.35 89.150.129.4 DNS Standard query A stun.l.google.com

8 3.131653 89.150.129.4 192.168.1.35 DNS Standard query response A 209.85.229.126

9 6.186464 192.168.1.35 89.150.129.4 DNS Standard query SRV _stun._udp.jabber.ccc.de

10 6.231383 89.150.129.4 192.168.1.35 DNS Standard query response, No such name

I use a different SOCKS5 proxy for each of my IM accounts; I have various protocols enabled and each of them appears to work perfectly (aim/yahoo/msn/jabber/etc). Each of my SOCKS5 proxies is a local proxy (ssh or other tunnels) listening on 127.0.0.1 on some specific port. I expect Pidgin to only speak to these proxies. I do not trust my local network not to forge DNS replies and I do not want people to know where I am connecting when I use a proxy (my proxies are encrypted tunnels).

Specifically, I have two accounts configured as XMPP accounts; both of them are configured to talk to a specific SOCKS5 proxy on 127.0.0.1. Both google and the jabber.ccc.de server allow open registration and it should be trivial to reproduce this DNS leak.

This is for Pidgin 2.6.4 (libpurple 2.6.4) - 3c54c32773c1f4469b35603025eb4516315aebf0

Attachments (7)

jabber-dns-leak.pcap (269 bytes) - added by ioerror 9 years ago.
Jabber DNS leak packet capture
libpurple-proxy.h.patch (539 bytes) - added by ioerror 8 years ago.
configure.ac-hardening.patch (1.7 KB) - added by ioerror 8 years ago.
Screenshot-Modify_Account-pristine-00.png (270.1 KB) - added by ioerror 8 years ago.
Screenshot-Modify_Account-pristine-01.png (256.1 KB) - added by ioerror 8 years ago.
Screenshot-Modify_Account-enum-relocated-00.png (25.4 KB) - added by ioerror 8 years ago.
Screenshot-Modify_Account-enum-relocated-01.png (289.8 KB) - added by ioerror 8 years ago.

Download all attachments as: .zip

Change History (69)

Changed 9 years ago by ioerror

Jabber DNS leak packet capture

comment:1 Changed 9 years ago by ioerror

  • Description modified (diff)

comment:2 Changed 9 years ago by ioerror

I've attached a pcap file for a jabber.org DNS leak.

comment:3 follow-up: Changed 9 years ago by datallah

  • Status changed from new to pending

It isn't going to be possible to do a SRV request through your SOCKS5 tunnel.

You can avoid the SRV request by specifying the connect server to the appropriate value in the "Advanced" section of your XMPP account.

comment:4 Changed 9 years ago by ioerror

  • Status changed from pending to new

It appears that the leak is in libpurble/protocols/jabber.c

Suspect calls appear to be on line 683: »···»···»···try_srv_connect(js);

And also on 686-687: »···»···»···js->srv_query_data = purple_txt_resolve("_xmppconnect", »···»···»···»···»···js->user->domain, txt_resolved_cb, js);

It appears that try_srv_connect() will eventually fall back to the defaults: »···/* Fall back to the defaults (I'm not sure if we should actually do this) */ »···jabber_login_connect(js, js->user->domain, js->user->domain, »···»···»···purple_account_get_int(purple_connection_get_account(js->gc), "port", 5222), »···»···»···TRUE);

I think if there's a proxy configured for a jabber account, it might make sense to simply do this in the first place. It seems unlikely that any SOCKS proxies will support SRV or TXT records in the near future. It might make sense to allow a user to fill in those responses manually if they know them (and they're not often changing)...

It may be prudent to check for a proxy in jabber_stream_connect() and to alert the user that this isn't a possible working combination.

comment:5 Changed 9 years ago by datallah

Without the SRV lookup (if there is no Connect Server specified manually), it isn't possible to connect to many XMPP accounts (including Google Talk).

comment:6 in reply to: ↑ 3 Changed 9 years ago by ioerror

Replying to datallah:

It isn't going to be possible to do a SRV request through your SOCKS5 tunnel.

You can avoid the SRV request by specifying the connect server to the appropriate value in the "Advanced" section of your XMPP account.

In both XMPP accounts (at the time of bug filing), I had (and still have) the entire advanced tab filled in (excepting the BOSH URL field) with server information. It makes these SRV (and AAAA) DNS requests either way.

comment:7 Changed 9 years ago by ioerror

I spent a little more time looking at the call graph manually. It does look like jabber_stream_connect() will call jabber_login_connect() if connect_server[0] isn't empty (this somehow should be expressed to the user, I think).

In any case, that will only skip the first possible SRV record resolution attempt. Eventually the flow of execution will hit jabber_login_callback() and *possibly* trigger the above mentioned SRV requests. However, this doesn't appear to be the source of my leaking. Still, it seems fragile and should be more explicit, I think.

It looks like js->stun_query is probably closer to the root of the issue. I think that at some point in the call graph, pidgin thinks that it needs to make a DNS query for an STUN server. It looks like purple_network_set_stun_server() (line 867 of libpurple/network.c) will make a call to purple_dnsquery_a(). This is invoked by purple_network_init() and so it's likely the source of the leak for people without every tab (other than the BOSH field) in the advanced tab filled in...

comment:8 Changed 9 years ago by ioerror

It's also likely to be a leak for people with every field on the advanced tab filled in.

comment:9 Changed 9 years ago by ioerror

Ironically, when I try to set my global STUN server to '127.0.0.1', pidgin will make a SRV query:

845 24.742391 192.168.1.35 89.150.129.4 DNS Standard query SRV _stun._udp.127.0.0.1

With this global STUN server configured, each account will still make their own STUN related SRV queries. :-(

comment:10 Changed 9 years ago by malu@…

  • Milestone set to 2.6.6
  • Resolution set to fixed
  • Status changed from new to closed

(In 6e11e232a469bd7bd1f5c8dadebcfa5809eb1cd1):
jabber: Only make the SRV lookup for STUN based on the domain if no STUN server is set in prefs. Closes #11110

comment:11 follow-up: Changed 9 years ago by kjo

There is still a DNS leak with XMPP accounts in the following case:

  • setup an XMPP account whith a SOCKS5 local proxy as described above
  • disconnect from the network, e.g. by unpligging ethernet cable
  • reconnect e.g. by replugging ethernet cable

Pidgin then automagically reconnects to the accounts, but leaks these requests:

IP localhost.58656 > nameserver.domain: 21791+ TXT? _xmppconnect.domain.tld. (53)
IP localhost.50104 > nameserver.domain: 21791+ TXT? _xmppconnect.domain.tld. (53)

comment:12 in reply to: ↑ 11 ; follow-up: Changed 9 years ago by datallah

Replying to kjo:

There is still a DNS leak with XMPP accounts in the following case:

  • setup an XMPP account whith a SOCKS5 local proxy as described above
  • disconnect from the network, e.g. by unpligging ethernet cable
  • reconnect e.g. by replugging ethernet cable

Pidgin then automagically reconnects to the accounts, but leaks these requests:

Look carefully at the backlog of this ticket. Some of these "leaks" are unavoidable and are not bugs.

comment:13 in reply to: ↑ 12 Changed 9 years ago by kjo

Look carefully at the backlog of this ticket. Some of these "leaks" are unavoidable and are not bugs.

I read the above thread, and I think that these leaks are bugs

It isn't going to be possible to do a SRV request through your SOCKS5 tunnel.

You can avoid the SRV request by specifying the connect server to the appropriate value in the "Advanced" section of your XMPP account.

I specified the "connect server" in the advanced section of the XMPP account, so the _xmppconnect requests seems useless to me. During normal connection (not a reconnection after network loss) pidgin connects to the account without making any DNS request outside the SOCKS5 proxy.

I think that at some point in the call graph, pidgin thinks that it needs to make a DNS query for an STUN server.

A also have a global STUN server set to "localhost" in the global preferences, as well as a "pile transfer proxies" set to "localhost" in the XMPP account preferences.

Did I miss something?

comment:14 Changed 9 years ago by datallah

I think what you're seeing is a timing issue.

When connecting directly fails, the _xmppconnect TXT record lookup occurs to see if alternative connection methods are available.

You'll see a "Couldn't connect directly to %s. Trying to find alternative connection methods, like BOSH.\n" message in the debug log when this is happening.

comment:15 Changed 8 years ago by ioerror

This bug is not fixed as long as there are DNS leaks.

Can someone please re-open it? I'm not able to re-open the bug myself.

comment:16 Changed 8 years ago by bleeter

  • Milestone changed from 2.6.6 to Implementation In Progress
  • Resolution fixed deleted
  • Status changed from closed to new
  • Version 2.6.4 deleted

I think given the message in the debug log above ('Trying to find alternative connection'), what Pidgin should be capable of doing is to NOT attempt find alternative connections if the original connection fails. I'll set up my development environment over the next day or two and see if I can bang out some kind of temporary fix (short of re-engineering all lookups and connections, etc.)

comment:17 Changed 8 years ago by ioerror

Tor has been working a bit on this bug: https://trac.torproject.org/projects/tor/ticket/1676

comment:18 Changed 8 years ago by bleeter

Apologies for not updating recently.

What's probably more of an effective workaround would be a plugin that overrides all DNS queries so that they only get sent to the proxy. I can imagine certain situations where people wouldn't really mind if DNS is done away from the proxy as well as where they'd mind if it is. A plugin override could therefore provide control without having to go waist deep inside core and all prpl's for code checking. That'd offer a far more complete workaround than patching on one prpl.

It was when I had this realisation that my quick and dirty hopes fell apart.

Thoughts?

comment:19 Changed 8 years ago by ioerror

I'd be open to such a plugin and I'm actually working on a configure flag that will simply override all known libc or otherwise DNS related function calls. That will solve the issues that we have for the TIMBB where we ship Pidgin as a component as we can easily build the binary. Sadly, this approach will not work for anyone else unless a vendor also builds with such a flag and there is no reason to enable such a flag by default...

I'm not sure that I'm up for writing an entire plugin to solve this problem in the next few days; I'm happy to share whatever hacks I create though.

comment:20 Changed 8 years ago by ioerror

I've written a patch for jabber.{c,h} - it's a pretty small patch though I wonder if proxy_in_use() is better abstracted into libpurple?

I've put the code here: https://trac.torproject.org/projects/tor/attachment/ticket/1676/

Thoughts?

This fixes all of the DNS leaks mentioned in this bug.

comment:21 Changed 8 years ago by ioerror

proxy_in_use() may be useful in general for all protocols but I'm not sure of the general way that I should abstract it.

comment:22 Changed 8 years ago by datallah

This patch will prevent connections in the default configuration to e.g. GTalk for any users who use a proxy (the SRV lookup is necessary).

I think it's a much better idea to make a plugin override purple_srv_txt_query_set_ui_ops(), to provide a dummy implementation.

comment:23 Changed 8 years ago by ioerror

Right - that's the idea - if I'm using Google Talk with Tor, which I am - I don't want to do a SRV lookup. It is not safe.

I want to be told that the connection fails with my proxy because it does not support SRV lookups. I expect that pidgin may want to warn me about a need to fill in the advanced tab by hand or something similar. Otherwise, I will leak information that allows someone to perform a MITM attack on me or worse.

I don't see how a plugin will change this behavior?

comment:24 follow-up: Changed 8 years ago by datallah

Right, your patch does what you want for your particular situation, but it isn't going to be an acceptable thing to do in libpurple by default - in most proxy cases, the right thing to do *is* going to be the SRV lookup.

The proposed plugin solution will bypass SRV/TXT lookups and make it seem to the code that initiates the lookup that no results were returned. If implemented correctly, it should have the same effect as changing the code like you're doing, but will apply to all places where the dns requests are made.

comment:25 in reply to: ↑ 24 ; follow-up: Changed 8 years ago by ioerror

Replying to datallah:

Right, your patch does what you want for your particular situation, but it isn't going to be an acceptable thing to do in libpurple by default - in most proxy cases, the right thing to do *is* going to be the SRV lookup.

Hrm - how are you deciding that? Isn't this bug report a record of a bunch of users asking that this dangerous default behavior be changed? And also that they're surprised by this default behavior?

The proposed plugin solution will bypass SRV/TXT lookups and make it seem to the code that initiates the lookup that no results were returned. If implemented correctly, it should have the same effect as changing the code like you're doing, but will apply to all places where the dns requests are made.

Will this plugin be enabled by default when you use a proxy? If not, pidgin will leak information to the network that allows an attacker to violate client privacy and reroute client destination traffic. If so - why implement it as a plugin?

I admit, I'm new to pidgin internals, so I'm really not sure of why you'd make this choice over another. The idea of having it apply everywhere is a much better solution, I agree - I'm actually undertaking an audit of each protocol ( https://trac.torproject.org/projects/tor/ticket/2918 ) that we want to support in TIMBB. None the less - I'm confused how normal users using a normal pidgin proxy setting will be protected from DNS leaking security and privacy issues?

Perhaps it would make sense to have a preference where we "allow DNS requests to bypass proxy settings" in the proxy dialog? And perhaps that would be implemented by a plugin that is enabled by default unless you check that box?

comment:26 in reply to: ↑ 25 ; follow-up: Changed 8 years ago by datallah

Replying to ioerror:

Replying to datallah:

Right, your patch does what you want for your particular situation, but it isn't going to be an acceptable thing to do in libpurple by default - in most proxy cases, the right thing to do *is* going to be the SRV lookup.

Hrm - how are you deciding that? Isn't this bug report a record of a bunch of users asking that this dangerous default behavior be changed? And also that they're surprised by this default behavior?

The vast majority of proxy usage isn't by people looking for "anonymity" - it is people with a restricted network network of some variety (frequently a corporate network) and they need to use a proxy (usually provided by the network administrator) to be able to access external resources.

Most people don't care that their ISP can see what they attempt to connect to. If e.g. GTalk (or many other XMPP services) didn't work out of the box because we didn't do SRV lookups, there would be a orders of magnitude more people complaining about that - there are already are lots of people who seek support because they use a broken DNS server that doesn't do SRV.

The proposed plugin solution will bypass SRV/TXT lookups and make it seem to the code that initiates the lookup that no results were returned. If implemented correctly, it should have the same effect as changing the code like you're doing, but will apply to all places where the dns requests are made.

Will this plugin be enabled by default when you use a proxy? If not, pidgin will leak information to the network that allows an attacker to violate client privacy and reroute client destination traffic. If so - why implement it as a plugin?

No, of course it won't be enabled by default. It isn't even clear that the plugin would be distributed with Pidgin at all (it could be though). It would be a plugin because it's hack - you'd be (intentionally) crippling libpurple.

I admit, I'm new to pidgin internals, so I'm really not sure of why you'd make this choice over another. The idea of having it apply everywhere is a much better solution, I agree - I'm actually undertaking an audit of each protocol ( https://trac.torproject.org/projects/tor/ticket/2918 ) that we want to support in TIMBB. None the less - I'm confused how normal users using a normal pidgin proxy setting will be protected from DNS leaking security and privacy issues?

This plugin would be something that presumably you would ship with your "TIMBB" (I'm not sure that that actually is anyway) and could be enabled by default in that setup.

Perhaps it would make sense to have a preference where we "allow DNS requests to bypass proxy settings" in the proxy dialog? And perhaps that would be implemented by a plugin that is enabled by default unless you check that box?

If it was a checkbox, in the preferences, then it likely wouldn't be a plugin.

I think that the biggest confusion here is that you're assuming that "proxy" == "anonymizing proxy".

I would certainly agree that there should be a way to use Pidgin in such a way that doesn't leak information for those who want to use it with something like Tor and can follow instructions on how to set it up correctly, but it shouldn't be at the cost of support for the more common use cases.

comment:27 in reply to: ↑ 26 ; follow-up: Changed 8 years ago by ioerror

Replying to datallah:

Replying to ioerror:

Replying to datallah:

Right, your patch does what you want for your particular situation, but it isn't going to be an acceptable thing to do in libpurple by default - in most proxy cases, the right thing to do *is* going to be the SRV lookup.

Hrm - how are you deciding that? Isn't this bug report a record of a bunch of users asking that this dangerous default behavior be changed? And also that they're surprised by this default behavior?

The vast majority of proxy usage isn't by people looking for "anonymity" - it is people with a restricted network network of some variety (frequently a corporate network) and they need to use a proxy (usually provided by the network administrator) to be able to access external resources.

Right and often this includes local DNS filtering, monitoring or even simply a mis-functioning DNS resolver of some kind.

Most people don't care that their ISP can see what they attempt to connect to. If e.g. GTalk (or many other XMPP services) didn't work out of the box because we didn't do SRV lookups, there would be a orders of magnitude more people complaining about that - there are already are lots of people who seek support because they use a broken DNS server that doesn't do SRV.

This is an odd one - you guys already fixed *some* of these issues. My fix only impacts people who add a proxy, so it's actually not a perfect fix but it should not impact anyone by default. How many users even set proxies? Are the people who set proxies really unwilling to learn that their proxies reduce functionality? How has that been determined?

The proposed plugin solution will bypass SRV/TXT lookups and make it seem to the code that initiates the lookup that no results were returned. If implemented correctly, it should have the same effect as changing the code like you're doing, but will apply to all places where the dns requests are made.

Will this plugin be enabled by default when you use a proxy? If not, pidgin will leak information to the network that allows an attacker to violate client privacy and reroute client destination traffic. If so - why implement it as a plugin?

No, of course it won't be enabled by default. It isn't even clear that the plugin would be distributed with Pidgin at all (it could be though). It would be a plugin because it's hack - you'd be (intentionally) crippling libpurple.

Well, I would say that currently there is a security and privacy problem in libpurple. So regardless of how we find a solution, currently libpurple isn't suitable for anyone who needs to use pidgin for circumvention (Tor, OpenSSH) or anonymity (Tor) or simply as a way to securely forward at conferences (OpenSSH or other SOCKS proxies).

I admit, I'm new to pidgin internals, so I'm really not sure of why you'd make this choice over another. The idea of having it apply everywhere is a much better solution, I agree - I'm actually undertaking an audit of each protocol ( https://trac.torproject.org/projects/tor/ticket/2918 ) that we want to support in TIMBB. None the less - I'm confused how normal users using a normal pidgin proxy setting will be protected from DNS leaking security and privacy issues?

This plugin would be something that presumably you would ship with your "TIMBB" (I'm not sure that that actually is anyway) and could be enabled by default in that setup.

Oh, sorry. Tor IM Browser Bundle. It's a totally configured IM/Browser setup that uses Tor.

Perhaps it would make sense to have a preference where we "allow DNS requests to bypass proxy settings" in the proxy dialog? And perhaps that would be implemented by a plugin that is enabled by default unless you check that box?

If it was a checkbox, in the preferences, then it likely wouldn't be a plugin.

Ok. Would you be interested in a checkbox?

I think that the biggest confusion here is that you're assuming that "proxy" == "anonymizing proxy".

I'm not assuming anonymizing proxy. I'm assuming that when a user says they wish to proxy their traffic relating to an account, they proxy the traffic related to that account. All of it. If you're using an SSH tunnel, it isn't about anonymity, it may just be about the local network being unsafe. Think Firesheep or dsniff, etc.

I would certainly agree that there should be a way to use Pidgin in such a way that doesn't leak information for those who want to use it with something like Tor and can follow instructions on how to set it up correctly, but it shouldn't be at the cost of support for the more common use cases.

Great. My main concern is that it should not be an add on that no one will use or an option that is disabled by default in an already advanced tab.

I think a DNS related checkbox in the proxy widget might make sense over a plugin.

comment:28 in reply to: ↑ 27 Changed 8 years ago by datallah

Replying to ioerror:

Replying to datallah:

Replying to ioerror:

Replying to datallah:

Right, your patch does what you want for your particular situation, but it isn't going to be an acceptable thing to do in libpurple by default - in most proxy cases, the right thing to do *is* going to be the SRV lookup.

Hrm - how are you deciding that? Isn't this bug report a record of a bunch of users asking that this dangerous default behavior be changed? And also that they're surprised by this default behavior?

The vast majority of proxy usage isn't by people looking for "anonymity" - it is people with a restricted network network of some variety (frequently a corporate network) and they need to use a proxy (usually provided by the network administrator) to be able to access external resources.

Right and often this includes local DNS filtering, monitoring or even simply a mis-functioning DNS resolver of some kind.

Yes, but let's not confuse issues here - this ticket is about avoiding DNS leaks for people who want to use a proxy to avoid exposing information to others who might be able to see it if it used their network directly.

Most people don't care that their ISP can see what they attempt to connect to. If e.g. GTalk (or many other XMPP services) didn't work out of the box because we didn't do SRV lookups, there would be a orders of magnitude more people complaining about that - there are already are lots of people who seek support because they use a broken DNS server that doesn't do SRV.

This is an odd one - you guys already fixed *some* of these issues. My fix only impacts people who add a proxy, so it's actually not a perfect fix but it should not impact anyone by default. How many users even set proxies? Are the people who set proxies really unwilling to learn that their proxies reduce functionality? How has that been determined?

We fixed situations where we were doing DNS lookups in ways that couldn't be avoided and there was a fully correct non-breaking solution.

We don't collect any sort of usage statistics, so we can only speculate based on the types of tickets we see and interactions with users.

One assumption that I believe that we have to start off with is that if possible, it should *just work*. If someone wants "privacy", they need to do appropriate research and take appropriate steps to configure their system appropriately - if you really care, you need to do what it takes to happen and not make assumptions.

Well, I would say that currently there is a security and privacy problem in libpurple. So regardless of how we find a solution, currently libpurple isn't suitable for anyone who needs to use pidgin for circumvention (Tor, OpenSSH) or anonymity (Tor) or simply as a way to securely forward at conferences (OpenSSH or other SOCKS proxies).

Ok.

Perhaps it would make sense to have a preference where we "allow DNS requests to bypass proxy settings" in the proxy dialog? And perhaps that would be implemented by a plugin that is enabled by default unless you check that box?

If it was a checkbox, in the preferences, then it likely wouldn't be a plugin.

Ok. Would you be interested in a checkbox?

Perhaps. We tend to avoid adding additional complexity and preferences to the core, but this might be something that arguably could be warranted.

I think that the biggest confusion here is that you're assuming that "proxy" == "anonymizing proxy".

I'm not assuming anonymizing proxy. I'm assuming that when a user says they wish to proxy their traffic relating to an account, they proxy the traffic related to that account. All of it. If you're using an SSH tunnel, it isn't about anonymity, it may just be about the local network being unsafe. Think Firesheep or dsniff, etc.

I still think you're making an incorrect (for the most common proxy usage) assumption. Most people use a proxy because they need to - their restricted network just wont allow them to connect if they don't use proxy; they just want it to work, they don't care if a stray DNS request doesn't go through the proxy if it causes their Google Talk account to connect.

Sure, there are lots of valid reasons that someone would want to avoid using their local network's DNS, but only a tiny proportion of users will care - I'd bet that most people who use proxies don't even know what a proxy really is apart from a setting they need to set so stuff will work.

All that said, I'm all for making it possible for the minority of people who want/need to do this for privacy/security reasons (I don't dispute that there are perfectly valid reasons to want to do this), I just want to make sure that we keep the context of the overall usage and other targeted use cases in mind.

comment:29 follow-up: Changed 8 years ago by datallah

After chatting with some other folks about this, we've come up with the idea of having an additional proxy type of "Tor" that would functionally be a SOCKS5 could be used to make this (and potentially other) decisions (e.g. not advertising your IP address as an option for file transfers).

Does that sounds like a reasonable option?

To do this, we'd have to add API, so it'd have to be done relatively soon to squeeze into the upcoming 2.8.0 release.

comment:30 in reply to: ↑ 29 ; follow-up: Changed 8 years ago by ioerror

Replying to datallah:

After chatting with some other folks about this, we've come up with the idea of having an additional proxy type of "Tor" that would functionally be a SOCKS5 could be used to make this (and potentially other) decisions (e.g. not advertising your IP address as an option for file transfers).

Does that sounds like a reasonable option?

Holy cow! You guys rock! Yes. Please.

To do this, we'd have to add API, so it'd have to be done relatively soon to squeeze into the upcoming 2.8.0 release.

Ok - what do you need from me? I'm happy to code stuff up - I'd probably just need a little direction.

comment:31 Changed 8 years ago by jpostel

I'm just chiming in in support of this change. I've been using pidgin through Tor with the OTR plugin and expected it to "DTRT".

comment:32 Changed 8 years ago by jpostel

The alternative being that I need to explicitly manage DNS resolution myself. Currently Tor users operate on the assumption that SOCKS5 proxied applications don't leak. Needless to say anonymity seeking users will not be amused that who their connecting to is being leaked - defeating much of the purpose of the indirection.

comment:33 in reply to: ↑ 30 Changed 8 years ago by datallah

Replying to ioerror:

Ok - what do you need from me? I'm happy to code stuff up - I'd probably just need a little direction.

I'm working on an implementation, once that is done I'll let you know.

It'll be good to get some testing.

comment:34 Changed 8 years ago by datallah@…

(In f9ed9968030c167eb2a7d562c69b04efbe00ca5d):
Add a new proxy type of "Tor". This is really just a SOCKS5 proxy, but can be used to restrict functionality (e.g. DNS lookups) for privacy reasons.

Refs #11110

comment:35 Changed 8 years ago by datallah@…

(In 545dd3386c0c8b1556984514b859317f7ec392d8):
Add new DNS-related API to perform lookups in the context of an account. Combined with the new "Tor/Privacy?" proxy setting, this allows us to prevent DNS lookups when the user has selected a proxy that they may want to use to for privacy.

Refs #11110

comment:36 Changed 8 years ago by datallah@…

(In 075c2902b90abb6349a6b689e26fa0ecf720ca04):
Use the new account-contextual DNS API everywhere. Refs #11110

comment:37 Changed 8 years ago by datallah

  • Milestone changed from Implementation In Progress to 2.8.0

The im.pidgin.pidgin branch monotone contains the all of the changes that I believe are necessary for this.

These changes will be in the upcoming 2.8.0 release, please test.

comment:38 Changed 8 years ago by datallah

  • Resolution set to fixed
  • Status changed from new to closed

It's worth noting that the new "Tor/Privacy?" proxy will not be able to prevent DNS lookups in libraries outside of our control (e.g. libgadu, which is used for gadu-gadu and possibly libmeanwhile used for sametime).

comment:39 Changed 8 years ago by ioerror

We're using a checkout from monotone and packed into a tar.gz here: http://erinn.org/~e/pidgin.tgz

I've configured it like so:

./configure --disable-screensaver --disable-gstreamer --disable-vv --disable-idn --disable-meanwhile --disable-nm --disable-perl --disable-tcl

I've tried to build it but it fails:

make cd . && /bin/bash ./config.status config.h config.status: creating config.h config.status: config.h is unchanged make all-recursive make[1]: Entering directory `/tmp/pidgin-mtn' Making all in . make[2]: Entering directory `/tmp/pidgin-mtn'

GEN package_revision_raw.txt GEN package_revision.h

make[2]: Leaving directory `/tmp/pidgin-mtn' Making all in libpurple make[2]: Entering directory `/tmp/pidgin-mtn/libpurple' Makefile:909: .deps/account.Plo: No such file or directory Makefile:910: .deps/accountopt.Plo: No such file or directory Makefile:911: .deps/backend-fs2.Plo: No such file or directory Makefile:912: .deps/backend-iface.Plo: No such file or directory Makefile:913: .deps/blist.Plo: No such file or directory Makefile:914: .deps/buddyicon.Plo: No such file or directory Makefile:915: .deps/candidate.Plo: No such file or directory Makefile:916: .deps/certificate.Plo: No such file or directory Makefile:917: .deps/cipher.Plo: No such file or directory Makefile:918: .deps/circbuffer.Plo: No such file or directory Makefile:919: .deps/cmds.Plo: No such file or directory Makefile:920: .deps/codec.Plo: No such file or directory Makefile:921: .deps/connection.Plo: No such file or directory Makefile:922: .deps/conversation.Plo: No such file or directory Makefile:923: .deps/core.Plo: No such file or directory Makefile:924: .deps/dbus-server.Plo: No such file or directory Makefile:925: .deps/dbus-useful.Plo: No such file or directory Makefile:926: .deps/debug.Plo: No such file or directory Makefile:927: .deps/desktopitem.Plo: No such file or directory Makefile:928: .deps/dnsquery.Plo: No such file or directory Makefile:929: .deps/dnssrv.Plo: No such file or directory Makefile:930: .deps/enum-types.Plo: No such file or directory Makefile:931: .deps/eventloop.Plo: No such file or directory Makefile:932: .deps/ft.Plo: No such file or directory Makefile:933: .deps/idle.Plo: No such file or directory Makefile:934: .deps/imgstore.Plo: No such file or directory Makefile:935: .deps/log.Plo: No such file or directory Makefile:936: .deps/marshallers.Plo: No such file or directory Makefile:937: .deps/media.Plo: No such file or directory Makefile:938: .deps/mediamanager.Plo: No such file or directory Makefile:939: .deps/mime.Plo: No such file or directory Makefile:940: .deps/nat-pmp.Plo: No such file or directory Makefile:941: .deps/network.Plo: No such file or directory Makefile:942: .deps/notify.Plo: No such file or directory Makefile:943: .deps/ntlm.Plo: No such file or directory Makefile:944: .deps/plugin.Plo: No such file or directory Makefile:945: .deps/pluginpref.Plo: No such file or directory Makefile:946: .deps/pounce.Plo: No such file or directory Makefile:947: .deps/prefs.Plo: No such file or directory Makefile:948: .deps/privacy.Plo: No such file or directory Makefile:949: .deps/proxy.Plo: No such file or directory Makefile:950: .deps/prpl.Plo: No such file or directory Makefile:951: .deps/purple-client-example.Po: No such file or directory Makefile:952: .deps/purple-client.Plo: No such file or directory Makefile:953: .deps/request.Plo: No such file or directory Makefile:954: .deps/roomlist.Plo: No such file or directory Makefile:955: .deps/savedstatuses.Plo: No such file or directory Makefile:956: .deps/server.Plo: No such file or directory Makefile:957: .deps/signals.Plo: No such file or directory Makefile:958: .deps/smiley.Plo: No such file or directory Makefile:959: .deps/sound-theme-loader.Plo: No such file or directory Makefile:960: .deps/sound-theme.Plo: No such file or directory Makefile:961: .deps/sound.Plo: No such file or directory Makefile:962: .deps/sslconn.Plo: No such file or directory Makefile:963: .deps/status.Plo: No such file or directory Makefile:964: .deps/stringref.Plo: No such file or directory Makefile:965: .deps/stun.Plo: No such file or directory Makefile:966: .deps/theme-loader.Plo: No such file or directory Makefile:967: .deps/theme-manager.Plo: No such file or directory Makefile:968: .deps/theme.Plo: No such file or directory Makefile:969: .deps/upnp.Plo: No such file or directory Makefile:970: .deps/util.Plo: No such file or directory Makefile:971: .deps/value.Plo: No such file or directory Makefile:972: .deps/version.Plo: No such file or directory Makefile:973: .deps/whiteboard.Plo: No such file or directory Makefile:974: .deps/xmlnode.Plo: No such file or directory make[2]: * No rule to make target `.deps/xmlnode.Plo'. Stop. make[2]: Leaving directory `/tmp/pidgin-mtn/libpurple' make[1]: * [all-recursive] Error 1 make[1]: Leaving directory `/tmp/pidgin-mtn' make: * [all] Error 2

Thoughts?

comment:40 Changed 8 years ago by ioerror

One other thing - the configure output has one issue:

config.status: error: cannot find input file: `po/Makefile.in.in'

comment:41 Changed 8 years ago by datallah

If you're using development source, you need to use autogen.sh.

comment:42 Changed 8 years ago by ioerror

Ah, I was calling most of that stuff by hand. I hadn't seen the autogen.sh because previously I'd been working from a release tar.gz - that did the trick!

Thank you - we'll give you some feedback soon.

comment:43 Changed 8 years ago by ioerror

One initial feedback point - sometimes people run their Tor on a different port than 9050 - it doesn't appear possible to configure which Host or Port Tor is running on?

comment:44 Changed 8 years ago by ioerror

Wowza - I just tested it with an account and it just directly connected without even talking to my local Tor.

I guess that is *not* what we wanted at all. I looked through the code and didn't find a single place where the proxy would be set as 127.0.0.1:9050...

comment:45 Changed 8 years ago by ioerror

Here's the log:

(16:55:37) proxy: No environment settings found, not using a proxy (16:55:37) dnsquery: Performing DNS lookup for jabber.ccc.de (16:55:37) proxy: No environment settings found, not using a proxy (16:55:37) dns: Wait for DNS child 29410 failed: No child processes (16:55:37) dns: Created new DNS child 29420, there are now 1 children. (16:55:37) dns: Successfully sent DNS request to child 29420 (16:55:37) dns: Got response for 'jabber.ccc.de' (16:55:37) dnsquery: IP resolved for jabber.ccc.de (16:55:37) proxy: Attempting connection to 217.10.10.194 (16:55:37) proxy: Connecting to jabber.ccc.de:5222 with no proxy (16:55:37) proxy: Connection in progress (16:55:37) proxy: Connecting to jabber.ccc.de:5222. (16:55:37) proxy: Connected to jabber.ccc.de:5222.

I guess that I should set some ENV variable? That seems like it will cause some major confusion for users as it fails open...

comment:46 Changed 8 years ago by ioerror

purple_proxy_get_setup() appears to inspect the environment for a proxy and of course it does not find one.

Should we add the new proxy type into that purple_proxy_get_setup()?

It appears that the way that this was written we behave just as a SOCKS proxy and if it's unset we'll directly connect, this is of course what is happening.

comment:47 Changed 8 years ago by ioerror

Indeed - I find that when I set the proxy in pidgin (GTK) - it produces the following XML in my accounts.xml:

»···»···<proxy> »···»···»···<type>envvar</type> »···»···</proxy>

As it stands - the code sees proxy type envvar after this has been set.

If I set the proxy by hand to type 'tor' and set host to '127.0.0.1' and port to '9050' - it appears to work as expected.

I'll keep digging around...

comment:48 Changed 8 years ago by ioerror

Perhaps an unrelated issue - when changing the proxy types from say, http with a login/password/host/port to none, pidgin keeps everything around except the type.

Example of setting http to none: »···»···<proxy> »···»···»···<type>none</type> »···»···»···<host>1.2.3.4</host> »···»···»···<port>2323</port> »···»···»···<username>username</username> »···»···»···<password>password</password> »···»···</proxy>

If you then clear the data manually and set it to none: »···»···<proxy> »···»···»···<type>none</type> »···»···</proxy>

comment:49 Changed 8 years ago by ioerror

For some reason, I had no host, port, username or password config boxes during any of this testing - however, I noticed a small mistake that once changed, I somehow had fields to fill in. In proxy.h, the PurpleProxyType? def appeared to be reversed and this caused the UI to not show the proper GTK widgets and all hell broke loose. The proxy now fails closed when the information is empty.

It was:

»···PURPLE_PROXY_USE_ENVVAR,       /**< Use environmental settings.       */
»···PURPLE_PROXY_TOR               /**< Use a Tor proxy (SOCKS 5 really)  */

It is now:

»···PURPLE_PROXY_TOR,              /**< Use a Tor proxy (SOCKS 5 really)  */
»···PURPLE_PROXY_USE_ENVVAR        /**< Use environmental settings.       */

With that switch, I have a proxy type that emits the proper xml into accounts.xml and it connects over Tor (as configured)!

With a proxy that is unreachable - we get this error (as expected):

(00:42:10) proxy: Attempting connection to 127.0.0.1
(00:42:10) proxy: Connecting to jabber.ccc.de:5222 via 127.0.0.1:1 using SOCKS5
(00:42:10) socks5 proxy: Connection in progress
(00:42:10) socks5 proxy: Connected.
(00:42:10) proxy: Connection attempt failed: Connection refused
(00:42:10) jabber: Couldn't connect directly to jabber.ccc.de.  Trying to find alternative connection methods, like BOSH.
(00:42:10) dnssrv: Aborting TXT lookup in Tor Proxy mode.(00:42:10) jabber: Unable to find alternative XMPP connection methods after failing to connect directly.
(00:42:10) connection: Connection error on 0x7ffff8e388c0 (reason: 0 description: Unable to connect)
(00:42:10) account: Disconnecting account xxxx@jabber.ccc.de/ccc (0x7ffff82fee60)

With a proxy that is reachable:

(00:43:16) account: Connecting to account xxxx@jabber.ccc.de/ccc.
(00:43:16) connection: Connecting. gc = 0x7ffff8e52fa0
(00:43:16) dnsquery: Performing DNS lookup for 127.0.0.1
(00:43:16) dnsquery: IP resolved for 127.0.0.1
(00:43:16) proxy: Attempting connection to 127.0.0.1
(00:43:16) proxy: Connecting to jabber.ccc.de:5222 via 127.0.0.1:9050 using SOCKS5
(00:43:16) socks5 proxy: Connection in progress
(00:43:16) socks5 proxy: Connected.
(00:43:16) socks5 proxy: Able to read.
(00:43:16) s5: reallocing from 5 to 8
(00:43:16) s5: reallocing from 8 to 10
(00:43:16) proxy: Connected to jabber.ccc.de:5222.

So - the one change that needs to be done for your branch is the following patch:

diff -U 1 pidgin-mtn/libpurple/proxy.h pidgin-mtn-fixed/libpurple/proxy.h
--- pidgin-mtn/libpurple/proxy.h	2011-04-28 04:05:25.000000000 -0700
+++ pidgin-mtn-fixed/libpurple/proxy.h	2011-04-29 00:33:16.982350763 -0700
@@ -41,4 +41,4 @@
 	PURPLE_PROXY_SOCKS5,           /**< SOCKS 5 proxy.                    */
-	PURPLE_PROXY_USE_ENVVAR,       /**< Use environmental settings.       */
-	PURPLE_PROXY_TOR               /**< Use a Tor proxy (SOCKS 5 really)  */
+	PURPLE_PROXY_TOR,              /**< Use a Tor proxy (SOCKS 5 really)  */
+	PURPLE_PROXY_USE_ENVVAR        /**< Use environmental settings.       */

After applying the above patch, I did the following:

  patch -p1 < ../configure.ac-hardening.patch
  ./autogen.sh
  ./configure --disable-screensaver --disable-gstreamer --disable-vv --disable-idn --disable-meanwhile --disable-dbus --disable-perl --disable-tcl --enable-gnutls=no --enable-nss=yes --disable-consoleui --enable-gcc-hardening --enable-linker-hardening
  time make
  sudo make install

Everything appears to be basically functional and I'll test for leaks with XMPP next.

Changed 8 years ago by ioerror

comment:50 Changed 8 years ago by ioerror

Just for completeness, I've also attached my hardening patch (bug #13879 - http://developer.pidgin.im/ticket/13879) that I used during testing here.

Changed 8 years ago by ioerror

comment:51 follow-up: Changed 8 years ago by datallah

I'm going to ignore the first few messages since my last reply, it looks to me like there was some confusion that was subsequently resolved - if there is something in those that is a real problem, please let me know.

We can't (shouldn't) reverse the order of the entries in that enum - that would cause the value previously used for ENVVAR to change. The order in the enum isn't at all correlated with the order of the items displayed in the GUI, the selection is determined by value, not by order.

I can't recreate the problem you're experiencing here - please make sure that you're using a clean build, particularly since your patching changed the ints for the proxy type enum. The proxy configuration settings in the GUI should (and do) appear in all cases except "No proxy" and "Use environmental settings".

comment:52 in reply to: ↑ 51 ; follow-up: Changed 8 years ago by ioerror

Replying to datallah:

I'm going to ignore the first few messages since my last reply, it looks to me like there was some confusion that was subsequently resolved - if there is something in those that is a real problem, please let me know.

Sure, sorry about the above confusion...

We can't (shouldn't) reverse the order of the entries in that enum - that would cause the value previously used for ENVVAR to change. The order in the enum isn't at all correlated with the order of the items displayed in the GUI, the selection is determined by value, not by order.

Hrm. Does that actually matter? The proxy value will be written out to disk (in accounts.xml) as text after any proxy switch (once the callback is called). So the int value only matters at run time and is internal to pidgin, isn't it?

I mean, I understand that the symbolic name should be enough but this does not appear to be the case.

I can't recreate the problem you're experiencing here - please make sure that you're using a clean build, particularly since your patching changed the ints for the proxy type enum.

Ok - I can reproduce it locally - every time from a clean build. Until I re-order the enum, I always had a "Tor/Privacy?" option with no fields to fill in and internally, it wrote 'envvar' to the 'accounts.xml' file. Similarly, the "Use Environmental Settings" selection gave me fields to fill in.

I am using a clean build from http://erinn.org/~e/pidgin.tgz and I did the following:

  wget http://erinn.org/~e/pidgin.tgz
  tar -xvzf pidgin.tgz
  cd pidgin-mtn
  ./autogen.sh
  ./configure --disable-screensaver --disable-gstreamer --disable-vv --disable-idn --disable-meanwhile --disable-dbus --disable-perl --disable-tcl --enable-gnutls=no --enable-nss=yes --disable-consoleui --enable-gcc-hardening --enable-linker-hardening
  time make
  sudo make install
  /usr/local/bin/pidgin

One thing worth noting is that the autogen.sh has an error in the last line where configure is run:

checking for XScreenSaverRegister in -lXext... no
checking for XScreenSaverRegister in -lXss... no
configure: error: 
XScreenSaver extension development headers not found.
Use --disable-screensaver if you do not need XScreenSaver extension support,
this is required for detecting idle time by mouse and keyboard usage.

This shouldn't matter as the next thing that I call is the correct configure line for my system. Does it?

I have no other pidgin packages on my system. Previously, I used the pidgin packages that came with ubuntu (I removed pidgin pidgin-dev pidgin-libnotify pidgin-otr during this development cycle) and those are long gone.

Here's my pristine pidgin:

% which pidgin
/usr/local/bin/pidgin

% ldd /usr/local/bin/pidgin
	linux-vdso.so.1 =>  (0x00007fffb81ff000)
	libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f5828cb5000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f5828a9a000)
	libgtkspell.so.0 => /usr/lib/libgtkspell.so.0 (0x00007f5828892000)
	libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00007f5828542000)
	libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00007f5827f20000)
	libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00007f5827c72000)
	libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00007f5827a51000)
	libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007f582779e000)
	libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00007f5827573000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00007f5827357000)
	libm.so.6 => /lib/libm.so.6 (0x00007f58270d4000)
	libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007f5826ec6000)
	libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007f5826c43000)
	libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00007f58269f9000)
	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f5826772000)
	libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f582653d000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f58262f5000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f58260f0000)
	libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f5825eeb000)
	librt.so.1 => /lib/librt.so.1 (0x00007f5825ce3000)
	libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00007f5825a04000)
	libpurple.so.0 => /usr/local/lib/libpurple.so.0 (0x00007f582573f000)
	libnsl.so.1 => /lib/libnsl.so.1 (0x00007f5825525000)
	libresolv.so.2 => /lib/libresolv.so.2 (0x00007f582530b000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f58250ee000)
	libc.so.6 => /lib/libc.so.6 (0x00007f5824d6b000)
	libuuid.so.1 => /lib/libuuid.so.1 (0x00007f5824b65000)
	libz.so.1 => /lib/libz.so.1 (0x00007f582494e000)
	libenchant.so.1 => /usr/lib/libenchant.so.1 (0x00007f5824743000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f582453e000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f582432c000)
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f5824121000)
	libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007f5823f1e000)
	libXi.so.6 => /usr/lib/libXi.so.6 (0x00007f5823d0e000)
	libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f5823b05000)
	libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007f58238fa000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f58235c4000)
	libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x00007f58233c1000)
	libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007f58231bd000)
	libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f5822fb7000)
	libpcre.so.3 => /lib/libpcre.so.3 (0x00007f5822d88000)
	libselinux.so.1 => /lib/libselinux.so.1 (0x00007f5822b6a000)
	libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00007f5822910000)
	libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0x00007f582268d000)
	libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0x00007f5822483000)
	libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0x00007f5822269000)
	libpng12.so.0 => /lib/libpng12.so.0 (0x00007f5822042000)
	libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0x00007f5821e3e000)
	libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00007f5821c34000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f5821a18000)
	libexpat.so.1 => /lib/libexpat.so.1 (0x00007f58217ee000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5828ee2000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f58215e9000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f58213e3000)

Additionally, my /usr/local/* is empty before I install pidgin.

The proxy configuration settings in the GUI should (and do) appear in all cases except "No proxy" and "Use environmental settings".

Not for me. I only have proper functionality when I re-order the enum - once I've done that, everything functions as expected.

As an aside, when compiling a pristine copy (no patches at all), I see:

  CC     privacy.lo
  CC     proxy.lo
proxy.c:2404: warning: no previous prototype for ‘purple_proxy_connect_socks5’
  CC     prpl.lo
  CC     request.lo
  CC     roomlist.lo
  CC     savedstatuses.lo
  CC     server.lo
  CC     signals.lo
  CC     smiley.lo
  CC     dnsquery.lo
dnsquery.c:923: warning: no previous prototype for ‘purple_dnsquery_a’
  CC     dnssrv.lo
dnssrv.c:677: warning: no previous prototype for ‘purple_srv_resolve’
dnssrv.c:817: warning: no previous prototype for ‘purple_txt_resolve’
  CC     status.lo

Changed 8 years ago by ioerror

Changed 8 years ago by ioerror

comment:53 Changed 8 years ago by ioerror

I've attached four screenshots that show the state of the GTK widgets. The pristine screenshots are from the pristine tree without any patches, the enum-relocated has only a single change - the relocation of the enum as is performed by the libpurple-proxy.h.patch I've attached.

I opened each account, went to the proxy tab, selected the field, saved the account, went back, opened it again, and finally saved the screen shot. The text in the right hand corner demonstrates what happens when the callback is called and the text values are flushed to accounts.xml.

As you can see from the screenshots the pristine copy is lacking fields to fill in and the enum renumbered is working as expected.

comment:54 Changed 8 years ago by ioerror

You'll also note from the text that the pristine copy emits the text 'envvar' when it should emit 'tor' and it emits 'tor' when it should emit 'envvar'

comment:55 in reply to: ↑ 52 ; follow-up: Changed 8 years ago by datallah

Replying to ioerror:

Replying to datallah:

We can't (shouldn't) reverse the order of the entries in that enum - that would cause the value previously used for ENVVAR to change. The order in the enum isn't at all correlated with the order of the items displayed in the GUI, the selection is determined by value, not by order.

Hrm. Does that actually matter? The proxy value will be written out to disk (in accounts.xml) as text after any proxy switch (once the callback is called). So the int value only matters at run time and is internal to pidgin, isn't it?

It does matter because it is an API breakage - any plugin that was compiled against an old version of libpurple that used "PURPLE_PROXY_USE_ENVVAR" would map to the TOR value on a newer libpurple.

comment:56 follow-up: Changed 8 years ago by datallah

Aha... I've figured out what the problem is.

I was looking at the overall proxy preference (which works fine), whereas you're using the account-specific proxy setting (which exhibits the problem you're seeing).

Thanks for your persistence - I'll fix the issue shortly.

comment:57 in reply to: ↑ 55 Changed 8 years ago by ioerror

Replying to datallah:

It does matter because it is an API breakage - any plugin that was compiled against an old version of libpurple that used "PURPLE_PROXY_USE_ENVVAR" would map to the TOR value on a newer libpurple.

That makes sense. Thanks for clarifying!

comment:58 in reply to: ↑ 56 Changed 8 years ago by ioerror

Replying to datallah:

Aha... I've figured out what the problem is.

I was looking at the overall proxy preference (which works fine), whereas you're using the account-specific proxy setting (which exhibits the problem you're seeing).

Thanks for your persistence - I'll fix the issue shortly.

Ah! I'd love to see the diff for this change - thanks for working through it with me!

comment:59 Changed 8 years ago by ioerror

It appears that some Adium users want this feature as well: http://trac.adium.im/ticket/15161

comment:60 Changed 8 years ago by datallah@…

(In 6ebf6c2d815e97076480c93bd323905a40072a5b):
Fix account-specific proxy selection GUI to not be dependent enum ordering.

Refs #11110

comment:61 Changed 8 years ago by datallah@…

(In 6aa82282e6ca33634357e91c18d470a5a01d52ba):
Fix account-specific proxy config GUI to use same ordering as global proxy GUI.

Refs #11110

comment:62 Changed 8 years ago by datallah

I've discovered another issue that Tor users may care about, see #13928 for more information.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!