- tor-dev - lists.torproject.org

Future Onion Addresses and Human Factors
by Alec Muffett 14 Aug '15

14 Aug '15

Hi All, Having Beer with Donncha, Yan and others in Berlin a few days ago, discussion moved to Onion-Address Human Factors. Summary points: 1) it’s all very well to go an mine something like “facebookcorewwwi” as an onion address, but 16 characters probably already exceeds human ability for easy string comparison. 2) example of the above: there are already “in the field” a bunch of onion addresses “passing themselves off” as other onion addresses by means of common prefixes. 3) next generation onion addresses will only make this worse 4) from Proposal 244, the next generation addresses will probably be about this long: a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion 5) taking a cue from World War Two cryptography, breaking this into banks of five characters which provide the eyeball a point upon which to rest, might help: a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sd.onion 6) using underscores would be a pain (tendency to have to use SHIFT to type) 7) using dots would pollute subdomains, and colons would cause parser confusion with port numbers in URIs 8) being inconsistent (meaning: “we extract the second label and expunge anything which is not a base32 character”, ie: that with-hyphens and without-hyphens) may help or hinder, we’re not really sure; it would permit mining addresses like: agdjd-recognisable-word-kjhsdhkjdshhlsdblahblah.onion # illustration purposes only …which *looks* great, but might encourage people to skimp on comparing [large chunks of] the whole thing and thereby enable point (2) style passing-off. 9) appending a credit-card-like “you typed this properly” extra few characters checksum over the length might be helpful (10..15 bits?) - ideally this might help round-up the count of characters to a full field, eg: XXX in this? a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion 10) it might be good to discuss this now, rather than later? Hence this email, in the hope of kicking off a discussion between people who care about human factors. :-) - alec — Alec Muffett Security Infrastructure Facebook Engineering London

11 27

tor's definition of 'median'
by nusenu 14 Aug '15

14 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2028 > If 3 or more authorities provide a Measured= keyword for a router, > the authorities produce a consensus containing a "w" Bandwidth= > keyword equal to the median of the Measured= votes. a random sample from recent votes: grep 37.59.38.117 -A 3 *|grep Measured w Bandwidth=6869 Measured=7570 w Bandwidth=6869 Measured=15500 w Bandwidth=6869 Measured=18100 w Bandwidth=6869 Measured=30500 Tor says the median value is 15500 2015-08-10-16-00-00-consensus: w Bandwidth=15500 but the median of these 4 values is actually: (18100+15500)/2 = 16800 no? Has tor a different definition of 'median' and simply takes always the second ordered measurement vote out of 4 votes or is there a bug in the spec or implementation? -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVyNtYAAoJEFv7XvVCELh0YU8P/0hWhCLfafvFDPdAfUwUJFPA A1ZA946JGKg1Vjy+ch3tffjDHRosXt7K5U33N9rKMUlW9ul2BQ+uNgzK4eTbghHz yCMn6D+uLk1xruYTsIUZ+Pk/ZywaUKj/FngohVvQnaJIgJCHCEnCIqqBNEK0PjUh EBzI5GdyWpEA2fh55PSRuSNCVzbiVhGwYSKgrVwFrFcKr9iPLmdZsa9SD1mb1PD1 IZOkU6TnSnFGbPaN+pHYdNr5/QJA1/08yYBpG7qAJaTCAMvMif7bKMJ7ElYo7opc oXcECIcBBPnATgKvbO47dbSnX3s+vPMsrRhhdTa1BMr1MIzVG3RWGhNSJwXXQTJh jyaPGj10JRWNxDsY0ro001MX0HymmXeLLCkY4nWsUqPXDiZcQe4oRzLQas5bOI94 ct4tCavj9pRNp2XYCWe631gqcsQ3xV7y37dWUCvpdXqt2NC1B7j2w/Y/UiuNArSj QBtS4Ap5wqnU5JySjndi+lIPOlaPk9uitmzpKLxNF9fnpI6ZECP3T50vHVeZiiQ9 7o1ZyBsPLk3bi2hRy8ZJ0wyO+5WF8bdrlsKXSR40UjrwQZ5kCQf6xmWiSg9PqZFU rIL14yCOsQkR3P4/IgMlL8dtgFk3Asmkkx039144fRKveEhffFjo54CUMhg/jLra EF5cUqz4QdgcpRvKa/5h =lA/6 -----END PGP SIGNATURE-----

8 12

Re: [tor-dev] [Twisted-Python] please can haz code review -> Tor-ified Twisted Python HTTP proxy server - txtorhttpproxy
by David Stainton 13 Aug '15

13 Aug '15

Dear Aaon Gallagher, Thanks for the helpful observation. i'm going to make the correction soon and then we'll be underscore free. On Wed, Aug 12, 2015 at 7:06 AM, Aaron Gallagher <_(a)habnab.it> wrote: > David Stainton <dstainton415(a)gmail.com> writes: > >> If I get rid of this last terrible import: >> from twisted.web._newclient import ResponseDone >> >> then I'm not sure how to detect when to call the finish() method here: >> https://github.com/david415/txtorhttpproxy/blob/master/txtorhttpproxy/proxy… > > Fortunately, ResponseDone is re-exported by twisted.web.client: > > >>> import twisted.web.client > >>> twisted.web.client.ResponseDone is twisted.web._newclient.ResponseDone > True > >>> twisted.__version__ > '11.0.0' > > I couldn't get 9.0 to compile in the five seconds I tried, but 11.0 is > still pretty old. I think it always was re-exported like this.

1 0

[important] sponsors deliverables discussion point for Wed's meeting
by Isabela 13 Aug '15

13 Aug '15

Hello Core Tor folks! Note: if you are not a contractor or full time you can ignore this email, it is about paid deliverables. Me and Nick have been working on documenting the current status of our deliverables for the year to Sponsor S [project year ends on October] and Sponsor U [project year ends on November]. The result gave us a clear picture of where we need your help with. Please take a look at: https://docs.google.com/spreadsheets/d/1dTva10mu-FcX8KrxRjgkFvHSyNy7aBpD9xe… For Wednesday we want to figure out how can people jump in and help on these tasks. Right now we have a lot assigned to Nick and is a big red flag that we won't make it. Not to mention that Nick also has to carry on other work and to do both is just impossible. Please take a look, ask questions and lets figure out how we can conclude all this tasks. Priorities are: * Rows 5 & 6 * And any help on the other tasks that are all about writing docs (rows 12, 13, 15, 16, 17) * Or maybe help out with the final push for Sponsor S tasks We will be adding the related tickets (column H) later today so you can take a look before the meeting on Wednesday. thanks! isabela -- PM at TorProject.org gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1 B298 3224 4994 1506 4C7B @isa

1 1

[Measurement Team] Next IRC meeting happens on Wednesday, Aug 12, 14:00 UTC in #tor-project
by Karsten Loesing 12 Aug '15

