Re: [tor-talk] Possibly Smart, Possibly Stupid, Idea Regarding Tor & Linux Distributions
Hi Alec, > On 04 Jan 2017, at 12:24, Alec Muffettwrote: > > Actually, I don't believe that you do disagree with the problem statement > :-) > > I believe that you may concerns with one of my proposed solutions to the > problem, and that's okay because I do too. :-) > > Let me see if I can reframe the problem statement, and maybe pose another > alternative? > > > == Problem Statement, Reframed == > > I believe that, at the moment, the Debian "installiverse" assumes that > people who want to use Tor -- on a server -- are skilled and knowledgeable. > > Case in point: > > * For setting up relays you want to stand on a solid foundation, so Debian > "stable" works really well. > > * But I will bet that you are not running the relays by using the 0.2.5 > codebase which it offers. :-) I currently maintain 15 debian systems privately (mostly VMs). All but one of them have tor installed. Only four of them use the tpo repository (those provide either public or private network relays or dirauths). The others use regular debian-provided packages. > ** (Not least, I believe that the crypto in anything older than 0.2.7.* > will be a lot slower?) This doesn't matter unless you run a high-performance relay. Also, I think going from 0.2.7.x to 0.2.8.x increased my cpu usage on my busy relay. > * So I believe that you are probably not running 0.2.5 because you are > skilled enough to use backports or roll your own. I consider myself skilled enough, but I'd rather keep the amount of custom repositories to the bare minimum. Especially my more trusted computers don't get additional repos if I can help it at all. > Now, for contrast, consider Tor Browser Bundle: > > * TBB is designed for use by "normal people". > > * It is not running 0.2.5.* either, because it would be foolish to push out > such "old code" to the clients. > > * TBB runs code which we might call "Tor Stable", being probably a similar > version to the code which you yourself would deploy for a relay. > > * Therefore: "Debian Stable" is not offering "Tor Stable", instead it is > offering "Tor Stale", or "Tor Stagnant". > > > == Summary == > > Debian Stable, by default, offers code that we would deprecate on the > servers, and would never ship on the clients. Well, we're not currently deprecating it. It's still recommended by the dirauths to run one of those versions. I am not sure, but I think the main reason to ship recent Tors in TB is because we have to ship new Firefox releases anyway, so the pain of adding in some more software is minimal. That and the increased benefit of new security features, better blocking resistance, etc. > How is this to anyone's benefit? > > It's like the old chef's rule about "never cook with wine that you would > not drink by yourself" > > > == Challenge == > > Consider schools. Consider journalists, hobbyists, non-CS university > students. Consider "IoT tinkerers". I'm a sysadmin at my school for a student computer pool, we have around 13k users and around 250 physical machines for students to use. The biggest thing I'd wish for were a system-wide installable Tor Browser that we can keep updated for our users. And we would do it, just like we keep everything else updated (for that job, while we do run debian stable, we're constantly chasing down last versions for a variety of software where the latest version is necessary for teaching or because it was requested by some students). > Consider people who don't know what "vim" does. :-) > > These are people who can use Tor for good purposes, and I believe that Tor > should seek to "enable" them, and make Tor easier to use for them. > > But the Tor code which comes with Debian, and thus with Raspbian, and > kinda-with-Ubuntu, is (by the metaphor) bad wine which you would never > offer to these people to actually drink nor cook with. In my world, these people don't really use apt-get, they will look to install something they can download from a website while following some instructions. TB seems to fit for that mental model. I just see a kind of disconnect between the hapless user and the advanced usecases where TB is not enough. If the user does know apt-get, they could install the torbrowser-launcher package on debian stable, which helps get them a shiny new TB. Admittedly, I have no idea about availability on Ubuntu. > In my previous e-mail I suggested removing Tor from Debian precisely > because of this future-staleness problem. I find this to be totally the wrong thing. We all want all our users to run our latest code, nownownow. It's a completely understandable line of thought, after all we're developers and passionately implemented features, created better architecture, debugged and fixed bugs for days. I think it's still kind of arrogant/presumptuous. As long as there are no reasons to kill an older version (like security issues, incompatability with a newer protocol where the cost of keeping to support the older
Re: [tor-talk] Possibly Smart, Possibly Stupid, Idea Regarding Tor & Linux Distributions
Hi Alec, thanks for your thoughts. I have just one very quick comment, but it seems you haven't addressed it yet: > On 03 Jan 2017, at 03:04, Alec Muffettwrote: > > Where I feel that issues arise are in the older Ubuntus and Debians. > > Again, I understand that there are "backports" repos, but my experience of > encouraging new people to adopt Tor is one of trying to help them to jump > over the hurdles which we immediately place in their way. I install Debian stable on my servers precisely because they don't necessarily track the latest packages for everything. When I have installed them and they work, I don't need to do super frequent maintenance - I get security updates, but not much more. Tor updates for relays frequently require you to read the changelog carefully to have a sane upgrade path, other software does that too - having to do that constantly when you're not actually need any of the new features is super annoying imo. There are some select pieces of software where this isn't the case - the kernel on my gaming system, the tor package on my relays, some others - where I selectively use backports or custom repositories. I would imagine if the main purpose of my machines wasn't providing tor relays, I'd prefer to just run whatever debian stable provides. > So this is kinda the problem statement: > > - old versions of Tor are out there in the wild > > - they pollute the software environment, representing "cognitive load" / > barriers to easy adoption and learning > > - adoption and learning are critical to the growth in use of Tor I guess I just disagree with this problem statement. Cheers Sebastian -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] 33c3 and tor?
Hi, > On 20 Dec 2016, at 14:37, fatalwrote: > an early version of the fahrplan for 33c3 is released¹ (btw. also the > 33c3 app on f-droid is already available). > > I couldn't find any talks from the tor-project yet, but maybe I've > overlooked them? Will there be any? > > And will there be a tor relay operators meetup? > > Thanks > > f. > > ¹ https://fahrplan.events.ccc.de/congress/2016/Fahrplan/ CCC has opted not to accept any talks by Tor this year, but there will be Tor people there. Someone might organize a relay operators meetup. Cheers Sebastian -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Is Tor 32 bit only?
> On 13 Dec 2016, at 01:14, hi...@safe-mail.net wrote: > > I was just wondering if you compile Tor on a 64 bit Linux distro, will it > make a 64 bit executable? Or is it 32 bit only? Would be nice if it had > supported 64 bit processing. Tor has full support for x86_64 (it's the preferred platform, even). Cheers Sebastian -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Is it possible to get a Node-Chain with 3 nodes from ONE country?
> On 21 Mar 2016, at 08:27, Ben Stoverwrote: > > Is it possible to get a Node-Chain with 3 nodes from ONE country? Yes. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Directory problems?
> On 18 Mar 2016, at 15:17, Sebastian Niehaus> wrote: > Am 18.03.2016 um 14:11 schrieb tor_t...@arcor.de: > >> then start connect to tor. Also you can open AdvOR.ini and this to [torrc] >> section. > > If there are problems with multiple authorities there might be something > strange going on. > > Am am not sure if I can take my tin foil hat off or if "someone" tries > to mess with some vital parts oft the tor network. Well, afaict the purpose of those lines is to basically bring an outdated Tor client back to live, by teaching it about the new identity of a few directory authorities as they're currently configured by Tor, not a sign that someone is actively messing with dirauths. Cheers Sebastian -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Invalid consensus today
Hi there, different threads on this list have already begun popping up about today's 0700 UTC consensus. The reason is that the dirauths did not produce a consensus that was signed by all 9, but rather the vote was split (this happens sometimes and usually causes no great concern). The dirauth dannenberg was on the winning side of split, so the produced consensus had just 5 signatures, the minimum required amount for a consensus to be valid. Unfortunately, its key changed recently and that change has not yet been communicated via a new Tor stable release. Thus, any Tor not configured to trust dannenberg's new key would've rejected the consensus as signed by just 4 directory authorities. Now that all 9 are in agreement again this problem is gone and there should be no more logs appearing from this incident. Cheers Sebastian -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Does Facebook Onion Work?
> On 17 Feb 2016, at 22:15, David Goulet <dgou...@ev0ke.net> wrote: > On 17 Feb (22:10:44), Sebastian Hahn wrote: >>> On 17 Feb 2016, at 21:17, blo...@openmailbox.org wrote: >>> Does Facebook still provide an onion link? >>> >>> Because I've tried https://www.facebookcorewwwi.onion/ and I get a >>> neverending loop in which the site loads and loads and loads... >>> >>> Any ideas? >> >> the correct address is https://facebookcorewwwi.onion/ - never use >> www. in onionland. > > Hrm, actually the subdomains are important for Facebook. They will redirect > you to the www. if omitted and since the SSL certificate is an EV wild card, > it can take anything as subdomain. So with that, they can easily regex the URL > once it arrives to the HS and send it to the right place internally using only > the subdomain. > > All the languages for instance are subdomain "fr-ca.", "it-it.", "en-us.", > etc... ah, I don't ever use facebook so I didn't notice that they actually make use of that. Could you reproduce the issue, then? Cheers Sebastian signature.asc Description: Message signed with OpenPGP using GPGMail -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Does Facebook Onion Work?
Hi blobby, > On 17 Feb 2016, at 21:17, blo...@openmailbox.org wrote: > Does Facebook still provide an onion link? > > Because I've tried https://www.facebookcorewwwi.onion/ and I get a > neverending loop in which the site loads and loads and loads... > > Any ideas? the correct address is https://facebookcorewwwi.onion/ - never use www. in onionland. Cheers Sebastian -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] #nottor
> On 03 Dec 2015, at 08:30, Andreas Kreywrote: > > On Wed, 02 Dec 2015 17:32:22 +, coderman wrote: > ... >> the collective defect identification efforts in real-time have moved >> to channel #nottor. > > Speaking of which - what's up with #tor and #nottor. > > I'm using irssi (and am relatively clueless to IRC). > > When I /join #tor without a registered nick, I end up > in ##nottor ('#tor ##nottor Forwarding to another channel'). > I can join #nottor. > > When I try to join #nottor with a registered nick, > I get told 'Cannot join to channel #nottor (You must be invited)' > I can join #tor. > > Boggle? > > Andreas You're on the FreeNode irc network, not OFTC's. Cheers Sebastian -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] tor --verify-config opens listeners? (for short timeframe)
On 23 Feb 2015, at 23:33, Nusenu nus...@openmailbox.org wrote: I stumpled on this while debugging an ansible role. It basically does this: tor --verify-config -f foo.torrc tor -f foo.torrc while the torrc is fine and the first tor execution retuns 0 the second one will *sometimes* fail (depends on exact timing) because 'tor --verify-config' apparently occupies the ports - so the second tor invocation can't start anymore because the ports are still in use. same problem with (I didn't expect that): tor --verify-config -f foo.torrc tor -f foo.torrc If you want to reproduce it you might have to try few times till it fails (and don't forget to kill tor when it didn't fail). If this is expected behaviour please update the manual page to include information that --verify-config actually does quiet a bit more than reading the configuration file :) This is a bug. Feel free to file it and assign it to me (Sebastian on trac.torproject.org), I'll take care of it in a few days. Cheers Sebastian signature.asc Description: Message signed with OpenPGP using GPGMail -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Removal of Vidalia content from our website
Hi tor-talk, we have stopped updating our Vidalia bundles a long time ago, today I've removed the download links and related documentation from the Website. At this time, Vidalia has been unmaintained for too long to be a recommended solution. Cheers Sebastian signature.asc Description: Message signed with OpenPGP using GPGMail -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor and solidarity against online harassment
On 14 Dec 2014, at 07:06, Mirimir miri...@riseup.net wrote: Is https://blog.torproject.org down? http://www.downforeveryoneorjustme.com/blog.torproject.org = yes DDoS? It's up intermittently. I'd suspect ddos atm, yes. Cheers Sebastian -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Replacing a dirauth: Welcome longclaw
Hi there, after many years of service Mike Perry is retiring his dirauth, turtles. It hasn't been functional for some time, so we decided to add a new dirauth to replace it. The new dirauth will be hosted by Micah Anderson (hi Micah). It'll bring some more geographical diversity to the Tor network, as it is run out of Hong Kong. Its name will be longclaw. Please join me in thanking Mike for his dedication to Tor and the Tor network and his focus on the Tor Browser which necessitated this change. Welcome Micah, and thanks for taking up the challenge. If you have any questions or concerns, don't hesitate to hit reply. Thanks Sebastian signature.asc Description: Message signed with OpenPGP using GPGMail -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Changes for dirauth gabelmoo
Hello again, On 05 Sep 2014, at 01:21, Sebastian Hahn sebast...@torproject.org wrote: it's been almost 3 years since I started maintaining gabelmoo, and I'd like to give you an update. Soon, gabelmoo will get a new hosting environment along with a much-needed hardware upgrade. Along with a much better connection, I'll hope gabelmoo can serve the Tor network for quite some time yet. Unfortunately, this means an IP address change, which necessitates a new Tor version. Once we are ready to release one anyway and the migration has taken place, we'll get this going. And this is your heads up that the move has been completed. You should not notice any kind of disturbance from this, and everything should continue to work as normal. The new address, for those curious, is 131.188.40.189. Let me know about any issues. Cheers Sebastian signature.asc Description: Message signed with OpenPGP using GPGMail -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] http://localhost:631/
On 09 Sep 2014, at 09:36, Hartmut Haase hha4...@web.de wrote: why can't Tor Browser connect to that page? localhost is your own computer, and you can't open a connection to your own machine using a Tor client. Cheers Sebastian -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Changes for dirauth gabelmoo
Hey there, it's been almost 3 years since I started maintaining gabelmoo, and I'd like to give you an update. Soon, gabelmoo will get a new hosting environment along with a much-needed hardware upgrade. Along with a much better connection, I'll hope gabelmoo can serve the Tor network for quite some time yet. Unfortunately, this means an IP address change, which necessitates a new Tor version. Once we are ready to release one anyway and the migration has taken place, we'll get this going. As always, I'll be happy to provide information about the dirauth hosting as much as possible in case you have any questions. Cheers Sebastian signature.asc Description: Message signed with OpenPGP using GPGMail -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Dropping Tor Browser support for Mac OSX 10.6?
On 03 Sep 2014, at 17:08, Tor Talker tortal...@hidemeta.com wrote: [Short answer] As an individual user, I don't need Tor on Mac OS 10.6, but as a developer of a soon to be released Tor-dependent project I would like to see support continue. [Long answer] We are developing a system called HideMeta that relies on Tor and other proven security components to encrypt and anonymize communications. We are packaging the system as interpreted source code so there is no need to trust binary executables. Anyone can inspect the code they are actually running to verify it does what we claim. Therefore, we rely on Tor support for the operating systems on which we run. If the Tor project abandons OS X 10.6 (which a significant number of users are stuck with due to lack 64-bit processors or the need for features like Rosetta), we will either have to advise against using Hidemeta or installing an outdated Tor. In the face of pervasive, network-wide eavesdropping, our system gains strength with the number of active users. Our view is that even on an insecure OS, HideMeta users are still increasing their personal privacy, making pervasive surveillance less effective, and increasing the security of whistle blowers, journalists, dissidents, and others who legitimately need strong privacy and, hopefully, use hardened operating systems. For us, supporting a widely used OS like 10.6 is a good thing, even if it has been deprecated. I'll also note that we do not need the Tor Browser. Availability of a standalone Tor executable for OS X would be better for us. You can easily build a 32bit Tor executable. This is not about making Tor incompatible with OSX 10.6, only about not providing Tor Browser builds for it anymore. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [tor-consensus-health] Consensus issues
Hi Sebastian, thanks for looking after the network! On 16 Aug 2014, at 22:56, Sebastian G. bastik.tor wrote: On Sat, 16 Aug 2014 19:46:15 + (UTC) the doctor said: NOTICE: Consensus belonging to maatuska was missing the following authority signatures: tor26 NOTICE: Consensus belonging to tor26 was missing the following authority signatures: tor26 NOTICE: Consensus belonging to urras was missing the following authority signatures: tor26 NOTICE: Consensus belonging to dizum was missing the following authority signatures: tor26 NOTICE: Consensus belonging to gabelmoo was missing the following authority signatures: tor26 NOTICE: Consensus belonging to moria1 was missing the following authority signatures: tor26 NOTICE: Consensus belonging to dannenberg was missing the following authority signatures: tor26 NOTICE: Consensus belonging to Faravahar was missing the following authority signatures: tor26 If I understand this messages correctly tor26 didn't sign the consensus of any other authority. (Correct me if I'm wrong.) How is it possible that tor26 doesn't sign its own consensus? Here's an easy theory on what might have happened: When it was time to vote, tor26 made a vote, and distributed it to the other dirauths. When it was done doing so, it went offline. The other dirauths made a consensus, and signed it. tor26 came back online, learned that there was a consensus it didn't know about, fetched it from the other dirauths, but didn't sign it - because the time to sign it was in the past. This does not constitute an error condition for tor26, because enough other dirauths signed it for it to be considered valid. I'd argue against increasing the complexity of the voting process to handle this rare edge case. I do think maybe the wording is confusing: What does Consensus belonging to mean? A consensus doesn't belong to any individual dirauth. I don't have a quick suggestion for what to name the notice instead, tho. A similar message was send on the 15th for gabelmoo, but gabelmoo had no notice line. There were two warning, first gabelmoo did not publish a fresh consensus and secondly it did not report bandwidth scanner results. Nothing I would have worried about. Nor would I have found strange. Yes, gabelmoo was down as I was fixing its bw auth. Nothing to worry about indeed. However an authority handing out a consensus it didn't sign might be something that isn't quite right. I think it's OK, considering the above. Cheers Sebastian signature.asc Description: Message signed with OpenPGP using GPGMail -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] messing with XKeyScore
On 05 Jul 2014, at 15:08, Roman Mamedov r...@romanrm.net wrote: On Sat, 5 Jul 2014 03:59:28 + Matthew Finkel matthew.fin...@gmail.com wrote: This problem makes me sad on many levels, and I'm not opposed to implementing mitigation techniques (within reason) based on the rulesets, however we shouldn't do anything that will hurt our users nor should be do anything that makes tor more difficult to use (unfortunately this includes sending users bogus bridge addresses). Well, what is the format of a E-Mail response with a bridge list? If it's just plain text, why not instead send them as a picture in attachment, with bridge IP addresses encoded in CAPTCHA style to not be machine-readable. Because it makes it harder for humans to use, and doesn't help. Watching the bridge authority gives you a list of bridges, too - no need to read emails. There are no quick fixes to global surveillance, and we shouldn't forget our users when deploying questionable countermeasures. Cheers Sebastian signature.asc Description: Message signed with OpenPGP using GPGMail -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] The following directory authorities recommend other client versions than the consensus: gabelmoo
Hi, On 07 Feb 2014, at 08:05, tor-admin tor-ad...@torland.me wrote: This message was reported by the Doctor: NOTICE: The following directory authorities recommend other client versions than the consensus: gabelmoo +0.2.2.39 +0.2.4.15-rc +0.2.4.5-alpha +0.2.4.6- alpha +0.2.4.7-alpha +0.2.4.10-alpha +0.2.4.12-alpha +0.2.4.13-alpha +0.2.4.14-alpha +0.2.4.9-alpha +0.2.4.8-alpha +0.2.4.11-alpha +0.2.4.16-rc This means that for the reported period of time, the directory authority gabelmoo, which I maintain, recommended more versions for use than the other versioning directory authorities. This happened because the decision to change the recommended versions was made while I was asleep, and I've only fixed it for the upcoming consensus in a few minutes. So the message is harmless. Does it make sense to still recommend 0.2.4.X-alpha/rc client versions now that 0.2.4 is stable? Or am I misunderstanding the notice. The idea is to recommend all versions which aren't known to be bad, so that an operator who reads their Tor logs will realize their Tor really needs to be upgraded in order to remain secure/operational when theysee it. So, if an -rc version is fine to use, we can keep recommending it. Thanks for keeping an eye on our infrastructure! Sebastian -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Hidden Services
On Sep 17, 2012, at 12:19 AM, Scurvy Scott wrote: I'm sure this has been asked on here before but: Is it possible to basically brute force tor hidden services by simply visiting every possible .onion address and then indexing the ones that are active? Yes all 32^16 possibilities.. Is there possibly another way to do this? Perhaps by contacting the public key hash database mentioned at: https://www.torproject.org/docs/hidden-services.html.en for instance? I know for a fact that such an index would be completely unwanted but I'm talking theoretically. We'll see what types of responses we get. Pure brute force, that's 2^80 attempts. If you could try 1 trillion addresses per second, you'd be at it a little less than 40,000 years. I don't think brute force is the approach you should be looking for. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] tor-0.2.4.2-alpha compile errors
On Sep 14, 2012, at 9:34 AM, grarpamp wrote: Some easy ones... [snip] What compiler is that, and version? The code in main.c has been like this for a while, I wonder why it didn't come up before. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Python upgrade breaks 'random' in ARM..
On May 25, 2012, at 4:45 PM, Eric Seerden wrote: Hi Damian et al. I'm running Tor-0.2.3.15.alpha on FreeBSD 9.0, all fine.. However, I upgraded Python26 to version 2.6.8 (= up-to-date with port) it breaks ARM.. = File /usr/share/arm/starter.py line 18 in module import cli.controller = File /usr/share/arm/cli/controller.py line 11 in module import cli.menu.menu = File /usr/share/arm/cli/menu/menu.py line 10 in module import cli.menu.actions = File /usr/share/arm/cli/menu/actions.py line 8 in module import cli.wizzard = File /usr/share/arm/cli/wizzard.py line 9 in module import random = File /usr/local/lib/python2.6/random.py line 47 in module from os import urandom as _urandom = ImportError: cannot import name urandom Would you know a way around this because I'm not familiar with Python at all.. Any suggestions would be much appreciated.. Regards, E. PS. Running ARM from the executable comes down to the same problem.. Is virtualenv involved in any way? This is mentioned as a potential issue in the Python 2.6.8 release notes [0]. Maybe the freebsd maintainers for arm (or for python things in general) like virtualenvs? [0]: http://mail.python.org/pipermail/python-dev/2012-April/118676.html ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] building tor-0.2.3.15-alpha on Ubuntu
On May 20, 2012, at 9:32 AM, BigTor wrote: People, Because I guess there's a better way to build Tor from source on my Ubuntu 12.04 box than I do, I ask for some help. I want to build Tor from source with my build-from-source openssl 1.0.1c. My OpenSSL install is in /usr/local/ssl/ , there are the libcrypto.a and libssl.a files. I try to start building Tor with ./configure --enable-static-openssl --with-openssl-dir=/usr/local/ssl/ but whatever I do at the end, ending with slash or without, it results in the error message configure: error: You must specify an explicit --with-openssl-dir=x option when using --enable-static-openssl The only way I found to build Tor with my own install of openssl, is when I comment out lines 7178 till 7182 in the configure script and add the line TOR_OPENSSL_LIBS=/usr/local/ssl/libssl.a /usr/local/ssl/libcrypto.a After this, I check with `ldd ./src/or/tor` if there's libssl/libcrypto linked, and there's not, so correct. I build Tor this way from tor-0.2.3.12 - tor-0.2.3.15. There has to be a better way to building Tor from source, without editing the configure script, is there? Thanks! Tor's configure script is known to be broken when trying to link against static openssl ( https://trac.torproject.org/projects/tor/ticket/4692 ). The workaround is to make sure you don't only build static openssl libs, or - even better - you try out the patch in the ticket I linked to and give feedback on the bugtracker. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Absence of digital signature of TBB sources
On Apr 4, 2012, at 2:34 PM, and...@torproject.is wrote: On Wed, Apr 04, 2012 at 10:44:10AM +, rransom.8...@gmail.com wrote 0.7K bytes in 20 lines about: : The official TBBs are built from the sources in Git, not from the : tarballs. There probably shouldn't be any release tarballs for TBB : source code. But anyone should be able to build TBB from the source tarball. At least, this is how I used to build everything way back in the day when I built all of the packages. I didn't use the source repo. I tagged a release, built a source tarball, and then built the packages from the tarball. This way our builds were official, but at least others could build their own packages the same way we did. In theory the (signed, of course) tags in a git repo can fulfil the same purpose. That's probably the model we should aim for here. I'll poke Erinn again about the existing tarball's signatures, tho ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] About sources of TBB
On Mar 24, 2012, at 4:29 PM, James Brown wrote: On 24.03.2012 15:01, James Brown wrote: On 24.03.2012 14:57, James Brown wrote: I have got TBB-sources from here: https://www.torproject.org/projects/torbrowser-details.html.en#build But when I try to verify that, I have so strange result: ~$ gpg --verify tor-browser-2.2.35-8-src.tar.gz.asc tor-browser-2.2.35-8-src.tar.gz gpg: не найдено данных формата OpenPGP. gpg: Не могу проверить подпись. Файл подписи (.sig или .asc) должен быть первым указан в командной строке. And the next question, that as I can see there are TBB for Linux 2.2.35-9 in repos but 2.2.35-8 in sources, why? Sorry: LANG=C; gpg --verify tor-browser-2.2.35-8-src.tar.gz.asc tor-browser-2.2.35-8-src.tar.gz gpg: no valid OpenPGP data found. gpg: the signature could not be verified. Please remember that the signature file (.sig or .asc) should be the first file given on the command line. Probably attached file is not a signature: https://www.torproject.org/dist/torbrowser/tor-browser-2.2.35-8-src.tar.gz.asc Hrm, looks like you're quite right. I've cc'ed our build engineer here to check it out. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] EVIL bug Linux Tor Browser Bundle (2.2.35-8)
On Mar 19, 2012, at 7:11 PM, clarissabryant wrote: On Mon, 19 Mar 2012 14:51:17 -, m...@tormail.net wrote: Wow, Anonymous! Wow, what an amazing, bug. Drama. Clearly exposing your own browsing on your own file system on your own computer is a conspiracy of epic proportions. If the existence of vidalia debug log is a risk to your anonymity, you are already owned. Did you know tor, vidalia, and firefox talk over localhost? Google localhost and you will find a HUGE conspiracy affecting BILLIONS of computers. Billions of people are exposed to the localhost peer to peer network and infestation. The bug in TBB is quite severe, and it is against its stated goals and design principles (one of which is leaving no/as little traces as possible on disk for later forensics). This bug was severe, it was fixed quickly, and hopefully nobody was impacted too much. Time to move on. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] A paranoid question
On Mar 16, 2012, at 11:42 PM, Raynald wrote: Hi. How can I trust that the intermediate TOR computers are not really a central network for tracking and processing the communications? I see that the main sponsor is An anonymous North American NGO - New Global Order? :D - and, I don't know why but it reminds me what I heard once that one of the main investors of Facebook is the CIA (one of their thousand facades)... Cheers! Raynald. Well, one good way would be to run a fast relay yourself, have it join the network, and see if it gets advertised as a fast relay. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] tor debian repository for non x86 arch? (arm)
On Feb 21, 2012, at 1:07 AM, Damian Johnson wrote: Hi tagnaq, from what I was aware of it's in there... https://trac.torproject.org/projects/tor/ticket/3391 That said, I'm not quite sure where it's located. On Mon, Feb 20, 2012 at 3:13 PM, tagnaq tag...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I used to install packages from the torproject debian repos (https://www.torproject.org/docs/debian.html.en#development ) but apparently they do not include packages for arm. Is there a debian repo for arm somewhere? (containing tor 0.2.3.x packages for debian stable) thanks, tagnaq I suspect tagnaq meant arm, the architecture here - note how he asked for tor 0.2.3.x packages. Weasel doesn't have an arm machine to do the builds on, so we don't have those packages on deb.tpo. Sorry ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] bridge up down times
On Feb 12, 2012, at 11:38 PM, eliaz wrote: I have a few novice questions about a normal bridge I've set up. I've not found answers in the documentation. * Opposite the one country that's so far listed in the usage summary, the #Client column shows 1-8. What does this mean exactly? 1 client? eight? 1 client eight times? between 1 and 8 clients. We don't give more accurate statistics for safety reasons. * When I do have to shut down my machine or stop Tor I'd like to do it when no clients are using the bridge. The bandwidth graph spikes every few minutes, hard to predict from it when there might be no traffic. Is there an app from which over time I could get an idea of when it's least disruptive to stop Tor? Can't use Arm; I'm running on windows. I can log onto shell accounts via ssh in PuTTY/pageant, if that's any help. Thanks You can set the ShutdownWaitLength tor configuration option to something very high, like half an hour or so. That means Tor will continue servicing ongoing connections, but not accept new ones. Once there are no more ongoing connections or 30 minutes are up, Tor will exit. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Google as default search engine revisited
On Jan 10, 2012, at 5:26 PM, 5...@gmx.de wrote: I found a thread in the archive (November 2011), but I could not find a satisfying answer to the questions 1. Why is Google the default search engine in the TOR browser bundle? Because it's the default search engine in Firefox 2. Does TOR get money from Google a) for using Google as the default search engine? No. b) in general? Google sponsors the Google Summer of Code, and gives 500$ per student to the mentoring organizations, and also pays some amount of money for mentors to travel to the summit (only to cover transportation expenses). Tor has participated in the program in the past, and probably will again if accepted. In the past, I believe the work on Thandy was (partially?) sponsored by Google, but that there's no current contract. Andrew might be able to tell you more. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Automatic vulnerability scanning of Tor Network?
On Dec 27, 2011, at 7:03 AM, John Case wrote: On Thu, 22 Dec 2011, Lee wrote: While I totally get both sides of this argument *in theory*, all of this sounds a lot to me like getting pissed off about someone ringing your doorbell because they didn't mail you an opt-in form first. Nope. The probes were annoying, but the killer was my all-in-one consumer grade router/nat/dhcp server/firewall leaking packets into what was supposed to be the secure part of my home network. Ahhh, finally. This is the Godwins law of tor-talk - all threads eventually lead to some moron running a relay from their home Internet connection. To be fair, if we let the thread run long enough, I'll bet Mr. Do-Gooder-Port-Scanner is running from home, too. Comedy from all directions. I feel that your insults are entirely uncalled for here. Running a relay from a home connection is perfectly fine if there's enough spare bandwidth. There is absolutely nothing wrong with doing just that, and I am thankful to every operator who sets up a good node. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor - 1-click-compile-version
On Dec 24, 2011, at 12:21 AM, Chris wrote: [snip] The threat here potentially comes from governments mandating a back door. All Tor developers that have voiced their opinion on the matter of backdoors state that they would never put in a backdoor, and personally I would immediately quit the project if any evidence was produced that such a backdoor was implemented/is about to be implemented. The solution to this problem is to spread out the responsibility of checking for back doors amongst developers in different parts of the world and giving them the ability to issue secure signed hashes of the compile binaries. They would need to compile binaries themselves to create these signed secure hashes. This is not currently possible, because the builds are not deterministic [0]. So, nobody except the release engineer knows how the binary was built exactly. Tor has a vulnerability where there are only two or three bootstraping servers. They are spread out from my understanding although also a point of vulnerability. It requires 2 of three server currently I believe to compromise the service. If I recall correctly there is the possibility to have several trusted entities although there are only two or three right now. I'm sure someone more knowledgeable can provide better info. This is pretty plainly wrong. Tor uses a set of currently 8 directory authorities (I operate one of them, gabelmoo), and uses them to bootstrap. Blocking them all is easy, and prevents bootstrapping for Tor clients that aren't using bridges, but if a bridge is available they are not required for bootstrapping purposes. If a sufficient number of them are compromised, an adversary can do bad stuff like skew the popularity of a relay or prevent a relay from joining/add a relay that isn't really online, etc. Unless a majority of them are hijacked it is very hard to pull off those attacks unnoticed, tho. Sebastian ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] DNSl eakage
On Dec 6, 2011, at 9:16 AM, kamyar kamyar wrote: Hi, It seems that Expert Bundle is just a SocksProxy, i did configure my browser's port as 9050 and could surf the web, but what about DNS leakage issue ? after following article /tor/wiki/doc/Preventing_Tor_DNS_Leaks steps adding a line to about:config in FireFox, still DNSleakage exists, I use WinXP, any comments suggestions? Thank, Use the Tor browser bundle, the expert package is just for people who need to use non-standard configurations ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor no longer works with win2K ??
On Nov 14, 2011, at 3:45 AM, Jim wrote: Since I don't run Microsoft software I have not paid a great deal of attention to the downloads the Tor Project offers for it. So I went and took a look at your download pages to see what Anon Mus was talking about. I see that for the bundles, you indicate the Microsoft Windows versions are for Windows 7, Vista, and XP but for the Expert package (should it really be called a bundle?) you also list other versions of the OS. While I do not at all agree with the tone of some of his posts, I wonder if Anon Mus might not have a valid point about this. Perhaps on the Expert package for Windows a brief explanatory note should be added reflecting some of the discussion on this thread? Jim Hey Jim, your suggestion does indeed appear reasonable, and I had actually prepared such an addition to the download page when we learned that this bug is not windows 2000 specific at all. It can hit people who use all versions of Windows, but by far doesn't hit most of them. So it is in fact false that this is specifically a bug with support for win2k, and rather it's a general bug that we're hoping to solve. We've had some help from someone experiencing the issue, but details are still a bit in the dark. Hopefully we'll have a patch out soon. Sebastian ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor no longer works with win2K ??
I'll pretend you didn't insult me and the rest of the Tor dev team, and try and get your question answered. I've snipped the useless allegations. On Nov 12, 2011, at 12:52 PM, Anon Mus wrote: Jacob Appelbaum wrote: On 11/10/2011 02:39 AM, Anon Mus wrote: I got a message to upgrade my Tor version.. Nov 10 10:20:45.953 [Warning] Please upgrade! This version of Tor (0.2.1.30) is obsolete, according to the directory authorities. Recommended versions are: 0.2.1.31,0.2.2.34,0.2.3.6-alpha,0.2.3.7-alpha But (as before) the latest versions of the expert install do not work. Here's the stable.. Nov 10 10:17:10.093 [Notice] Tor v0.2.2.34 (git-c4eae752f0d157ce). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows 2000 Service Pack 4 [workstation]) Just as a general warning, I suspect the Random Number Generator on Windows 2000 is not so great. I would seriously consider installing a recent Operating system or booting a tails live CD. All the best, Jacob As I understand it the random number generator in win2k is the same as the one in WinNT, Win2003, WinXP and Windows Vista. http://www.theregister.co.uk/2007/11/13/windows_random_number_gen_flawed/ http://www.computerworld.com/s/article/9048438/Microsoft_confirms_that_XP_contains_random_number_generator_bug http://www.segobit.com/rng.htm Does this mean support for these Windows OSes is also to be withdrawn? Nobody said anything about withdrawing support because of this. Note that Jake spoke of suspicion. Recommending against the use of Operating Systems that have reached their end of life and no longer have security support is also just common sense, and it isn't surprising that WinNT or WinXP pre-SP have extremely bad security problems. Does this really surprise you at all? By just reading the articles you linked to above, you will see that MS claims the attack is fixed in the most recent version of Windows XP. You don't provide any kind of evidence that it is still a problem on those systems. Perhaps you can ensure a full explanation is placed a warning on the Torproject web site otherwise lots of users will be using Windows operating systems which are vulnerable. It's not entirely clear what the implications are, from what I understand. Obviously my questions are still NOT being answered, I QUOTE, Maybe that is because you demand a fully qualified answer within six hours, while you fail to provide a good bug report? Typically, bugs get reported to https://bugs.torproject.org, where the developers actually expect them. I re-iterate, can I get a reply from someone on the tor dev team about this ERROR and whether Win2k is being supported now or not? Here's the reply from someone on the tor dev team: Exciting! It seems you've found a bug on Windows 2000 systems, we should totally debug that and see if we can get it fixed! Unfortunately, we don't have a windows 2000 system around to debug this ourselves, and this is the only report we've gotten about trouble so far. Please try and provide more input about your system, the other software that you run, and if you have any experience debugging software so we may help you get this issue resolved. If we have to conclude that the expert Bundle doesn't work on Windows 2000 anymore for whatever reason, I'm afraid we'll have to drop support for it unless someone else steps in to provide the necessary fixes. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] New operator for gabelmoo (one of Tor's directory authorities)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi tor-talk, As of today I'm the new operator of the directory authority gabelmoo. Karsten Loesing, who has been operating it since early 2008, decided to focus more on software development and less on the sysadmin overhead that running a directory authority implies. He handed over all the necessary keys to me, and his access to the gabelmoo host has been suspended. Directory authorities are special Tor relays which are responsible for generating a list of the currently running relays in the network once an hour. There are currently 8 directory authorities, operated by Tor developers and other individuals trusted by the Tor Project. To get a quick idea of what they are doing, check out the network status health page[0]. If you have any questions concerning the role of a directory authority in the Tor network or the operation of gabelmoo, please do not hesitate to ask. All the best Sebastian [0]: https://metrics.torproject.org/consensus-health.html (roughly 3MB) -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJOrckuAAoJEKlsb90UDJYbZgcH/1Cv1jVg6sMvQIL2q20o5MW2 +jDgH2BGFv/L1Hk327DXeY4ph2luMkh6YVbKAh4emXQBp4HPBK4xklBma4zTKohx iI7xcoB5MfSyUgJIglKo/CxelVhqMfMb+F6obT48rBaztvjvfTGMw8knageKh0pn nDXmrehlGRdO4fS5yltr1FQQLIG4i+1LXPixlujtFs0XrSHq3Z+AlA2Z/vYA8vkF GmSrmhsHyvweXQ3GH8rS726Fp5uE8ZiNgQsVyeRoXXWLYkGt7yu7hIWFMVvTevwI /gzKiiFK8TiDryCNlxh20Klxhuasb4SdIe4o48Q5wlRvmyUmcTdXdROijBMiJz4= =g2Qe -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Suggestion: make _hidden services_ choose random entry nodes often!
On Oct 21, 2011, at 2:27 PM, hi...@safe-mail.net wrote: All standard clients have the same entry nodes on a permanent basis or as long as the entry nodes are up, while the middle and exit nodes changes all the time. This is to reduce the chance of choosing an accidental path that is end-to-end supervised when browsing the WWW. With hidden services, this isn't needed, since these are end-to-end encrypted connections. The same goes for those who visit hidden services. And randomness is what hidden services need to stay safe. Because it's generally easy to distinguish clients from servers from the way data is transferred, and check if an IP is in the official Tor nodes list or not, it should be pretty easy to find hidden service clients by using a cluster of bad entry nodes to supervise IP addresses and traffic. With a large enough cluster, like 100-200 bad entry nodes, all new hidden services will have a 5-10% x3 chance to select a permanent bad entry node. Old hidden services may already have chosen a bad one, or will have the same 5-10% chance for each new entry node they select if their regular nodes go down. It's just a matter of analyzing timings and traffic, and the hidden service's IP could be found. This only regards listed hidden services, but I guess most are. Since hidden services don't need to stick to the same entry nodes, the Tor developers should really consider making the Tor client randomly choose entry nodes, just as with middle and exits, for hidden service usage. It should be easy to add and it will increase the security of hidden services greatly by adding lots of randomness. Unfortunately, you got it all wrong. There's a trivial attack against any hidden service that doesn't use entry guards: Make a lot of connections to it, while running at least one relay. Then do some timing analysis to see when your connection to the hidden service coincides with a connection to the node that you control, and write down the IP address of the person making the connection, and you have de-anonymized the hidden service. If you have 200 bad entry nodes under your control, that attack will work very quickly and reliably, whereas there's still a good chance that you need to keep those nodes running for a few months for the hidden service to pick one of those nodes as guard. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] since today check.torproject.org states you are not using tor
On Oct 15, 2011, at 11:27 PM, and...@torproject.org wrote: On Sat, Oct 15, 2011 at 04:39:25PM -0400, and...@torproject.org wrote 0.9K bytes in 21 lines about: : For some reason, the exit list doesn't see checktpo as a valid exit. If : I can't figure it out in an hour, I'll just disable the exit enclave. It seems the tordnsel process that confirms exits is going to take a few hours to catch up. In the meanwhile, I've disabled exits to check.torproject.org from the checktpo tor relay. This has stopped the false negatoives from appearing on check.torproject.org. Fun times. I suspect what's going on here is that checks sees the connections are coming from localhost, and hasn't whitelisted those as tor connections. Either that, or dnsel doesn't trust the relay's exit policy when it can't confirm for itself. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle: PGP encryption built-in?
On Oct 10, 2011, at 2:48 PM, Joe Btfsplk wrote: On 10/10/2011 2:44 AM, Robert Ransom wrote: No. See https://tails.boum.org/bugs/FireGPG_may_be_unsafe/ , but beware -- I'm sure katmagic and I missed a few dozen attacks. You're correct - that is, the https site you link has an unsafe certificate, * per msg * in Firefox 7: tails.boum.org uses an invalid security certificate. The certificate is not trusted because the issuer certificate is not trusted. (Error code: sec_error_untrusted_issuer) Anyone else seeing same security msg? Yes, the tails developers decided not to pay the SSL mafia and got a certificate from cacert instead. Your browser probably isn't configured to trust cacert, so you get the warning. Alternatively, someone is really trying to mitm you - tough to know. Anyway, the sha1 fingerprint of the tails website should be E1 5D 87 49 7F A1 21 75 8B 6B 1A 85 DC EF 70 E1 C6 7C 82 57. Now good luck deciding whether you should trust my claim in this unsigned email, or what. Enjoy the trip through the rabbit hole. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Possible Attack on Tor speed?
On Aug 24, 2011, at 10:54 AM, morphium wrote: Hi, I just had an idea, how an attacker could slow down the Tor network, and wanted it to discuss with you. To my knowledge, there is only the BadExit and BadDirectory flag, nothing like BadNode. In contrast to a bad exit, which is misbehaving, how could the network block a node, which has all outgoing traffic blocked? Lets say, I set up some (few hundred or so) Nodes, which I start up and then block outgoing traffic on them. If they're chosen as middle node for a circuit, the circuit can't build, because the next server cannot be reached. If my servers advertise a high bandwidth (is there any detection for false bandwidth advertisings?), Tor will often try to put them in a circuit, and often will fail. This could lead to no usable circuit for several minutes. Let me know what you think! Thanks :) Dirauths can add nodes to their configuration to not add to the directory at all. See AuthDirReject in tor's manpage. The other answer is that the bw auths will never manage to test bandwidth succesfully. All the best Sebastian ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor 0.2.2.30-rc is out
On Jul 10, 2011, at 11:04 PM, David H. Lipman wrote: I get confused where to download. I only found Win32 unstable 0.2.2.29 :-( From: Roger Dingledine a...@mit.edu Packages will appear on the download page in the coming days. Be patient :) ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] ReachableAddresses *:* harmful?
On Jun 3, 2011, at 6:52 AM, Fernan Bolando wrote: Thanks, Actually openbsd seems to defaults this to ReachableAddresses *:80,*:443 Did you (or does openbsd) set the FascistFirewall option by chance? How did you learn that openbsd defaults to ReachableAddresses *:80,*:443? Thanks Sebastian ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor 0.2.3.1-alpha is out!
On May 6, 2011, at 2:30 AM, Jim wrote: Nick Mathewson wrote: Changes in version 0.2.3.1-alpha - 2011-05-05 Tor 0.2.3.1-alpha adds some new experimental features, including ... automatic home router configuration. Are you saying the Tor software itself (as opposed to Vidalia or some such) attempts to configure routers it discovers? W/o prompting? Is that a good idea? If I am understanding correctly that sounds like that could cause problems and quite possibly get users of the software upset after they get a nasty surprise. Am I correct that disabling UPnP on the router is sufficient to defeat this? Jim Tor now has a build-time option to optionally include a helper script that has upnp and/or nat-pmp functionality. This helper script further needs to be enabled by setting a Tor configuration option (PortForwarding) to enable the feature at runtime. When that option is set on a build that supports it, and the router supports and is configured to allow upnp configuration, only then will automatic port forwarding be attempted. It is my general recommendation to always disable upnp everywhere, but that's beside the point here. Sebastian ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] seeking someone to fix a Tor rpm bug
On Mar 10, 2011, at 12:38 PM, Erinn Clark wrote: Hey Marco! * Marco Bonetti si...@slackware.it [2011:03:10 12:10 +0100]: Primarily I am worried about the upgrade scenario and changing groups in a way that doesn't break previous versions of the packages. Could you elaborate a bit on the issues? So far my understanding is that --with-tor-group should not be called anymore during configure, so a patch would be to just remove --with-tor-group=%{torgroup} from the rpm spec %configure line :-P Yes, you could just remove that. But do you need to change the group for all of the people who already have a _tor group created upon upgrade? Should you delete the group from existing systems altogether? Is it as simple as just removing all of the other torgroup mentions from the .spec (and there are quite a lot of them)? Does it do the right thing when it gets installed for a new user as well? I suspect for a new user it's fine. It's the transition part I don't know about (and realistically don't have enough time for to make sure I do a very good job with, which is why I'd prefer to ask someone who knows more about it than I do). Afaict the _tor group should still exist, and be the primary group for the _tor user. The only thing happening here is that the configuration option for tor to choose a specific group was removed. This is analogous to what Debian does during install time. Sebastian ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk