Tor 0.2.0.23-rc is out
Tor 0.2.0.23-rc is the fourth release candidate for the 0.2.0 series. It makes bootstrapping faster if the first directory mirror you contact is down. The bundles also include the new Vidalia 0.1.2 release: http://trac.vidalia-project.net/browser/vidalia/trunk/CHANGELOG This is a release candidate! That means that we don't know of any remaining show-stopping bugs, and this will become the new stable if there are no problems. Please test it, and tell us about any problems that you find. https://www.torproject.org/download#Dev Changes in version 0.2.0.23-rc - 2008-03-24 o Major bugfixes: - When a tunneled directory request is made to a directory server that's down, notice after 30 seconds rather than 120 seconds. Also, fail any begindir streams that are pending on it, so they can retry elsewhere. This was causing multi-minute delays on bootstrap. signature.asc Description: Digital signature
Re: A couple of annoying bugs in the latest RC
On Tue, 25 Mar 2008, Andrew Del Vecchio wrote: Has anyone else noticed the following bugs, specifically on Ubuntu 7.10? A) When upgrading/installing/removing packages using apt, Tor tries to initiate itself for no apparent reason, which results in a non-fatal but very annoying error from apt that wastes buffer space, or requires clicking a button if you're in X using Synaptec. You realize that a very annoying error is not very useful as an error/bug report, right? Peter
Re: [hermetix] Tor relay going down
One interesting feature of having both is the possibility to offer better and safer anonymity to your users by providing access to the remailer services. Something likehttp://v6ni63jd2tt2keb5.onion/mm-anon-email.htm Or torify mixmaster will work in future with following settings in /etc/mixmaster/client.conf CHAIN gpfa,*,*,* SMTPRELAY lcr3k7ljvm436gli.onion Other ideas we can discuss off list. If you were interested in, please contact me. Karsten
Re: Weird-looking circuits in Vidalia
On Tuesday 25 March 2008 21:05:49 you wrote: snip Ok, thanks for the info! How about replacing these strings with text like Directory Request in future? That would be be little more descriptive. I was thinking the same thing recently. I even went so far as to start a proposal - because there are numerous tunneled requests in Tor that aren't user initiated these days. I didn't get very far with it, and I'm not sure it's particularly straightforward in all cases. But it looks to be easy enough for these tunneled requests. Here's what I was thinking: Motivation/Overview: Tor now tunnels a large number of network maintenance operations through circuits on the Tor network. Many of these operations are not initiated by the user. Both TorK and Vidalia display active connections to the user and these maintenance operations may cause alarm, distress, and even panic if displayed without at least some attempt at explanation. If Tor were to provide a STREAM_PURPOSE string as an extension for the existing STREAM_EVENT controllers would be able to determine whether to display a stream to the user, or more likely provide a mechanism for explaining the purpose of the connection to the curious user. Specify a new PURPOSE field for extended stream events as follows: Index: doc/spec/control-spec.txt === --- doc/spec/control-spec.txt (revision 14111) +++ doc/spec/control-spec.txt (working copy) @@ -984,6 +984,7 @@ 650 SP STREAM SP StreamID SP StreamStatus SP CircID SP Target [SP REASON= Reason [ SP REMOTE_REASON= Reason ]] [SP SOURCE= Source] [ SP SOURCE_ADDR= Address : Port ] + [SP PURPOSE= Reason] CRLF StreamStatus = @@ -1033,6 +1034,13 @@ that requested the connection, and can be (e.g.) used to look up the requesting program. + Purpose = DIR_FETCH / UPLOAD_DESC / DNS_REQUEST / + USER / DIRPORT_TEST + + The PURPOSE field is provided only for NEW and NEWRESOLVE + events, and only if extended events are enabled (see 3.19). Clients MUST + accept purposes not listed above. + signature.asc Description: This is a digitally signed message part.
Re: [hermetix] Tor relay going down
On Wed, Mar 26, 2008 at 10:50:40AM +0100, Karsten N. wrote: One interesting feature of having both is the possibility to offer better and safer anonymity to your users by providing access to the remailer services. This was supposed to end with through Tor hidden services... Something likehttp://v6ni63jd2tt2keb5.onion/mm-anon-email.htm Or torify mixmaster will work in future with following settings in /etc/mixmaster/client.conf CHAIN gpfa,*,*,* SMTPRELAY lcr3k7ljvm436gli.onion I see you still got the idea ;) Cheers pgpJO3zPh1sMU.pgp Description: PGP signature