12 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team on Wednesday, August 12, 2015, 14:00 UTC in #tor-project https://www.timeanddate.com/worldclock/fixedtime.html?iso=20150812T14 Suggested agenda is: - 1-1-1 task exchange: you get 1 minute to describe a task that would take somebody else roughly 1 hour and that they will do for you within 1 week (review a document, write some analysis code, fix a small bug, etc.; better come prepared to get the most out of this; give 1, take 1) - Priorities: should we focus more on a certain aspect of measurements in the Tor network, while temporarily suspending or even permanently dropping other aspects? Let's talk about how we can add such priorities to the roadmap draft we have been working on [0]. - Misc/discussion: whatever comes up during the meeting If you think this can be fun, please join us at the meeting! Talk to you tomorrow! All the best, Karsten [0] https://people.torproject.org/~karsten/volatile/measurement-roadmap.pdf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVyhwAAAoJEJD5dJfVqbCrjkMIAMCUpfVBIw2GWaPLMgW9MSFo 1ANENAwisD86f2r+ypRtBtK28TDN4d3cauACkqY8zLHs4ZzghO0f58Ob9ZhGgHei jkOM2i/M/yBEZehAit2kYoeND8gfWdW2vj5HufFF2khw+xFsL1+oQgVyurfdMQ3/ TfI1iWBuv5NSTQx4h/W64DJ9vagwYiLNvPrI2TbO2hhOiEKS1nIMZ3vYjI2V3Yff 0rjGsTd3WMm2AIarbJtVoeFW2jgqeweSFR5M+aAYdsRRKH/nRdcl6ToVPro+8uih I3GRCFJpEIh1CHJSGvfLuazJ88W1INYf/LQiOkEAx8CiSshBHar+0JpWOMpsrfc= =ZC0R -----END PGP SIGNATURE-----

1 0

Tor's default behavior for ed25519 identities
by s7r 12 Aug '15

