- tor-dev - lists.torproject.org

Re: [tor-dev] Marker branch for current tor release(s)
by teor 25 Jan '18

25 Jan '18

Hi, Tor branches are a question for tor-dev@, I am directing all responses there. Also, I fixed the top-post. > On Jan 5, 2018 00:48, "Andreas Krey" <a.krey(a)gmx.de> wrote: > > https://www.torproject.org/download/download.html.en in the source code 'tab' > states the current stable and alpha version of tor. > > Would it be possible to publish the current states as branches 'stable' and > 'alpha' (or 'testing', or 'unstable') in the git repo? What do you mean by "alpha" and "stable" ? When tor 0.3.2.9 is released next week, there will be no alpha version. When this happens, do you want master, or the latest stable? When there are multiple supported tor versions, which one should be stable? At the moment, we support 0.2.5 and 0.2.9 as long-term support, and 0.3.0 and 0.3.1 as regular releases. Should stable be 0.3.1 (and change to 0.3.2 next week)? Do you want a long-term support branch as well? Should it be 0.2.5 or 0.2.9? > That would help us tor-from-source builders to just fetch the repo, and > if the respective branch changes, to rebuild and redeploy. Looking for a > new release tag or screen-scraping said web page is a bit hairy, and feels > unnecessary. If you want something that's easier to scrape, and signed, check for new source releases at: https://dist.torproject.org/ We provide the latest Tor Browser version through a URL (which I can't remember right now). Maybe we could do the same thing with Tor. > On 5 Jan 2018, at 23:17, Chad MILLER <chad(a)cornsilk.net> wrote: > > I second this. > > There's a recommended-versions list in the consensus, but you have to already have Tor available and running to get it. No, you don't need Tor: $ curl http://197.231.221.211:9030/tor/status-vote/current/consensus-microdesc | grep server-versions | tr "," "\n" | tail -1 0.3.2.8-rc Or you can do this far more reliably in Python using stem: https://stem.torproject.org/ > Maybe also publish in a DNS TXT record or something? Is that secure? Can you sign a TXT record? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

4 7

Pluggable transports research
by Jodi Spacek 25 Jan '18

25 Jan '18

I'm a master's student at the University of British Columbia (Vancouver, Canada) where I'm primarily researching anonymous systems and censorship. I would be delighted to contribute to pluggable transports. Of particular interest is image and audio data stenography - is anything is in the works for this or is it outdated? My aim is to add this functionality while fully testing and evaluating it as part of my thesis project. I refer to the list of idea suggestions here: https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/ideas Any guidance is greatly appreciated. Thanks so much! Jodi p.s.: Please advise if this is not the correct mailing list. and perhaps belongs in tor-assistants. If so, I will inquire there once my access is (hopefully!) granted. -- www.jodispacek.com

5 5

tor failing to resolve some dns records
by blaze glory 23 Jan '18

23 Jan '18

3 2

WIP proposal for migration to TLS 1.3
by isis agora lovecruft 22 Jan '18

22 Jan '18

Hello, It's not done yet; it probably has errors; it definitely has omissions; it's still riddled with "XXX"s everywhere… but here's a work-in-progress draft proposal for migrating our link protocol(s) to use TLS 1.3: https://gitweb.torproject.org/user/isis/torspec.git/log/?h=tls13 It's not quite ready for a whole bunch of feedback yet, since I'm still reading through all the specs and writing the proposal. However, if you're super knowledgeable about TLS 1.3 and have opinions or ideas or see a mistake/misunderstanding somewhere, please feel free to share! Thanks! Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

1 0

No Control Socket when DisableNetwork 1
by iry 20 Jan '18

20 Jan '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tor Developers, According to the Tor manual: https://www.torproject.org/docs/tor-manual-dev.html.en > DisableNetwork 0|1 When this option is set, we don’t listen for or > accept any connections other than controller connections, and we > close (and don’t reattempt) any outbound connections. Controllers > sometimes use this option to avoid using the network until Tor is > fully configured. (Default: 0) However, it seems when DisableNetwork is set to 1, /var/run/tor/control does not exist anymore making us cannot get a controller from socket file. (stem.control.Controller.from_socket_file() is affected in this case: https://stem.torproject.org/api/control.html#stem.control.Controller.fro m_socket_file) To reproduce this, I tested both Tor 0.3.1.9 and 0.3.2.9 on Debian Stretch: When DisableNetwork 0, run: systemctl --no-pager restart tor@default > user@host:~$ ls -l /var/run/tor/ total 1328 srw-rw---- 1 debian-tor > debian-tor 0 Jan 19 21:14 control -rw-r----- 1 debian-tor > debian-tor 32 Jan 19 21:14 control.authcookie -rw-r----- 1 > debian-tor debian-tor 1350116 Jan 19 21:14 log srw-rw-rw- 1 > debian-tor debian-tor 0 Jan 19 21:14 socks -rw-r--r-- 1 > debian-tor debian-tor 6 Jan 19 21:14 tor.pid When DisableNetwork 1, run: systemctl --no-pager restart tor@default > user@host:~$ ls -l /var/run/tor/ total 1244 -rw-r----- 1 debian-tor > debian-tor 32 Jan 19 21:00 control.authcookie -rw-r----- 1 > debian-tor debian-tor 1269005 Jan 19 21:00 log I searched on Tor-trac but did not find any similar report. Therefore, would you please tell me wether Tor intentionally behaves like this or this is a bug? (If this is a bug, I can definitely help to report it to Tor-trac.) Thank you so much! Best Regards, iry -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlpifX0ACgkQoUtNvG3N 1TwLsBAAn8W3H7VMwiR9UwnVJoXOZ0iWRLbF/JdtDUjXcG1/cQmK5aEHtbVCy4Jl VOWYKBJeHxZAmHlBC+ZR3E/vyDesatjPDIPvzUuwYN3T0COFpMyN71ipOjs1KqYP GFFgLFzClQHvnThe59TIEomVcdXIt9ebPU3QmVxnNhvB/KKggKOgTuYd/n8R0efe 0kAl5/8vZZv4/IiorRkF/ltQwmnOTR1V2H1OrOOHM/AyxLGfwGO9KffznRDX/BN4 AdM4MWpMh3+DKCKgJZpf3Gzwcn7d6DvL74YQVIhmwofoxEOCBD/f+iYeJKkoVPw7 Pd8YHkYvXqCRqHBFfTEe4BtZdcxK2k3FXbUcbKahFDYMtdotdzknf542f6+Bbt+p hmiuJT8bX/Kn2dBzonbqJuh2XEBA2y6OqqhJaVoJr5l6tWyghp18BsA2m6W4mg2H ApkUTv0YsQ8guXckfJP2LOhXxKWN0yncQ7bMzGZSfSwtqGwrDxFFWk2V8vXIrWWL X5pz3oObvQB9eUJcKix2C29kJSGBry68Ts1x4MnL14CDw0WqNqAqe0O3IAiCANjl CU+z9P129eb/pdYXW/OTFnVyWhQBXNvCRHTZB7Yvym+dN4B6MD3uOkH9THf9BaCF yVCOK1c04/sfqADnpE3Rhkr98iix3N2gbdOod/10T+GyG4OBh64= =Oh0M -----END PGP SIGNATURE-----

3 3

(no subject)
by blaze glory 16 Jan '18

16 Jan '18

1 0

Error-Correcting Onions with Bech32
by nullius 12 Jan '18

12 Jan '18

