- tor-dev - lists.torproject.org

Error in javascript:ISSUE#6761
by AKASH DAS 05 Sep '16

05 Sep '16

There is an error in the javascript syntax in https-anywhere which the test bypasses. I have issued it in the github link https://github.com/EFForg/https-everywhere/issues/6761. On Mon, Sep 5, 2016 at 10:49 PM, AKASH DAS <akash.d14(a)iiits.in> wrote: > If I have to make any patch in the code, do I have to submit it in this > mailing list or https-everywhere's mailing list? Just a doubt > > On Mon, Sep 5, 2016 at 10:35 PM, David Fifield <david(a)bamsoftware.com> > wrote: > >> On Mon, Sep 05, 2016 at 10:28:26PM +0530, AKASH DAS wrote: >> > Can I know the issues that are currently in https everywhere. >> >> I don't know if this is what you're looking for, but here are some open >> bug tracker tickets. >> >> https://trac.torproject.org/projects/tor/query?status=!close >> d&component=HTTPS+Everywhere%2FEFF-HTTPS+Everywhere >> https://trac.torproject.org/projects/tor/query?status=!close >> d&component=HTTPS+Everywhere%2FHTTPS+Everywhere%3A+Chrome >> > > > > -- > > *Akash Das* > > *Student Systems Admin* > > *Indian Institute Of Information Technology* > > *Sricity* > -- *Akash Das* *Student Systems Admin* *Indian Institute Of Information Technology* *Sricity*

1 0

HTTPS Everywhere
by AKASH DAS 05 Sep '16

05 Sep '16

Respected all, Can I know the issues that are currently in https everywhere. -- *Akash Das* *Student Systems Admin* *Indian Institute Of Information Technology* *Sricity*

3 4

Re: [tor-dev] [tor-talk] Onion Service introduction point selection
by George Kadianakis 03 Sep '16

03 Sep '16

Muhammad Hammad Mazhar <mmazhar(a)uiowa.edu> writes: > [ text/plain ] > I am looking into Tor onion services as part of my research, and am interested in how an Onion Service selects its introduction points, in particular where in source code does it do so. I am aware of rendservice.c in the source code, but any pointers are welcome. > > Please move this mail to the requisite list if required. > You were very close! Please see function rendservice.c:rend_consider_services_intro_points() and related code. [Moved to [tor-dev] from [tor-talk])

1 0

onionoo: poor reverse DNS results
by nusenu 02 Sep '16

02 Sep '16

Hi Karsten, some time ago I reported onionoo's poor reverse DNS results https://trac.torproject.org/projects/tor/ticket/18342 and it didn't change since then. As of 2016-07-02 08:00 (tpo instance) 3144 out of 8473 (~37%) still have no reverse DNS result (=IP address). Do you have an idea whether this will improve sometime before 2016-09-01? thanks, nusenu btw: Thanks for working around the maxmind AS problem with reverting to the May version.

2 2

txtorcon 0.16.1
by meejah 01 Sep '16

01 Sep '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm very happy to announce txtorcon 0.16.1 which adds a couple minor features to help support using Foolscap and Tahoe-LAFS over Tor. * issue 172: give TorProcessProtocol a .quit method * issue 181: enable SOCKS5-over-unix-sockets for TorClientEndpoint (thanks to "dawuud"). Also adds TLS support over SOCKS5. You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.16.1 https://github.com/meejah/txtorcon/releases/tag/v0.16.1 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.16.1.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.16.1.tar.gz.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check d551837025bb9f4fdded58cd11025c6e42924b6eb20dcb2a49f182b3fd85f377 dist/txtorcon-0.16.1.tar.gz e89a785f64f3544b19f7b1e6cebdbd6914475e0c60f508d9f0b6ce4a840769a7 dist/txtorcon-0.16.1-py2-none-any.whl EOF thanks, meejah p.s. There is no 0.16.0 because I tagged the wrong thing and noticed when pushing to PyPI. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXx3TOAAoJEMJgKAMSgGmn7AEIAN5BQNqisxefMyKnHA8BCSZW UJpXPagnftg33HF2v4ZG/2yQUh8sYMqEn/OI99g8yA++bZmG9H0lJixg0zs6V2XV bX63zJ7d9lr+uu3D+crQNnmofcoUbLRX+Z7n5SWhgGtlsVqemIJton/cuedtnrXm 1E5VdjhxYIZ/2Qv0gTz7ZBYw0Hmkr24qwVufdblQHDov2SdM0kknInWqxFqVMLQd /p0+PTEF6SMdemHFkOJ73sCbINg6qLB4cErKaFY14U2cnS3Y1pZLhlEKFTzbd8TU SWtg1b9pn5s4Euq5ruYhNNIqVtQz/lrq0/ZQ+NKiLZ/L2rtw9xFY0nF1KhFTgLc= =IMj2 -----END PGP SIGNATURE-----

1 0

Bifroest's sanitized bridge descriptors available from CollecTor in 48 hours from now
by Karsten Loesing 31 Aug '16

31 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, if you're not using CollecTor's sanitized bridge descriptors for anything, you can safely ignore this message. As you may know, there are currently two bridge directory authorities in the Tor network, Tonga and Bifroest, and Tonga will go away some time this weekend. You can fetch sanitized versions of Tonga's bridge descriptors here: https://collector.torproject.org/recent/bridge-descriptors/ We're also now ready to provide sanitized versions of Bifroest's bridge descriptors. The only differences to Tonga's descriptors are: - Statuses will have Bifroest's fingerprint in their file name rather than Tonga's. Example: https://people.torproject.org/~karsten/volatile/20160829-164232-1D8F3A91C37… - There will be two "concurrent" statuses published by Tonga and Bifroest this week, containing two distinct sets of bridges. I'm holding back Bifroest's descriptors from CollecTor for another 48 hours or so to give you time to prepare for this change. After all, you might have written your code under the assumption that there's just a single bridge authority, and the above change might confuse your code and break it. Everything will be on CollecTor in 48 hours from now. All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJXxHytAAoJEC3ESO/4X7XBMfAIAKXADVnMGK5rYmbZN5ymF2M8 IbFc/6VWV+CoUdss868Dp5/Y3huE6SgFXCe3A+R+jCg5Od8rIiWKEfNvVeLEXpU1 DtuYNAq3vlhVhHTOdWmCz2uRVeWNddb12RDa+H55QtGHC4JC8HP9PRSN+lLj5fBr YBuKvLAWfMOsfdAqVJwHmmhtORPag7wL2NWmmk/y4j9JCzQ//NmUv3CMdIQm+j98 pM5jwI6ogiec2f/Nbij3eSJHCAhHKuL5TKR6E+//TE/s4ZGBKDPxkw+w/PdQrViC A3RgDVm7sqrjKkm2jWHVEuTa36QdzBgpV6vH1tEmTrHTz7Epre3MVFwKR607LBM= =gXT3 -----END PGP SIGNATURE-----

1 1

metrics-lib/DescripTor 1.4.0 is released
by Karsten Loesing 31 Aug '16

31 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, we just released metrics-lib/DescripTor 1.4.0: https://dist.torproject.org/descriptor/1.4.0/ - From the change log: # Changes in version 1.4.0 - 2016-08-31 * Major changes - Add the Simple Logging Facade for Java (slf4j) for logging support rather than printing warnings to stderr. Applications must provide slf4j-api-1.7.7.jar or higher as dependency and can optionally provide a compatible logging framework of their choice (java.util.logging, logback, log4j). * Medium changes - Add an alpha version of a DescriptorCollector implementation that is not enabled by default and that uses CollecTor's index.json file to determine which descriptor files to fetch. Applications can enable this implementation by providing gson-2.2.4.jar or higher as dependency and setting property descriptor.collector to org.torproject.descriptor.index.DescriptorIndexCollector. * Minor changes - Include resource files in src/*/resources/ in the release tarball. - Move executable, source, and javadoc jar to generated/dist/. Happy descriptoring! All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJXxp6UAAoJEC3ESO/4X7XBUF8IAMuIPxoCkt9FR6LolUmuyk3I +eElyry5r8jUGDiBOxx0TWrYxr6ZrvxOD6lxzvG0a/nfAF+cdELJyNE+1+GiTku2 rgM/1NcxqGq6yBzxMFOZXPv1VG35LmpFtQUnxZR5Ij8x/p3SweMlbHUAVShSQZT2 tuRi32YCBZyH8XgD65XAak0SZ7co7aMZOORsixymFYW2oRYOxOkARX4sA4AfA4ED Nkqwa4fhX3b4uIshbzpifXm0ACkAxEUwewLS/g6vkKcn0a0tS6DC3mDrzIOAvF8v VTLghyZKbuWWuGZAlLEDhyHmo3/Afy6ETb1cFy/lvJUVnu/W8P4sbRnQrfvVJ/s= =Ugsq -----END PGP SIGNATURE-----

