Re: [ANNOUNCE] Incognito "tiny" Live CD update, now <50MB
On Friday 01 June 2007, Roger Dingledine wrote: > Thanks for sticking with this. I'll give you a quick suggestion that > you may not find useful quite yet but it'll sure come in handy soon: > how about putting a version number (or a few numbers) on it? :) I actually added the subversion revision to the CD title in this release :) It shows up in a few other places as well, such as the documentation on the CD. I suppose a real versioning scheme might be in order, in the SVN tags I use the date I took the Gentoo package snapshot, plus a -rX suffix, such as: 20070413-r1 20070413-r2 20070413-r3 I may use that instead of the SVN revision, comments are welcome. I like using svnversion because the script that generates the CD puts it in there, so I can be forgetful without side effects :) -- Pat Double, [EMAIL PROTECTED] "Ye must be born again." - John 3:7 signature.asc Description: This is a digitally signed message part.
Re: [ANNOUNCE] Incognito "tiny" Live CD update, now <50MB
On Fri, Jun 01, 2007 at 12:05:42AM -0500, Pat Double wrote: > I have released a new Incognito "tiny" Live CD. The major change is that it [snip] > http://fwks5nwum4hpjnin.onion/incognitotiny-i686.iso.torrent > http://www.patdouble.com/incognitotiny-i686.iso.torrent Hi Pat, Thanks for sticking with this. I'll give you a quick suggestion that you may not find useful quite yet but it'll sure come in handy soon: how about putting a version number (or a few numbers) on it? :) Thanks! --Roger
[ANNOUNCE] Incognito "tiny" Live CD update, now <50MB
I have released a new Incognito "tiny" Live CD. The major change is that it will now fit on a "business card" CD which holds 50MB. Note that this is Tor, Privoxy, Firefox and now ChatZilla on a CD you can carry in your wallet. Other changes: - Clean up squid conf, bind UDP listener to only localhost, disable core dumps. - Add ChatZilla, IRC client extension for Firefox. - Fix fluxbox menu so the "fluxbox" menu appears again. Links to the torrent are: http://fwks5nwum4hpjnin.onion/incognitotiny-i686.iso.torrent http://www.patdouble.com/incognitotiny-i686.iso.torrent Enjoy! -- Pat Double, [EMAIL PROTECTED] "Ye must be born again." - John 3:7 signature.asc Description: This is a digitally signed message part.
question about A/B communication with dir servers for hidden services
Hi, i have read in the rend-spec.txt: Bob's OP opens a stream to each directory server's directory port via Tor. (He may re-use old circuits for this.) Over this stream, Bob's OP makes an HTTP POST' request, to a URL "/tor/rendezvous/publish" relative to the directory server's root, containing as its body Bob's service descriptor. Alice opens a stream to a directory server via Tor, and makes an HTTP GET request for the document '/tor/rendezvous/' (...) (She may re-use old circuits for this.) and have one question for understanding: Are the "streams" from Bob and Alice to put & get the descriptor of a hidden service always established over Tor circuits or sometimes direct streams from the OP's to the Tor directory server? In other words: Is it assured, that the directory server doesn't know, that "Bob" has established a hidden service and "Alice" has asked about it? -- Ciao Kai Homepage: http://hp.kairaven.de/ Weblog: http://blog.kairaven.de/
Re: All authorities have failed. Not trying any.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Though I have no idea about the __AllDir... stuff, I can give you a first hint to solve it: > [Info] update_networkstatus_client_downloads(): Our most recent > network-status document (from nobody) is 1180650256 seconds old; > > and where is that age coming from? that amounts to >37 years 1970-01-01 00:00 + 37+ years = today Now the rest is up to you. ;) - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGX1CE0M+WPffBEmURAq9bAKCTiyHDKkJttAuFKbLNtqRsa28aHACeNU4F JU9fxyZBJq1zWtjArWY3WQ0= =G1vB -END PGP SIGNATURE-
Re: All authorities have failed. Not trying any.
On Thu, May 31, 2007 at 03:32:37PM -0700, scar wrote: > while Tor is still able to build circuits, it doesn't seem to be >able to download updated lists of routers. then, after several days, >there is no way for Tor to build circuits. is this related to the >__AllDirActionsPrivate setting? related to the activity of the system >(that is, that it gets put into standby and has intermittent internet >access)? We told you that setting __AllDirActionsPrivate would do that if you don't provide some external mechanism for inserting descriptors yourself. You're welcome to try setting it anyway, but if it breaks, you get to keep both pieces. :) If you figure out what the issue is and have a patch, great. Otherwise, I'll just continue saying that it's not recommended. Good luck, --Roger
All authorities have failed. Not trying any.
i am getting this message on the same system which uses the __AllDirActionsPrivate, that is, WinXP now running the 0.1.2.14 version of Tor. it shows every minute: [Info] update_networkstatus_client_downloads(): Our most recent network-status document (from nobody) is 1180650256 seconds old; downloading another. [Info] update_networkstatus_client_downloads(): All authorities have failed. Not trying any. the system gets put into standby frequently, but gets access to the internet every <24 hours. and where is that age coming from? that amounts to >37 years while Tor is still able to build circuits, it doesn't seem to be able to download updated lists of routers. then, after several days, there is no way for Tor to build circuits. is this related to the __AllDirActionsPrivate setting? related to the activity of the system (that is, that it gets put into standby and has intermittent internet access)? signature.asc Description: OpenPGP digital signature
Plan: dropping support for v1 directory protocol.
[Hi, folks. This message also went to or-dev, but I think there are some tool maintainers who aren't on that list.] Hi, all! As you probably know, Tor has had a few different directory protocols in its lifetime. The oldest one (the "v1 protocol") was pretty bad: it took up a lot of bandwidth, and it made every authority into a single point of failure. The more recent protocol (the "v2 protocol") has been fully supported since 0.1.1.8-alpha. Unfortunately, there are still some tools that use v1 directories, and there are still some clients (and even a few servers!) running 0.1.0.x. This is bad for a number of reasons: The 0.1.0.x series has not been supported for a while. Tor 0.1.1.x has been stable for more than a year now, and it has a lot of important security features that are not supported in 0.1.0.x. (These are features, not bugfixes, and they can't be backported without basically replacing 0.1.0.x with 0.1.1.x.) IMO, we are _not_ doing people a favor by keeping support for 0.1.0.x: it is insecure, buggy, and old. Thus, in a few months (say, on 1 August or 1 September), I propose that we drop support for v1 directories. The authorities, instead of generating full v1 directories, will serve empty directories instead, so that caches will not propagate stale information. This will make 0.1.0.x clients download empty directories, and fail to build circuits until their users upgrade to 0.1.1.x. At the same time, there's another transition to make in directory information: Check out proposal 104. We're going to move the fields "read-history" and "write-history" (which currently are only used by some tools, and are not used by Tor iteself) into a separate "extra-info" document that not everybody downloads. This will cut down on directory bandwidth, _a lot_, since those fields are very expensive. If you are maintaining a tool that uses v1 directories or the *-history fields, you'll need to switch to use v2 directories and extra-info documents. I'll try to ease the transition as much as I can, possibly by writing a script to cobble the contents of a Tor's cache into some semblance of a v1 directory. I'm not proposing this lightly; I really hate dropping support for old versions. Nevertheless, I think we need to do this soon: to limit the bandwidth demands on directory servers; to continue to improve the network's security; to avoid bloating our code with backward compatibility hacks indefinitely; and to ensure that users running ancient insecure software don't get hurt by it. Please let me know if for some reason August 1 is too late for you; if you've got compelling reasons, I'll push the date back to September 1. Please also let me know if I'm being totally insane here. :) yrs, -- Nick Mathewson pgp7k289bjfaN.pgp Description: PGP signature
Re: Bandwith donation for some days ?
Roger Dingledine <[EMAIL PROTECTED]> wrote: > > There will be the chaos-communication-camp in August in Germany > > (http://events.ccc.de/camp/2007/intro) with a 10G uplink. [..] > One last note -- are they all going to be using IP addresses from the > same /16 network, or will the IP addresses be more diverse than that? The IPv4 Space will be something like that, correct. It can be compared to the Congress, although the Bandwdith cannot be that large due to the location (outskirts of Berlin) and the wireless internet uplink. # thal
Re: Fetching only Exit nodes
On Thu, May 31, 2007 at 09:15:18AM -0700, Mr. Blue wrote: > I am using tor 1.1.26 You might want to stop that; 0.1.2.x has a lot of security improvements. > So..., > Whenever my script detects change of MD5 value of > cached-routers, > it clears DB and by using regular expesion it fill DB > with nodes. > > Now..., > I decided I wana have only exit nodes in DB and not > all of them. > > After looking at one already made script I saw that it > connects to Tors control port and uses: > "GETINFO ns/all \r\n"; > for geting that kind of info(and many more). > > Problem is because tor 1.1.26 doesn't have it. > I've tried with "GETINFO network-status \r\n", but > nada! > ... and ALL othe possible values to Tor. Right. 0.1.1.x is old though getinfo network-status *does* work for me there. It doesn't use the same format, though, and it can't tell you what is an exit node. You _could_ arrange for a long-running script to be notified of all new descriptors as they arrive by using SETEVENTS to listen for NEWDESC events, but I'm not sure that's what you want. > > Now because this script isn't of use to me I guess, I am on my own. > > I will continue to get that data from cached-routers > file. > Now > > reject 0.0.0.0/8:* > reject 169.254.0.0/16:* > reject 127.0.0.0/8:* > reject 192.168.0.0/16:* > reject 10.0.0.0/8:* > reject 172.16.0.0/12:* > accept *:80 > accept *:443 > reject *:* > > is absolutely same like: > > reject *:* > > Is that correct? No. The former rejects all addresses in private networks; accepts port 80, and port 443; and rejects everything else. The latter just rejects everything. HTH, -- Nick Mathewson pgpZjdEqvfOHV.pgp Description: PGP signature
Fetching only Exit nodes
I am using tor 1.1.26 So..., Whenever my script detects change of MD5 value of cached-routers, it clears DB and by using regular expesion it fill DB with nodes. Now..., I decided I wana have only exit nodes in DB. After looking at one already made script I saw that it connects to Tors control port and uses: "GETINFO ns/all \r\n"; for geting that kind of info(and many more). Problem is because tor 1.1.26 doesn't have it. I've tried with "GETINFO network-status \r\n", but nada! ... and ALL othe possible values to Tor. Now because this script isn't of use to me I guess, I am on my own. I will continue to get even that data from cached-routers file. Now reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* accept *:80 accept *:443 reject *:* is absolutely same like: reject *:* Is that correct? - Pinpoint customers who are looking for what you sell.
Fetching only Exit nodes
I am using tor 1.1.26 So..., Whenever my script detects change of MD5 value of cached-routers, it clears DB and by using regular expesion it fill DB with nodes. Now..., I decided I wana have only exit nodes in DB and not all of them. After looking at one already made script I saw that it connects to Tors control port and uses: "GETINFO ns/all \r\n"; for geting that kind of info(and many more). Problem is because tor 1.1.26 doesn't have it. I've tried with "GETINFO network-status \r\n", but nada! ... and ALL othe possible values to Tor. Now because this script isn't of use to me I guess, I am on my own. I will continue to get that data from cached-routers file. Now reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* accept *:80 accept *:443 reject *:* is absolutely same like: reject *:* Is that correct? Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