# Synopsis The Bech32 standard for error-correcting base32 strings was developed explicitly for relative ease and reliability in human communication of pseudorandom bitstrings. I invite discussion of specifying Bech32 as an alternative means for representing RFC 7686 .onion domain names. Should the response hereto be positive, then I will offer a formal proposal. I have written and released a tool which automatically recognizes and encodes/decodes .onion addresses in Bech32. To complement whatever I here say, please get a hands-on feel for Bech32 .onions: https://github.com/nym-zone/bech32 Manpage (yes, a real manpage!): https://raw.githubusercontent.com/nym-zone/bech32/master/bech32.1.txt # Background: About Bech32 Bech32 is specified by the Bitcoin BIP 173 standard,[1] co-authored by Pieter Wuille and Greg Maxwell. According to Mr. Maxwell, “Bech32 is designed for human use and basically nothing else”; the underlying research and development process involved extensive testing with human users, analysis of NIST visual confusability data, and the integration of a BCH code with strong error correction and detection properties. [1] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki I refer to BIP 173 for further explanation of Bech32’s design properties, its rationales, and the limits of its error handling. A specific application of Bech32 is Bitcoin’s new address format for the future, which I call “Bravo Charlie Addresses” after the letters “bc” specified for Bitcoin addresses in the standard’s “human-readable part” (HRP). However, the standard was written to permit general use in other applications. Having in hand a standard explicitly designed to ease the pain which wetware suffers when it comes into contact with pseudorandom gibberish, the cypherpunk in me is overjoyed at the potentials. One is a concept which I call “PGP Descriptors”, which I am currently working to specify with a few extra features and nuances. And of course, I think of .onions! # Bech32 for .onion I hereby nominate “onion” as the logical HRP for RFC 7686 .onion special-use domain names. Here is Bech32 .onion by example, using my bech32 tool with its built-in .onion support to encode and decode the name for the Tor Project’s .onion equivalent of its “www” site: ``` $ bech32 -e expyuzz4wqqyqhjn.onion onion1yh0c5eeuksscs8fdyd8406 $ bech32 -d onion1yh0c5eeuksscs8fdyd8406 expyuzz4wqqyqhjn.onion ``` The string is longer, because it contains 6 base32 characters’ worth of error-correcting code. N.b. also, the foregoing should work just fine for v3 onions (formerly prop-224). Imagine the impact on users who have a practical need to transmit a .onion address by verbal communication, or via a handwritten note. Now they can get some help with errors, instead of wondering why they can’t connect to a nonexistent .onion site. The standard enjoins applications against autocorrecting Bitcoin addresses, so as to prevent even the slightest possibility of causing funds loss by being too “helpful”. But in applications where it would be safe to do so, Bech32 can indeed correct small errors (as well as reliably detecting much worse errors). I suggest that such automatic correction would be suitable for .onion addresses. Bech32 co-author Dr. Wuille (sipa) has published Javascript reference code, plus a Javascript error-correction demo, under an MIT license. Perhaps this may be easily adapted into Torbutton, for automagic decoding of Bech32 “onion1” to .onion domains in the Tor Browser address bar. The code is in the same repository whence I copied the Bech32 reference C code I use internally in my tool: https://github.com/sipa/bech32 # Conclusion—or, to be continued... An alternative representational format with error-correcting codes will make .onion addresses more human-friendly. I look forward to the day when “onion1” addresses can be passed by handwritten notes, vocalized with a radio alphabet, stuffed into QR codes, scrawled on parchments placed in bottles tossed to sea, rocketed into space, and then conveniently transformed with appropriate corrections into the DNS-style .onion format specified by RFC 7686. Here’s to the alternative Onion format of the future! -- nullius(a)nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested: 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE) “‘If you’re not doing anything wrong, you have nothing to hide.’ No! Because I do nothing wrong, I have nothing to show.” — nullius

6 15

New Fallback Directory File Format
by teor 12 Jan '18

12 Jan '18

