Re: glibc Errors for TBB 1.0.17
Just upgraded from Tor Browser Bundle 1.0.14 to 1.0.17 for Linux i686, running on Debian lenny/5.0.6. Getting glibc errors: Launching Tor Browser Bundle for Linux in /path/to/tor-browser_en-US ./App/vidalia: /lib/i686/cmov/libc.so.6: version `GLIBC_2.9' not found (required by /path/to/tor-browser_en-US/Lib/libQtGui.so.4) ./App/vidalia: /lib/i686/cmov/libc.so.6: version `GLIBC_2.10' not found (required by /path/to/tor-browser_en-US/Lib/libQtNetwork.so.4) ./App/vidalia: /lib/i686/cmov/libc.so.6: version `GLIBC_2.9' not found (required by /path/to/tor-browser_en-US/Lib/libQtCore.so.4) Current installed version of glibc is 2.7 (standard Debian version). I guess this reflects a change in the build environment for TBB? Yes, and it looks like a bug to me. Added to Trac as #2225 (https://trac.torproject.org/projects/tor/ticket/2225). Thanks Robert. I run Tor from a USB drive, so the portable all-in-one Tor/Vidalia/FF bundle is excellent. Happy to build the TBB from source/components ... are there instructions for the process? Or some other way around the problem? See https://gitweb.torproject.org/torbrowser.git for the build scripts, but we would prefer to fix this bug. Will certainly have a look around. Happy to help if there's anything I can do. Thanks -C *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Very low performance in CriptolabTORRelays*
Hi, I'm the admin of CriptoLabTorRelays[1][2][3][4] As you can see at [1][2][3][4] our relays are having almost no transfer rate (3KB or so) It started on Monday 14 of November and after some testing we came to a conclusion... Our Univeristy (our workplace) somehow filtered Tor without us noticing. I need your help to get some proofs of the filter being applied so we can make a statement and ask for permission. Looking at the logs I see a frequently [debug] TLS error: unexpected close while reading (SSL_ST_OK) Tor: 0.2.2.18-alpha-2 SSL: 0.9.8o-3 Thanks. PD: We even tried using bridges (as in https://bridges.torproject.org/) with no luck. [1] http://torstatus.blutmagie.de/router_detail.php?FP=b0ebd113c29fa546596dae34e88b8ad82ffdaa3d [2] http://torstatus.blutmagie.de/router_detail.php?FP=a65f3cbe32d8b52afcd2b09f0258d5cef1b12f48 [3] http://torstatus.blutmagie.de/router_detail.php?FP=1d6a27aed313662e35f550b212335d4797dccdf6 [4] http://torstatus.blutmagie.de/router_detail.php?FP=3e628de58df60a228c38fa83d000439d129d00cc -- --- Daniel Franganillo Corrales --- e-mail: dani...@dilmun.ls.fi.upm.es --- CriptoLab. Despacho 6305. Facultad de Informática. Campus de Montegancedo S/N Universidad Politécnica de Madrid. Boadilla del Monte. Madrid (Spain) Teléfono - 91 336 (3673) --- smime.p7s Description: S/MIME Cryptographic Signature
Re: Active Attacks - Already in Progress?
On Sun, 28 Nov 2010 17:54 -0800, Mike Perry mikepe...@fscked.org wrote: Rather than cripple the network by forcing more clients to use slower nodes more often, we have opted to try to document the process of running a high capacity Tor exit node: http://archives.seul.org/tor/relays/Aug-2010/msg00034.html In my research (posted earlier to this list), I did not find an issue with exit relays. The relays which were reliably chosen as part of my circuit were often the first or second relay in my circuit - not the exit relay. Please help us to create the network we *wish* we had. I'm running a relay of my own, no worries. -- http://www.fastmail.fm - Accessible with your email software or over the web *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
