Re: [or-talk] where are the exit nodes gone?
Roger Dingledine schrieb: No, that 1755 was total Running relays. For comparison, there are 1541 running relays in the consensus right now. You might like http://metrics.torproject.org/consensus-graphs.html#exit-all the same graphs for the average observed bandwidth would be great regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Sun, 11 Apr 2010 08:47:31 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Roger Dingledine schrieb: No, that 1755 was total Running relays. For comparison, there are 1541 running relays in the consensus right now. You might like http://metrics.torproject.org/consensus-graphs.html#exit-all the same graphs for the average observed bandwidth would be great Observed by what? If it has anything to do with the numbers given in the consensus documents, then the only value such graphs would have would be for the purpose of comparing those graphs with the values reported by the relays themselves. The values in the consensus documents alone are, a priori, worthless. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
Scott Bennett schrieb: Observed by what? If it has anything to do with the numbers given in the consensus documents, then the only value such graphs would have would be for the purpose of comparing those graphs with the values reported by the relays themselves. The values in the consensus documents alone are, a priori, worthless. yes, the max and the burst bandwidth are not so much worth for statistic purposes. As I mentioned some says ago, MaxAdvertisedBandwidth 2500 KB config option leads to an real average bandwidth (measured by mrtg) of about 16000 KB on blutmagie exit. A higher MaxAdvertisedBandwidth value is killing the cpu with the number of new conns/s. Is it possible to use the average observed bandwidth reported by the relays? Knowing the number of exit relays doesn't help very much without knowing about the total provided bandwidth. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: prifoxy privoxy-on-firefox-extension?
Roger Dingledine a...@mit.edu wrote: Several people on irc have pointed out prifoxy: http://code.google.com/p/prifoxy/ Can somebody take a look at it, and decide whether it's for real, whether it looks competently done, trustworthy, safe to recommend, etc? My brief look showed me a binary blob and not much else, so my guess is that it's bad news; but more eyes would be great. There was a thread about this on the Privoxy users mailing list a while ago, started by the Prifoxy originator: http://sourceforge.net/mailarchive/message.php?msg_name=94f7b1b40902240452y1a22d7b4y7461c4edb2f956c5%40mail.gmail.com My concerns and questions were pretty much ignored and until that changes I certainly wouldn't recommend the extension myself. Fabian signature.asc Description: PGP signature
Re: [or-talk] where are the exit nodes gone?
Hi Olaf, On Sun, 11 Apr 2010 12:11:36 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett schrieb: Observed by what? If it has anything to do with the numbers given in the consensus documents, then the only value such graphs would have would be for the purpose of comparing those graphs with the values reported by the relays themselves. The values in the consensus documents alone are, a priori, worthless. yes, the max and the burst bandwidth are not so much worth for statistic You did say observed, not advertised. purposes. As I mentioned some says ago, MaxAdvertisedBandwidth 2500 KB config option leads to an real average bandwidth (measured by mrtg) of about 16000 KB on blutmagie exit. A higher MaxAdvertisedBandwidth value Remember, there are exactly two vantage points from which valid observations can be made, no more and no less. One is from inside your system's networking stack (including packet filter software). The other is inside your tor relay's process. Unless the value of about 16000 KB (/s) comes from one of those two sources, then I simply don't believe the so-called measurement, and neither should you. Such a measurement means, at best, only that it's probably a relatively big number when compared to the rest of such numbers in the consensus, and the real number is almost certainly larger than this number. is killing the cpu with the number of new conns/s. Is it possible to use the average observed bandwidth reported by the relays? Knowing the number of exit relays doesn't help very much without No, not at the present time because that is not reported by the relays. What a relay reports is the highest minimum number of bytes handled in any one second in a ten-second sliding window within the the past 24 hours. That value is then devalued considerably by the fact that the 24-hour periods are not normally consecutive, but rather are overlapped by roughly six hours at each end, so that only the middle twelve of the 24 hours are represented exclusively in a measurement reporting period. The whole reporting setup is wrong and needs to be revamped from scratch in order to get a system that works properly. As I've noted before, the very first and most critical thing to be done is the design separation of throughput capacity (which the clients need to know) from actual service rendered (which only some humans want to know). The rest cannot even be begun until that much is done. knowing about the total provided bandwidth. Probably the best data (i.e., not as bad as any of the other values reported) for that purpose would be found in the extra-info documents. Divide each field by 900 s to get the average rates in B/s. One good thing about the numbers in the extra-info documents is that both bytes read and bytes written are reported. Sorry to disappoint you, Olaf, but that's just the way things are for now. :-( FWIW, I still think it might be worth your time to take a spare machine, if you have one, and install an OS that supports superpages (e.g., FreeBSD 7.2 and later, Windows Vista and later, possibly Windows Server 2008, but I don't know about that one), and then try it long enough to see whether that relieves any of the CPU load. Or, if you're up for some coding and testing, you could try LINUX's support for huge pages, but that facility is neither automatic nor transparent to the application, as I understand it, so it does require additional code. At present, it's very likely that 30% to 45% of your tor relay's CPU time is being wasted in address translation due to TLB misses, even when the needed data or instructions are *already in some level of cache*. If the CPU is stalled because MMU has to walk a page table before it can discover that what it needs is not only already in memory, but already in a cache, the performance hit is a crying shame. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Sun, 11 Apr 2010 06:12:43 -0500 (CDT) I wrote: Hi Olaf, On Sun, 11 Apr 2010 12:11:36 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett schrieb: Observed by what? If it has anything to do with the numbers given in the consensus documents, then the only value such graphs would have would be for the purpose of comparing those graphs with the values reported by the relays themselves. The values in the consensus documents alone are, a priori, worthless. yes, the max and the burst bandwidth are not so much worth for statistic You did say observed, not advertised. purposes. As I mentioned some says ago, MaxAdvertisedBandwidth 2500 KB config option leads to an real average bandwidth (measured by mrtg) of about 16000 KB on blutmagie exit. A higher MaxAdvertisedBandwidth value Remember, there are exactly two vantage points from which valid observations can be made, no more and no less. One is from inside your system's networking stack (including packet filter software). The other is inside your tor relay's process. Unless the value of about 16000 KB (/s) comes from one of those two sources, then I simply don't believe the so-called measurement, and neither should you. Such a measurement means, at best, only that it's probably a relatively big number when compared to the rest of such numbers in the consensus, and the real number is almost certainly larger than this number. is killing the cpu with the number of new conns/s. I see I missed the implication in Olaf's main complaint above, which is that the authorities are advertising more capacity for his node than his node is advertising. Checking the current (i.e., valid-after 2010-04-11 10:00:00) consensus, I see that the authorities have decided to volunteer 2560 KB/s on behalf of node blutmagie, which is indeed greater than 2500 KB/s, though only 2.4% greater. (For some reason, my current directory files don't seem to contain a descriptor for blutmagie at all. I don't know why, but I assume that it will prove to be a temporary situation.) In any case, if a consensus document volunteers any capacity exceeding the smallest of a node's BandwidthRate, RelayBandwidthRate, or MaxAdvertisedBandwidth, then I believe it should be documented and reported as a bug in the authority code. Is it possible to use the average observed bandwidth reported by the relays? Knowing the number of exit relays doesn't help very much without No, not at the present time because that is not reported by the relays. What a relay reports is the highest minimum number of bytes handled in any one second in a ten-second sliding window within the the past 24 hours. That value is then devalued considerably by the fact that the 24-hour periods are not normally consecutive, but rather are overlapped by roughly six hours at each end, so that only the middle twelve of the 24 hours are represented exclusively in a measurement reporting period. The whole reporting setup is wrong and needs to be revamped from scratch in order to get a system that works properly. As I've noted before, the very first and most critical thing to be done is the design separation of throughput capacity (which the clients need to know) from actual service rendered (which only some humans want to know). The rest cannot even be begun until that much is done. knowing about the total provided bandwidth. Probably the best data (i.e., not as bad as any of the other values reported) for that purpose would be found in the extra-info documents. Divide each field by 900 s to get the average rates in B/s. One good thing about the numbers in the extra-info documents is that both bytes read and bytes written are reported. The other things I missed in Olaf's remarks above are *exit* usage and *exit* capacity. If tor ever get proper reporting of throughput capacity, then adding up the capacities of all exit nodes in the consensus or, arguably, the current directory, would yield the total exit capacity because it matters not whether data leave a node for a true destination or just to another node. But the total exit usage question cannot be answered at present because nothing reports that information at present. Whether tor is keeping such information locally but not reporting it either locally or to some authority, I don't know. If it is, then adding a few lines to write the information to a log every so often should be fairly trivial to do. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John
Re: [or-talk] where are the exit nodes gone?
Scott Bennett schrieb: I see I missed the implication in Olaf's main complaint above, which is that the authorities are advertising more capacity for his node than his node is advertising. relax, I'm not complaining. We are all volunteers not being payed for writing tor code. Checking the current (i.e., valid-after 2010-04-11 10:00:00) consensus, I see that the authorities have decided to volunteer 2560 KB/s on behalf of node blutmagie, which is indeed greater than 2500 KB/s, though only 2.4% greater. yes, I noticed that without mentioning it on this list. It appears to be a common misunderstanding in coding between 2^10 and 10^3. (For some reason, my current directory files don't seem to contain a descriptor for blutmagie at all. I don't know why, but I assume that it will prove to be a temporary situation.) did my node stop publishing its descriptor again? Traffic has dropped about 80% within the last hours. Have a look at the attached graph. But the total exit usage question cannot be answered at present because nothing reports that information at present. maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. Regarding superpages: Is it possible to figure out how much cpu time being wasted in address translation with on-board means like vmstat? But I'm certainly not going to migrate my tor node to Windows. Never ever! ;-) regards Olaf inline: anonymizer2.blutmagie.de_2-day.png
Re: [or-talk] where are the exit nodes gone?
On Sun, 11 Apr 2010 15:23:16 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett schrieb: I see I missed the implication in Olaf's main complaint above, which is that the authorities are advertising more capacity for his node than his node is advertising. relax, I'm not complaining. We are all volunteers not being payed for writing tor code. Checking the current (i.e., valid-after 2010-04-11 10:00:00) consensus, I see that the authorities have decided to volunteer 2560 KB/s on behalf of node blutmagie, which is indeed greater than 2500 KB/s, though only 2.4% greater. yes, I noticed that without mentioning it on this list. It appears to be a common misunderstanding in coding between 2^10 and 10^3. (For some reason, my current directory files don't seem to contain a descriptor for blutmagie at all. I don't know why, but I assume that it will prove to be a temporary situation.) did my node stop publishing its descriptor again? Traffic has dropped about 80% within the last hours. Have a look at the attached graph. Oh, jeez. I thought that one had been fixed a while back. Sigh. Or maybe it's not just *one* bug. But the total exit usage question cannot be answered at present because nothing reports that information at present. maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. You might communicate with Kasimir Gabert about that. I think he said some months ago that he was going to do that for his torstatus stuff, so what you want might already be written. Regarding superpages: Is it possible to figure out how much cpu time being wasted in address translation with on-board means like vmstat? But I don't see how because a successful translation stays in the hardware and causes no interrupt. The kernel only sees something when the translation fails. FreeBSD has had steadily growing HWPMC support since 6.0, so I just looked through some of the HWPMC man pages. There are counters for instruction cache misses and data cache misses, but I didn't see any counters at all that involved TLB-related events. That doesn't mean that there aren't any, just that I didn't find any documentation of any. On a moment's thought, that does seem a trifle odd, given that there are counters for lots of strange things, including other performance hits that have far milder consequences per event (e.g., logical CPU cycle lockouts caused by conflict with the other logical CPU in a core, IIRC) than TLB misses have. If I had the Intel processor manuals that describe the various counters that the chips support, I'd have a better clue where to look in the FreeBSD documentation or maybe how to query the hardware itself (using a small utility that is part of the base system) to find out whether there are any TLB-related event counters available. You might dig around in your system to see whether LINUX shows support for any TLB-related event counters. Something else you might check on if you're considering adding scraps of code to tor to use LINUX's huge page support is whether huge pages get page-fixed (a.k.a. wired). FreeBSD's superpages don't. If the kernel decides it has to snatch any base page frames out of a superpage, it simply demotes a superpage to the next smaller page size supported on that processor type, then demotes one of those, etc. until it can free up individual base pages. That means it can't cause the sort of problem that tying up several hundred megabytes of page frames by fixing a large process's pages into them can create for the rest of whatever is running in the same machine because a superpage's base (i.e., underlying, smallest sized) page frames can always be freed for reuse by something else if the system really needs them. On i386 and amd64 architectures, there are only two page sizes (4 KB and 4 MB) available anyway, so there's only one step available in either the promotion direction or the demotion direction. (ia64 (i.e., Itanium) has a several more steps available, IIRC, and I think the alpha processors have about five.) In any case, your Xeon(s) ought to be able to benefit considerably from running your gargantuan tor process in 4 MB pages instead of 4 KB pages. I'm not sure about Xeons, but the regular, non-server i386 and amd64 chips by Intel only have 64 TLB entries for instruction (i.e., text) pages and 64 TLB entries for data (i.e., data and stack) pages, so that means if an instruction working set or a data working set exceeds 256 KB, then the process running with base (4 KB) pages will end up thrashing the relevant TLB(s), stalling the processor every time while the MMU walks through the page table. If you have HTT-enabled Xeons, then remember that the two logical CPUs in each core share the same MMU and L1 and L2 caches, as well as the same bus to and from main memory, which can further
Tor-network-status wishlist (was Re: [or-talk] where are the exit nodes gone?)
On Sun, Apr 11, 2010 at 03:23:16PM +0200, Olaf Selke wrote: maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. Here's my chance to remind people about http://archives.seul.org/or/talk/Jan-2008/msg00300.html :) I think #1 and #4 have been done, but #2 and #3 remain. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Sun, Apr 11, 2010 at 9:01 AM, Scott Bennett benn...@cs.niu.edu wrote: On Sun, 11 Apr 2010 15:23:16 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: [snipped] maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. You might communicate with Kasimir Gabert about that. I think he said some months ago that he was going to do that for his torstatus stuff, so what you want might already be written. I've been really busy these past numerous months, but that code is written. You can find it in the trunk version of TorStatus. I'm giving myself two weeks at the end of this semester to get a new interface that was designed for me implemented, redo the PHP frontend code base, and push out a new version. :) You can get the actual bandwidth code already, however. I used a moving average to calculate it. Thanks, Kasimir -- Kasimir Gabert *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Sun, Apr 11, 2010 at 10:05 AM, Kasimir Gabert kasimi...@gmail.com wrote: On Sun, Apr 11, 2010 at 9:01 AM, Scott Bennett benn...@cs.niu.edu wrote: On Sun, 11 Apr 2010 15:23:16 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: [snipped] maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. You might communicate with Kasimir Gabert about that. I think he said some months ago that he was going to do that for his torstatus stuff, so what you want might already be written. I've been really busy these past numerous months, but that code is written. You can find it in the trunk version of TorStatus. I'm giving myself two weeks at the end of this semester to get a new interface that was designed for me implemented, redo the PHP frontend code base, and push out a new version. :) You can get the actual bandwidth code already, however. I used a moving average to calculate it. Thanks, Kasimir -- Kasimir Gabert Hello again, I believe you're bandwidth is being calculated to be 14523 KB/s -- impressive! http://trunk.torstatus.kgprog.com/index.php?SR=BandwidthSO=Desc Thanks, Kasimir -- Kasimir Gabert *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor-network-status wishlist (was Re: [or-talk] where are the exit nodes gone?)
On Sun, Apr 11, 2010 at 10:04 AM, Roger Dingledine a...@mit.edu wrote: On Sun, Apr 11, 2010 at 03:23:16PM +0200, Olaf Selke wrote: maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. Here's my chance to remind people about http://archives.seul.org/or/talk/Jan-2008/msg00300.html :) I think #1 and #4 have been done, but #2 and #3 remain. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ Hi Roger, #2 and #3 are implemented in the current trunk version. #1, however, is only partially implemented. Thanks, Kasimir -- Kasimir Gabert *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Sun, 11 Apr 2010 10:05:06 -0600 Kasimir Gabert kasimi...@gmail.com wrote: On Sun, Apr 11, 2010 at 9:01 AM, Scott Bennett benn...@cs.niu.edu wrote: =A0 =A0 On Sun, 11 Apr 2010 15:23:16 +0200 Olaf Selke olaf.se...@blutmag= ie.de wrote: [snipped] maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. =A0 =A0 You might communicate with Kasimir Gabert about that. =A0I think = he said some months ago that he was going to do that for his torstatus stuff, so what you want might already be written. Thanks for responding to that so quickly, Kasimir. It should save Olaf some time. I've been really busy these past numerous months, but that code is written. You can find it in the trunk version of TorStatus. I'm giving myself two weeks at the end of this semester to get a new interface that was designed for me implemented, redo the PHP frontend code base, and push out a new version. :) You can get the actual bandwidth code already, however. I used a moving average to calculate it. Did you just use a boxcar average? If so, it will have significant (I'd guess a peak of about 2% of true amplitude) Gibbs ringing in the result, but given the erratic quality of the source data (i.e., the mix of varying lengths of records, times of day, and so forth) and given how the results will be used, it's probably no big deal, and no one is likely to realize the ringing is present when they look at a graph of it anyway. How many 15-minute periods wide is the window? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Polipo and dnsUseGethostbyname - what is the best option and does it matter?
On Thu, Apr 08, 2010 at 04:24:06PM +0100, pump...@cotse.net wrote 2.7K bytes in 64 lines about: The standard Polipo configuration file for Ubuntu located at https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/config/polipo.conf should replace the configuration file one downloads when Polipo is I believe you mean The standard polipo configuration file for safely using Tor. The standard ubuntu polipo config doesn't use Tor. this setting in the configuration file is not important? Or does Polipo do the DNS resolution before traffic is passed on to Tor in which case the configuration file is crucial? In other words, when is DNS resolved when using Tor and Polipo? In practice, with that config file, dns queries are passed to tor directly for resolution, not being done by polipo nor the actual system resolver. If you change the options, you should see polipo query your local dns resolver either directly, or via gethostbyname. I agree the config needs more clarity and to match an actual option as specified in the info page. I'll add it as a bug to research. This is also the case for TBB, not necessarily so for non-tbb use cases. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Polipo and dnsUseGethostbyname - what is the best option and does it matter?
and...@torproject.org wrote: In practice, with that config file, dns queries are passed to tor directly for resolution, not being done by polipo nor the actual system resolver. Thank you for the confirmation. If you change the options, you should see polipo query your local dns resolver either directly, or via gethostbyname. So, the option reluctantly for dnsUseGethostbyname would mean DNS requests are done by Tor and are only done by Polipo if Tor DNS fails or does it mean DNS requests are now done by Polipo usually and only done by the system resolver if Polipo DNS fails? The manual says for reluctantly - Polipo tries to speak DNS and falls back to the system resolver if a name server could not be contacted. I am unclear where it tries to speak DNS - would this be before Tor or would the DNS still get pushed through Tor even though the configuration file has been modified? I agree the config needs more clarity and to match an actual option as specified in the info page. I'll add it as a bug to research. I am still confused regarding what yes actually means - does it refer to the default which is reluctantly or does it mean nothing to Polipo and is just ignored? In which case why not just comment this option out? Thank you for your help! *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Polipo and dnsUseGethostbyname - what is the best option and does it matter?
If you change the options, you should see polipo query your local dns resolver either directly, or via gethostbyname. But if you change it to false would that not be the safest option - from what I can gather in this situation Polipo would never do its own DNS. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Polipo and dnsUseGethostbyname - what is the best option and does it matter?
On Sun, Apr 11, 2010 at 11:14:31PM +0100, Matthew wrote: If you change the options, you should see polipo query your local dns resolver either directly, or via gethostbyname. But if you change it to false would that not be the safest option - from what I can gather in this situation Polipo would never do its own DNS. As I understand it, the question is whether polipo should use the system call named gethostbyname(), or if it should use its own internal non-blocking dns resolve code. The question isn't should polipo disable dns resolves or not. Back when I picked the yes answer, there were two reasons: A) polipo's internal dns resolve code didn't look at /etc/hosts, so when I set my proxy to localhost:9050, polipo would try to resolve localhost, and it ended up asking my ISP where localhost was. My ISP helpfully answered 127.0.0.1, but what if my ISP had answered something else? Really bad news. B) There were some remote buffer overflows in polipo's internal dns resolve code. Given those, and since polipo shouldn't be doing any dns resolves anyway when it's using a socks5 proxy, I figured I'd go for the choice that exposed less surface area. I'm not sure whether either of these bugs are fixed at present (ugh). So I'd recommend sticking with yes (or true, I guess it's called now). --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