Hi all, Some time in the next few weeks, the Tor fallback directory mirror file format will change. This affects stem and Relay Search, which parse this file. Change Description Here is a list of changes to the file format: * the "weight" line has been removed, and replaced with a Tor config default (#24679, #24681) * the comma that separates fallback C strings is now on its own line * a "nickname" comment has been added (#24600) * an optional "extrainfo" comment has been added (#22759) The added fields will be populated with placeholders until the list is rebuilt (#22271). This will hopefully happen some time in the next few weeks. Requesting More Extra Info Caches There are only a few fallbacks that cache extra-info documents. I checked 67, and only 4 cached extra-info documents. atagar, do you want me to ask some fallback operators to set DownloadExtraInfo 1? What number or proportion would you like? (We allow approximately 25% of fallbacks to go down before we start to rebuild the list. In the worst case, this can mean that ~40% are down at some point.) Example Entries A sample entry in the new format, using actual relay info: "5.9.110.236:9030 orport=9001 id=0756B7CD4DFC8182BE23143FAC0642F515182CEB" " ipv6=[2a01:4f8:162:51e2::2]:9001" /* nickname=rueckgrat */ /* extrainfo=1 */ , The current fallback file in the new format, with placeholders: https://github.com/teor2345/tor/blob/ticket22759_tree/src/or/fallback_dirs.… A small sample fallback file in the new format, with actual relay info: https://trac.torproject.org/projects/tor/attachment/ticket/22759/fallback_d… Please let me know if you would like any changes to the format. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

4 14

Agnostic Tools: Code Dev and Support For
by grarpamp 12 Jan '18

12 Jan '18

> I'm interested in helping you guys with Tor development. I don't really care > what I work on, except I do not support .onion websites (though I am willing > to be convinced otherwise) so I would prefer not to participate directly in > their development. I have plenty of experience with writing code Folks in convo before have covered some of these areas and more that one could surely find or think of... Philosophical... Why does someone want to support and develop for Tor, or any other overlay p2p anonymity network, or crypto, for that matter? When even a fix to the manpage could be read and used by onion users and operators, same for metrics, lists, or any other part of the ecosystem. Does one fear "bad" things, association, or support "good" things? Does freespeech, anonymity, privacy, human rights sound "good"? What is "bad"? Censorship? Theft, Dictatorships, Police States, whether one's own, that of the Enemy, or that of the Oppressed? Cryptocurrency, anonymity, free markets, privacy, messaging... "bad"? "Good" [only] when used to defeat "bad" things inside or outside of [mal]functional democracies that assert majority force over minorities who have forced no one? Ricochet, Signal, GPG... "bad"? New technology that forces change over old entrenched ways... "bad"? Are anonymous forums where professional therapists give pro bono counseling to even the most reviled, depraved, criminal, socially scarlet lettered and outcast... "bad"? Materials and talk of religion? Are datamining, traffic archiving, exploits, cleartext... "good"? Tor has exits... do people realize how much of both what they like to "support", and abhor, travels over those exits? The variety of traffic there is no different than onions. Should exits be unsupported? What about the internet, or printing presses, should those tools be unsupported? Are they "bad", get their makers looked askew? Onions, exits, internet, presses, hammers... all simply agnostic tools. Tools can be used to build great things, to defend, or to wield in bloody murder. And what of biases over certain agnostic tools instead of over the separate "good" or "bad" uses of them? Do other tool builders and users have to wonder if their tools are being compromised by those with such biases? What of when those with biases end up needing the tools themselves, what will be the tool quality, or their ability to do "good" with them? Have people taken the time to explore the onion space to find and participate in all the "good" things they like therein, to create and grow them, or even engage in counsel and advocacy against the "bad"? What tools would be needed to do that? Yes, people are free to work on what they like... including giving deep thought as to what they like and don't, and why, and how supporting agnostic tools can actually fit with that. Are not your pens tools? Who likes those? Who supports those? What if they didn't? Pens... write code. Tech, fun, politic... Amounting to consideration feature X may prevent or diminish a better archictecture on balance for some higher importance feature Y. That should be covered open devops as usual. Or if the *technology* or *code* of eg: eepsites onions, or other subsets of various projects are not in their interest or knowledge practice area. Ok. Or if the features provided by any overlay network or tool are deemed flawed, and the technical or political effort to get them fixed, or rearchitecture, or correctly advertised, or called out within as bunk, is too high, therein it may be better to abandon them and or speak out freely as such.

4 6

Volunteering for Tor
by Charles Hunt 11 Jan '18

11 Jan '18

After 15 years of desktop support, I am following my passion to be a Python3 programmer. I am still an amature programmer, but I aced the python fundamentals course from Coursera to flesh out my skills. I would like to continue developing my programming skills by volunteering for Tor. Do you have something I can help with? Thank you. Charles

3 3