Re: Tor 0.2.2.11-alpha and 0.2.2.12-alpha are out
On Thu, 22 Apr 2010 19:39:07 -0400 Roger Dingledine wrote: >Tor 0.2.2.12-alpha fixes a critical bug in how directory authorities >handle and vote on descriptors. It was causing relays to drop out of >the consensus. > Was there some point in releasing the above without your directory fetch circuit timeout patch, at least as a temporary fix that might be replaced by something better in 0.2.2.13-alpha? 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: Very strange exit-node? Bad or evil exit-node?
Roger Dingledine wrote: > On Thu, Apr 22, 2010 at 06:08:09AM +, James Brown wrote: > >> The exit-node which have ip 192.251.226.206 and named >> anonymizer2.blutmagie.de behaves itself as probably an evil exit-node. >> I can't change it practically at all. When I give command "pkill -1 tor" >> to my system many times it remains as my exit-node. >> Futhermore, it remains as my exit node when I restart my tor-daemon >> through /etc/init.d/tor restart. >> I can change it only by restarting my local network router and my >> tor-daemon at the same time, but in one or two minutes I can see that >> that tor-node become as my exit-node again. >> How can I to overcome that?! >> > > The way you overcome that is you get more people to run fast exit relays > for the Tor network. > > Right now not enough people do, so you end up using blutmagie a lot. > > The Tor network is a community, and it sure does need to grow if it wants > to handle all the people who want safety around the world. > > --Roger > > *** > To unsubscribe, send an e-mail to majord...@torproject.org with > unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ > > Very thanks for that information. I was very afraid and it seemed to me that anybody took control over the Tor net, but it was only my paranoia. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Tor 0.2.2.11-alpha and 0.2.2.12-alpha are out
Tor 0.2.2.12-alpha fixes a critical bug in how directory authorities handle and vote on descriptors. It was causing relays to drop out of the consensus. Tor 0.2.2.11-alpha fixes yet another instance of broken OpenSSL libraries that was causing some relays to drop out of the consensus. (Windows bundles will be available whenever Andrew gets around to making them; we're trying to stick to a policy of announcing alphas on time rather than waiting for every package.) https://www.torproject.org/download.html.en Changes in version 0.2.2.12-alpha - 2010-04-20 o Major bugfixes: - Many relays have been falling out of the consensus lately because not enough authorities know about their descriptor for them to get a majority of votes. When we deprecated the v2 directory protocol, we got rid of the only way that v3 authorities can hear from each other about other descriptors. Now authorities examine every v3 vote for new descriptors, and fetch them from that authority. Bugfix on 0.2.1.23. - Fix two typos in tor_vasprintf() that broke the compile on Windows, and a warning in or.h related to bandwidth_weight_rule_t that prevented clean compile on OS X. Fixes bug 1363; bugfix on 0.2.2.11-alpha. - Fix a segfault on relays when DirReqStatistics is enabled and 24 hours pass. Bug found by keb. Fixes bug 1365; bugfix on 0.2.2.11-alpha. o Minor bugfixes: - Demote a confusing TLS warning that relay operators might get when someone tries to talk to their OrPort. It is neither the operator's fault nor can they do anything about it. Fixes bug 1364; bugfix on 0.2.0.14-alpha. Changes in version 0.2.2.11-alpha - 2010-04-15 o Major bugfixes: - Directory mirrors were fetching relay descriptors only from v2 directory authorities, rather than v3 authorities like they should. Only 2 v2 authorities remain (compared to 7 v3 authorities), leading to a serious bottleneck. Bugfix on 0.2.0.9-alpha. Fixes bug 1324. - Fix a parsing error that made every possible value of CircPriorityHalflifeMsec get treated as "1 msec". Bugfix on 0.2.2.7-alpha. Rename CircPriorityHalflifeMsec to CircuitPriorityHalflifeMsec, so authorities can tell newer relays about the option without breaking older ones. - Fix SSL renegotiation behavior on OpenSSL versions like on Centos that claim to be earlier than 0.9.8m, but which have in reality backported huge swaths of 0.9.8m or 0.9.8n renegotiation behavior. Possible fix for some cases of bug 1346. o Minor features: - Experiment with a more aggressive approach to preventing clients from making one-hop exit streams. Exit relays who want to try it out can set "RefuseUnknownExits 1" in their torrc, and then look for "Attempt by %s to open a stream" log messages. Let us know how it goes! - Add support for statically linking zlib by specifying --enable-static-zlib, to go with our support for statically linking openssl and libevent. Resolves bug 1358. o Minor bugfixes: - Fix a segfault that happens whenever a Tor client that is using libevent2's bufferevents gets a hup signal. Bugfix on 0.2.2.5-alpha; fixes bug 1341. - When we cleaned up the contrib/tor-exit-notice.html file, we left out the first line. Fixes bug 1295. - When building the manpage from a tarball, we required asciidoc, but the asciidoc -> roff/html conversion was already done for the tarball. Make 'make' complain only when we need asciidoc (either because we're compiling directly from git, or because we altered the asciidoc manpage in the tarball). Bugfix on 0.2.2.9-alpha. - When none of the directory authorities vote on any params, Tor segfaulted when trying to make the consensus from the votes. We didn't trigger the bug in practice, because authorities do include params in their votes. Bugfix on 0.2.2.10-alpha; fixes bug 1322. o Testsuite fixes: - In the util/threads test, no longer free the test_mutex before all worker threads have finished. Bugfix on 0.2.1.6-alpha. - The master thread could starve the worker threads quite badly on certain systems, causing them to run only partially in the allowed window. This resulted in test failures. Now the master thread sleeps occasionally for a few microseconds while the two worker-threads compete for the mutex. Bugfix on 0.2.0.1-alpha. signature.asc Description: Digital signature
Re: Tor-friendly dedicated hosting
On Sat, 17 Apr 2010, krishna e bera wrote: https://wiki.torproject.org/noreply/TheOnionRouter/GoodBadISPs Please fee free to update that page under the appropriate region heading if your ex-ISP is not listed. Laws and practice and availability vary quite a bit with country and ISP. I think there was an ISP policy comparison project underway but i cannot find the reference atm. I have not seen any discussion of running a Tor node on an Amazon AWS instance... Seems like a no-brainer ... a virtual linux system that you are root on, dirt cheap bandwidth, and the ability to clone/scale/etc. Is anyone doing this ? Any comments/predictions ? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Firefox configurations for tor with Mac ppc
-Original Message- From: Hanspeter Spalinger To: or-talk@freehaven.net Sent: Wed, Apr 21, 2010 6:37 pm Subject: Re: Firefox configurations for tor with Mac ppc -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 21.04.10 02:53, schrieb zzzjethro...@email2me.net: > Here's a few more. Hope someone notices them and checks them out. Should I change my mac? > > browser.safebrowsing.enabled falsemac is true > browser.safebrowsing.malware.enabledfalsemac is true safebrowsing is checking addresses against known "bad" sites. this list will be retrieved from google periodicaly. This is the "enumerate badware" aproach which is inheriently flawed. If you use active blockers like noscript and alike, you gain much more security (eg, the "whitelist known good stuff" aproach) (http://kb.mozillazine.org/Browser.safebrowsing.enabled) > browser.search.suggest.enabledfalsemac is true you may want to turn this off since it may leak information to outside. (http://kb.mozillazine.org/Browser.search.suggest.enabled) > extensions.torbutton.locked_nodetrue mac is false > extensions.torbutton.proxies_applied truemac is false > extensions.torbutton.restore_tor true mac is false > extensions.torbutton.settings_applied true mac is false > extensions.torbutton.tor_enabled truemac is false Those are state settings for torbutton. i dont think you should change them. Read http://www.torproject.org/torbutton/design/#id2977751 for details > > network.cookie.cookieBehavior 1 mac is 2 cookies disabled on mac. good for privacy. you may want to use a plugin like cookiesafe to manage cookies in a more controlable way (the "always off" doesnt work for some sites). (http://kb.mozillazine.org/Network.cookie.cookieBehavior) > network.protocol-handler.warn-external.mailtotruemac is false > network.protocol-handler.warn-external.news true mac is false > network.protocol-handler.warn-external.nntp truemac is false > network.protocol-handler.warn-external.snewstruemac is false This decides if you get a warning before open urls that will be handled by external application. Eg, click a mailto://-link and it opens your mail-application. Your mac will open mail and news without asking if you click a link. (http://kb.mozillazine.org/Network.protocol-handler.warn-external-default) -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkvO42oACgkQpjmLjrU66/4ovgEAqCdVGqWP3KetGwUmB43kJe3T mIqZS8b/BAmykh3k19IA/RYJdeqnt5G3k9BO9aAFKhuXiS3gO5FR2hbj0WSww5cq =juC6 -END PGP SIGNATURE- *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ Hi and thanks for your response. I just want to be sure I understand what you are saying so please excuse my denseness. the extension.torbutton configs I sent above are all different on my Mac so I am assuming you mean I should change my mac to match the "state settings" as you called them. Is that correct? And what about "mailto", "news", "nntp" and "snews"? I should I make my mac true for them all? And of course for the first two, concerned with safebrowsing, should I change my mac? I had found Firefox configuration settings on the Hidden Wiki, that had recommended that network.protocol-handler.external-default be set at "false" and all subsettings for network.protocol-handler.external-default be set to "false". There are 16 of them; afp, data, disk, disks, hcp, help, javascript, mailto, moz-icon, ms-help, news, nntp, shell, snews, vbscript and vnd.ms.radio. Subsequently, network.protocol-handler.warn-external-default was to be set at "true", with all subsettings also set to "true". There are four: mailto, news, nntp and snews. Thanks for any clarity on this issue for me.