12 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Tor 0.2.7.x will support Ed25519 router identities along with the traditional 1024-bit RSA ones which will be used simultaneously for some time, until we will completely deprecate RSA router identities. I would like to document what Tor needs to do (or don't do) by default in some cases to prevent mistakes which confused operators could do. Please review and add/edit/remove if something is wrong, doesn't make sense or is incomplete. When finished, I will split it in more parts and open tickets on trac based on priorities. Some cases are already covered (Tor does what it should by default). We also need to compose the messages Tor will print in the log files in a way that they will be of a reasonable length and expressive/explicit/polite/whatever. Take in consideration the design: For an Ed25519 identity, Tor will generate these files in $datadirectory/keys: - - ed25519_master_id_secret_key - the master identity key. Optionally this can be kept offline or encrypted. This is the file one needs in case he wants to restore a relay. Never expires. Sensitive (if reached it will compromise the identity of the relay forever). - - ed25519_master_id_public_key - the public key. This is the actual router identity which Tor publishes in the descriptors. It is computed from the secret key and it is not sensitive. Never expires. - - ed25519_signing_secret_key - a temporary signing key. This will be used for circuits (onionskin) encryption. It is valid only temporary for as long as ed25519_signing_cert says so. - - ed25519_signing_cert - a cert signed by the master ID key (ed25519_master_id_secret_key) attesting that the ed25519_signing_secret_key 'x' is valid for 'n' days/months. The validity period can be configured with the torrc option SigningKeyLifetime 'n' days/weeks/months (default is 30 days). Also take in consideration that the directory authorities will pin relays with paired RSA-Ed25519 identities and reject them if one changes. For example, if relay A has ID RSA_A & Ed25519_A, and later changes to RSA_B & Ed25519_A or RSA_A & Ed25519_B, it will be rejected. The text is also available on Etherpad: https://etherpad.mozilla.org/efIBq6nDwt - ------------------------------------------------------ Ed25519 router identity - default behavior - ------------------------------------------------------ We don't touch the RSA ID key behavior. We let it as it was, use it if secret ID file is there, generate new one if not. The behavior below should be implemented by taking in consideration only the ed25519_* files in $datadirectory/keys (should not care or notice the RSA related files). We don't say anything about offline Ed25519 ID keys or encrypted Ed25519 ID keys. Whoever wants to use these features will have to read the FAQ first and understand some things. The default is: generate ed25519_master_id_secret_key (unencrypted) in $datadirectory/keys and use that forever, by automatically renewing ed25519_signing_secret_key and ed25519_signing_cert with the default validity period of 30 days, unless otherwise specified in torrc. This is already implemented and it is how Tor works now. At every start, restart, reload, server reboot, signal sent by user or another app, etc. Tor should: 1) check if file ed25519_master_id_secret_key exists in $datadirectory/keys and it's a valid curve25519 private key file; 2) check if file ed25519_master_id_secret_key_encrypted exists in $datadirectory/keys; 3) check if file ed25519_master_id_public_key exists in $datadirectory/keys and it's a valid curve25519 public key file; 4) check if file ed25519_signing_cert exists in $datadirectory/keys; 5) check if ed25519_signing_cert in $datadirectory/keys is expired; 6) check if ed25519_signing_cert correlates with ed25519_master_id_public_key; 7) check if file ed25519_signing_secret_key exists in $datadirectory/keys; 8) check if ed25519_signing_secret_key correlates with ed25519_signing_cert (non-expired cert refers to that signing key); 1. If ed25519_master_id_secret_key && ed25519_master_id_public_key && ed25519_signing_secret_key && ed25519_signing_cert are all missing from $datadirectory/keys: - -> We assume it's a new relay or a relay which just upgraded to a Tor that supports Ed25519 router identities. Generate a new Ed25519 identity unencrypted (ed25519_master_id_secret_key, ed25519_master_id_public_key, ed25519_signing_secret_key and ed25519_signing_cert with a validity for 30 days unless specified otherwise in torrc) and publish a descriptor using that, proceed as normal after. 2. If ed25519_master_id_secret_key is missing or exists encrypted && ed25519_master_id_public_key exists in $datadirectory/keys and ed25519_signing_secret_key and ed25519_signing_cert are expired: - -> We assume this can happen suddenly, while running unattended. Disable relay functionality and stop publishing descriptors (close ORPort and (if open) DirPort). Leave client functionality since that could be used by something else on that machine and it shouldn't be affected. Print warnings in the log file that action is required (generate new ed25519_signing_secret_key and ed25519_signing_cert or move the ed25519_master_id_secret_key unencrypted in $datadirectory/keys so Tor can do this by itself). The operator needs to signal Tor with a reload signal (HUP) or restart/stop & start after completing the action. Tor will check for the valid ed25519_signing_secret_key and ed25519_signing_cert by itself every time server restarts (along with Tor process) or at every automated reload signal (HUP). 3. If ed25519_master_id_secret_key exists unencrypted in $datadirectory/keys and there is no ed25519_master_id_public_key, ed25519_signing_secret_key or ed25519_signing_cert (or ed25519_signing_secret_key and ed25519_signing_cert are expired): - -> We assume the relay has just been restored and the Ed25519 identity was backed up. Automatically generate ed25519_master_id_public_key, ed25519_signing_secret_key and ed25519_signing_cert with a validity period of 30 days (unless otherwise specified in torrc). - -> Since we have the ed25519_master_id_secret_key unencrypted, and at startup we always check for availability/validity of the other ed25519* files by default anyway, we should generate automatically in this case: ed25519_master_id_public_key (if missing), ed25519_signing_secret_key (if missing or expired) and ed25519_signing_cert (if missing or expired). 4. If ed25519_master_id_secret_key exists encrypted in $datadirectory/keys && there is no ed25519_master_id_public_key, ed25519_signing_secret_key or ed25519_signing_cert (even if just one of these 3 is missing): - -> We assume the relay identity existed previously and ed25519_master_id_secret_key_encrypted was restored form a backup. Do not start Tor at all and print explicit warnings that action is required - Tor cannot decrypt the ed25519_master_id_secret_key_encrypted file. Generate ed25519_master_id_public_key, ed25519_signing_secret_key and ed25519_signing_cert or decrypt the ed25519_master_id_secret_key_encrypted in $datadirectory/keys so Tor can do it by itself. 5. If the chain validation fails (ed25519_signing_cert doesn't correlate to ed25519_master_id_public_key AND/OR ed25519_signing_secret_key doesn't correlate to ed25519_signing_cert): - -> We assume the operator probably runs many relays and holds many ed25519_master_id_secret_key files maybe accidentally mixes them and generates temporary signing key and key cert using the master key from another relay. Do no start Tor service at all and print warnings: the ed25519_signing_secret_key and ed25519_signing_cert are generated with the ed25519_master_id_secret_key of another relay. These files should be removed and replaced with the correct ones (search for the ed25519_master_id_secret_key which belongs to this relay). Otherwise it's useless (since we already reject RSA-Ed25519 which don't match), if the ed25519_master_id_secret_key is lost permanently, nothing else for the operator to do but to manually generate fresh identity both RSA and Ed25519 so the relay can be part of the consensus (start from scratch). 6. If ed25519_master_id_secret_key is missing or _encrypted AND ed25519_master_id_public_key is also missing from $datadirectory/keys AND a) we have an ed25519_signing_secret_key and ed25519_signing_cert which are not expired: - ->Automatically compute ed25519_master_public_key from the ed25519_signing_cert and save it in $datadirectory/keys. b) if ed25519_signing_secret_key and ed25519_signing_cert are expired: - ->Do no start Tor service at all and print warnings that user action is required (generate new ed25519_signing_secret_key and ed25519_signing_cert or move the ed25519_master_id_secret_key unencrypted in $datadirectory/keys so Tor can do this by itself). The operator needs to signal Tor with a reload signal (HUP) or restart/stop & start after completing the action. Tor will check for the valid ed25519_signing_secret_key and ed25519_signing_cert by itself every time server restarts (along with Tor process) or at every automated reload signal (HUP). - ------------------------------------------------------ Commands related to Ed25519 keys - ------------------------------------------------------ 1. tor --keygen should be replaced with tor --ecckeygen (keygen is not explicit enough since we are talking about 2 router identities which are used simultaneously [RSA and Ed25519]). - - Ask if user wants to encrypt the key with a passphrase and if yes ask 2 passphrase confirmations. Only allow ASCII, check and return invalid passphrase otherwise (local language keyboards mess things up). I suggest the Encrypt key? question [y/N] should be a No by default. - - Unless user specifies --out /path/to/dir to save the output files, save them in working directory (where the command is run). Do not create the folder and save them in $HOME/.tor. - - Only generate an ed25519_master_id_secret_key with this command (no ed25519_master_id_public_key, ed25519_signing_secret_key or ed25519_signing_cert). Print a message confirming this: ed25519_master_id_secret_key was successfully generated and saved encrypted/unencrypted (depending how it was generated) in $location ($location = either working directory where the command was run either the location specified separately with --out argument included in the - --ecckeygen command). Append _encrypted at the end of the file name in case a passphrase was provided. 2. tor --encryptkey <ed25519_master_id_secret_key file> or /path/to/<key file> - - check if it's a valid ed25519_master_id_secret_key unencrypted, ask for 2 passphrase confirmations and encrypt it. Only allow ASCII, check and return invalid passphrase otherwise (local language keyboards mess things up). - - ask if the user wants to delete the old plaintext ed25519_master_id_secret_key and only remain with the encrypted copy. [Y/n], Yes by default. Delete it in a secure way if yes, obviously. - - save the encrypted key in the working directory where the command is run or with an argument --out /path/to/dir. Print a message confirming this: ed25519_master_id_secret_key was successfully encrypted and saved in $location ($location = either working directory where the command was run either the location specified separately with --out argument included in the --encryptkey command). 3. tor --decryptkey <ed25519_master_id_secret_key file> or /path/to/<key file> - - ask for confirmation: Are you sure you wan to decrypt your ed25519_master_id_secret_key? This will save the master ID key in plaintext, not protected by a passphrase. [Y/n], Yes by default. - - ask for the passphrase and decrypt. - - ask if the user wants to delete the old encrypted ed25519_master_id_secret_key and only remain with the unencrypted copy of it. [y/N], No by default. - - save the plaintext key in the working directory where the command is run or with an argument --out /path/to/dir. Print a message confirming this: ed25519_master_id_secret_key was successfully decrypted permanently and saved in $location ($location = either working directory where the command was run either the location specified separately with --out argument included in the --decryptkey command). 4. tor --newpasskey <ed25519_master_id_secret_key file> or /path/to/<key file> - - ask for the current passphrase. - - ask for the new passphrase 2 times. Only allow ASCII, check and return invalid passphrase otherwise (local language keyboards mess things up). - - update the ed25519_master_id_secret_key file with then new passphrase in place, don't save a separate new copy with this command. - - print a message confirming that the passphrase has been successfully and permanently changed. 5. tor --gensignkey <ed25519_master_id_secret_key file> or /path/to/<key file> - - ask for the passphrase if key file is encrypted. - - generate new ed25519_signing_secret_key and ed25519_signing_cert valid for 30 days unless specified otherwise in torrc. If there is a SigningKeyLifetime in torrc, read it and ask the user: The signing key lifetime in your torrc is n days/weeks/months, use this validity period? [Y/n], yes default. If user enters N, ask the user to manually enter the lifetime. - - save the output files in the working directory where the command is run or with an argument --out /path/to/dir. Print a message which explains that these files need to be moved in Tor's $datadirectory/keys. - - Print a message confirming this: ed25519_master_id_public_key, ed25519_signing_secret_key and ed25519_signing_cert with a validity period of $validity have been successfully created and saved in $location. Please move them to your Tor $datadirectory/keys folder and make sure Tor can access/read them. ($validity = SigningKeyLifetime in torrc or lifetime manually specified by the user or 30 days, the default if there is no torrc setting for this and no input from the user; $location = either working directory where the command was run either the location specified separately with --out argument included in the --gensignkey command). 6. tor --getpubkey <ed25519_master_id_secret_key file> or /path/to/<key file> - - ask for the passphrase if key file is encrypted - - compute the ed2551_master_id_public_key - - save the output file ed25519_master_id_public_key in working directory where the command is run or with an argument --out /path/to/dir. - - Print a message confirming that the ed25519_master_id_public_key has been saved in $location ($location = either working directory where the command was run either the location specified separately with - --out argument included in the --getpubkey command). - ------------------------------------------------------ Permissions - a thing many users don't know/care about: - - If Tor cannot complete a command from above because it does not have permission to read the ed25519_master_id_secret_key print an error message and instruct the user that he should run the tor command as the rightful user or change permissions over the ed25519_master_id_secret_key file. - - If Tor cannot save the output files resulted from a command because it does not have write permissions in the working directory where the command is run or the destination directory manually specified with - --out argument included in command print an error message and instruct the user that he should either run the tor command as the rightful user or select a destination directory where current user has write permissions. - - Always save the output files when using above commands with the correct permissions (I guess these are chmod 0600?). - - Can Tor work if the files in $datadirectory/keys folder are owned by other user than the one running Tor? If not, we should try to detect what user runs Tor on that system (not everywhere Tor runs under debian-tor, in FreeBSD it is _tor for example) and change the owner of the files after they are generated and saved. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJVv/FNAAoJEIN/pSyBJlsRQJYIAJvO10nrCyGR7ImHptZS+GGN DQS424+drGF5uwMunADN/m9MQ2sqXBfa9xA74irA9KU4y1HtY4NUTJZWC9mUrlZv xb8nkp1jml6NMk7M8RQ/A330Ca04bTNcMOzvaBwqDodlG4GDuiNBMnia2SIqzaBD WSLzVQ1wz5zVdF5CPblQXIzS8jhLYQU4wjQf3Z7nnmPgjjn4HNKcd9Q9x/DWRCL7 TsdgE05ZCHpjCzep9xi0RhPV4tdY77Yti7n9b81ty4O+ctYSU8kzvYhiY4nglnDH YQvJSvDH2QnNqR6QXcC+cHSLAkoJMM56OLKoZmhU6cJkbZ3aC/9I5EcFyAZs62E= =X/f3 -----END PGP SIGNATURE-----

2 8

please can haz code review -> Tor-ified Twisted Python HTTP proxy server - txtorhttpproxy
by David Stainton 11 Aug '15

11 Aug '15

Dear Twisted/Tor developers, I am motivated by language security concerns. I think Twisted Python can often implement excellent replacements for our old crufty C implementations. In this case I'd like to stop using C programs running as root (or not root) to torify http connections... like privoxy, polipo, apt tor transport etc. Last year I wrote this little tor http proxy; yes it also handles RFC 2817 proxy CONNECT method as well: https://github.com/david415/txtorhttpproxy I wrote an AgentProxy that can proxy any sort of twisted http agent: https://github.com/david415/txtorhttpproxy/blob/master/txtorhttpproxy/proxy… It used to use more terrible underscore imports but Leif fixed the bit-rot and made it work with Twisted 15: https://github.com/david415/txtorhttpproxy/commit/38f1a0cfab586f7a8965a47e9… Is this project worthy of your precious 10 minutes to review it... so I can improve the code quality? If I get rid of this last terrible import: from twisted.web._newclient import ResponseDone then I'm not sure how to detect when to call the finish() method here: https://github.com/david415/txtorhttpproxy/blob/master/txtorhttpproxy/proxy… Sincerely, David Stainton

1 0

Re: [tor-dev] First release of OnioNS for beta testing
by Jesse V 11 Aug '15

11 Aug '15

Thanks Dr. Fu, I look forward to your comments. From the server log, apparently so far no one has tested the client, though someone has set up a server. I just want to highlight that I have servers up and running so the client and the HS functionality should work out of the box. For the client, install the software then follow the instructions in the README to integrate it into the Tor Browser. My current approach is to rename the Tor binary from "tor" to "torbin" and then insert a symlink to the onions-tbb executable under the name "tor". Then the onions-tbb software lauches "torbin", "onions-client", and the Stem script in that order, thus allowing all the necessary software to start with the Tor Browser. I have also added some functionality to wait until Tor is fully bootstrapped before launching onions-client and the Stem script, thus this approach is fully compatible with Tor bridges. Jesse V. > Subject: > Re: [tor-dev] First release of OnioNS for beta testing > From: > Xinwen Fu > Date: > 08/08/2015 04:25 AM > > To: > "tor-dev(a)lists.torproject.org" <tor-dev(a)lists.torproject.org> > > > Fantastic work. Will test it. > > Xinwen Fu >

1 0

Invitation to participate in a survey about Tor's future
by Sue Gardner 09 Aug '15

09 Aug '15

Hello people of tor-dev, You may have heard that I'm working with the Tor Project to help it develop a strategic plan [1]. To kick off, we're running a survey asking Tor-related people their opinions about Tor and its future. I'd like to invite you to participate: https://www.surveymonkey.com/r/tor_core The survey's pretty short and should take about 15 minutes to fill out. If you have time to do it within the next few days, that would be great. We'd really appreciate your input :) If you've got questions, there's an FAQ here (or you can just ask me here on this list). https://trac.torproject.org/projects/tor/wiki/org/Strategy/SurveyFAQ Thanks, Sue [1] http://suegardner.org/2015/05/20/why-im-working-with-tor-and-first-look/

2 1

collector problems since 2015-08-07 18:00?
by nusenu 09 Aug '15

09 Aug '15

Hi, I was wondering why onionoo reported empty platform strings for a growing number of relays. I wanted to confirm that by looking at collector data, but then I noticed that there is a problem with collector data itself. Files in [1] usually have a size of around 1 MB, currently they are at 1KB (basically empty). @thomas: Is that the cause for your onionoo instance issue? [1] https://collector.torproject.org/recent/relay-descriptors/server-descriptor…

3 3