1 0

Requiring p lines in consensuses
by Sebastian Hahn 31 Aug '16

31 Aug '16

Hi there, Karsten and I have been working on metrics-related tasks and one thing that's got a potential to cause us pain going forward is that of "p"-lines in consensuses. Tor has added them with consensus method 5 but only declared them to be optional. In practice, every consensus ever produced that used method 5 or later has added these lines, and I'd like to require them to be included going forward. The reason is that without looking at the consensus method, there's an ambiguity wrt exits: A missing line either means "reject 1-65535" (method 5 or later) or "no information" (anything before that). I believe this should cause no compatibility issues and wouldn't require a new consensus method. Is there some reason against doing this now? Cheers Sebastian

1 0

Alternative Implementations of Tor
by Alexander Færøy 29 Aug '16

29 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Over the past year I've been hacking, on and off, on an implementation of Tor in the Erlang programming language. The project started out after I met Linus Nordberg at the Erlang User Conference in the summer of 2015 - -- a couple of weeks before the CCC Camp in Germany. Linus and I discussed what it would take to get a very basic implementation of a Tor relay up and running in Erlang. The project has been named Talla, which is still open for change -- especially if it collides with an already established project within the wider Tor development community. I was unable to find any name clashes myself, but I may very well have overlooked something. The parts of Talla that is implemented in "pure" Erlang is going to be licensed under a two-clause BSD license. Talla also contains a "module" which is using Tor's ed25519 ref10 implementation (Thanks to Yawning for a great amount of help there) -- that module is licensed under the same license as Tor itself. I'm now at the point where things are slowly starting to take form. The important pieces of the code have so far been kept available only to a tiny group of close friends that I trust not to share the code until I, and possibly other people, considers that the code is stable enough for the wilderness of the wider internet. There is, to my knowledge, currently only one implementation of Tor that is actively in use on the production network, which is the C implementation. I'm aware of a Haskell implementation made by Galois, which to me mostly seemed like it was designed to be building blocks for writing more specialized clients and doing research with the Tor network. Last time I looked, the Haskell implementation's main function was doing a DNS lookup through a circuit within the Tor network and then quitting. I was also told there had been an implementation in Go that have had activity on the production network, but that project was abandoned by its maintainer. In general I'm a bit uncertain about the "best practices" of dealing with a third party Tor implementation, which Talla is. I'm writing this email to receive suggestions, comments, and possibly creative ideas about the following: 1. What is the general criteria set from the Tor project's perspective on when it is acceptable to make alternative Tor implementations available to the general public? I'm currently testing Talla using Chutney with a mixture of NTOR and pre-NTOR Tor daemons running (inspired by one of the configuration files in the Chutney repository, which referred to a 'tor-old' binary). My current plan is to stabilize Talla further until my gut feeling is that I can try to announce a single, middle, relay to the production Tor network. This relay will, of course, have a platform-string set to something easily identifiable like "Talla 0.0.1 (...)" and the contact-string set to a valid method of reaching out to me with, in its announced server descriptor. I will closely monitor that things are going as I expect and probably turn it off shortly after the test, when I have seen that my code isn't too "crashy" -- this will most likely be repeated a number of times until I'm satisfied with the results. Could I do more to ensure that the people caring for the network as a whole wont fear me pressing the start-button here? 2. I will not do any classical releases (as in packagable .tar.gz) until I'm past the point where my gut feelings are telling me that my code is reasonably stable for the production network of Tor. I will, in a very visible location, request that no distribution developers makes any packages of the code until there is a release. I think this is already the norm, but I guess being explicit won't hurt. 3. I will write, also in a visible location, a warning that the code is not production ready and that people should probably stick to running a Tor relay using the official Tor daemon and point to the installation instructions on torproject.org. 4. Not have any installation documentation and hope that Erlang is still an esoteric enough language to make people pass by without trying :-) 5. Talla will not have any references to the directory authorities that are currently used for the Tor production network. This means that anyone who is interested in running Talla will have to explicitly set the directory authority servers in Talla's configuration file. This will allow people who want to toy around with it together with Chutney to be easily able to do that. Why am I asking all these questions now, when I could just wait until Talla is ready? In two weeks there will be a smaller hacker camp in Denmark, named BornHack, where I was planning on giving a talk on the development of Talla, the design of the Erlang application, some of the many refactoring periods there have been, general information about how Tor works, and the testing of Talla. At the same time of the presentation I want to make all of the code for Talla available for the audience and public to see even though it at this point is not ready for "production usage" on the public Tor network. I hope this email will also allow us to discuss the wider concept of a network where there exists multiple implementations and the consequences of that. It might be there are other people hacking on a Tor implementation in their favourite language :-) I'm also on IRC as 'ahf' if anybody wants to talk about things regarding Talla that is outside of the scope of this email. Thanks you! Cheers, Alex. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXtHtlAAoJEPm8L+IrCM6PNl4P/08HCGnEpLADudaul9KX4bzL OqcygCP6AXpFUZdUqsD+hgPRgi97NYaNZas/hWimQyye3OfLw4EH29lukGiBrIZu Fp+bT2CAsan8Nn+Vb3rH0em1PPOyXYJ/qhYrXex/CPk5kY7CIatbwau9AgwylAKs 8G3wz364EQaAwq5v4BVTieenFxtNXfnjwtlPkNhtJUgRDwrj16v2IqwN1C6nIq2p E86Vok4ToWKwfzIshf2wESSGWHZ+K9bpZs+e1GnSkY4VgwpKE1Swp/8IhIlxa843 KO4EknByZIWqZrEORCd43nok88hW8tpbnuoMCE5HGMJzw/KTwQrSiS794cAnyhYt 6yokEUO3JdwRuJxLPzmLZc8tBniBaKuGfRbqC7XAurJkgq+UgLukgYWnlyvHlap+ RZaNpMqFQf8grMHWGd6ffxYzAcIc+935XN4D54Ua17seIpDHnKGKS04ZmKwBeCxy myafcqSxJsNrqYEN40QrtYdgU0zv74S75uU/DHAHcOcaPyAy5yHGAqAdOeGvtpV5 6/VAQDwbOPncfIntoU8FUjKcpKJBn5csltuknwDiWKFYLfAVqVawMYO2Ef12hDul 7SuqOksSL2Yx59m/0Bu8i0QARxZBw8x8TzuQ7RJkNmDeTR17ugDOIaBKV1Se9fgS JaHsOgLd/G0T7S4PT5vQ =IeQJ -----END PGP SIGNATURE----- -- Alexander Færøy

4 3

Some information about Tor relays
by Liu, Zhuotao 26 Aug '16

26 Aug '16

Hi Folks, This is Sky from University of Illinois. Currently we are working on research project related with Tor. To help us to better design and evaluation our proposal, we need some information about the Tor relays that is currently unavailable from the Atlas. Thus, if someone who operates Tor relays could provide us such information, your help will be greatly appreciated. :) We hope to have an estimate about computation capacity of Tor relays. For instance, how many circuits a relay can maintain when its CPU is driven to about 100%? On average, how many circuits are maintained by a busy guard and what the CPU utilization is. These kinds of information would be really helpful. Further, in Sep 2013, Tor saw a spike in its clients. https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients The suspicion is that a botnet used Tor as its C&C channel. Is there any data about the relay utilization during that time? For instance, how many more circuits a relay had to maintain during that time? Thanks a lot for your help. :)

4 7