Re: [tor-dev] Alternative Implementations of Tor
On Wed, Aug 17, 2016 at 11:01 AM, Alexander Færøywrote: Hi, and sorry for the delay! It's a crazy week here. :) > 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? Sounds like a start! As for advertising stuff in server descriptors, we're moving towards a new way to advertise support for the different sub-protocols that make up the Tor network. I hope that we'll merge it some time over the next month. Please see ticket 19958 and proposal 264 for more information. I'd especially like any comments you can give, from your perspective, before we finalize the design and implementation. > 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. I think that's a good start too! I'd recommend that everybody who is doing any kind of new cryptography system put a big warning on the early versions this way. Thanks again for doing this work; it looks exciting! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Alternative Implementations of Tor
Alexander Færøywrites: > [ text/plain ] > -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
Re: [tor-dev] Alternative Implementations of Tor
Add your projects here... https://trac.torproject.org/projects/tor/wiki/doc/ListOfTorImplementations ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Alternative Implementations of Tor
> On 18 Aug 2016, at 05:23, Nathan Freitaswrote: > > On Wed, Aug 17, 2016, at 11:01 AM, Alexander Færøy wrote: >> 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, > > Not sure how widely implemented it is, but Orchid was a formally > implemented version of Tor in Java, by the Toronto-based Subgraph group: > https://subgraph.com/orchid/index.en.html > > It was, at one point, integrated into the Martus human rights > documentation platform. > > The developers are likely on this list, or if not, easily reachable to > ask for any lessons learned. Tor uses the version in the platform string to detect features, so some alternative implementations claim to be a particular Tor version. Other alternative implementations might not report a version at all. At the moment, I see the following platforms reported on the network: Tor 0.2.4.19 on Windows XP,65833 ... Tor 0.2.9.1-alpha-dev on OpenBSD,1928192 node-Tor 0.1.0 on Linux x86_64,168444 So it appears that node-Tor is still going strong. And everything else just wants to blend in. A stem script to generate the full list is: - import sys from stem.descriptor.remote import DescriptorDownloader def get_bw_to_platform(): bw_to_platform = {} downloader = DescriptorDownloader() try: for desc in downloader.get_server_descriptors().run(): if bw_to_platform.has_key(desc.platform): bw_to_platform[desc.platform] += desc.observed_bandwidth else: bw_to_platform[desc.platform] = desc.observed_bandwidth except Exception as exc: print("Unable to retrieve the server descriptors: %s" % exc) return bw_to_platform bw_to_platform = get_bw_to_platform() for platform in sorted(bw_to_platform.keys()): print("%s,%i" % (platform, bw_to_platform[platform])) - Tim 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Alternative Implementations of Tor
On Wed, Aug 17, 2016, at 11:01 AM, Alexander Færøy wrote: > 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, Not sure how widely implemented it is, but Orchid was a formally implemented version of Tor in Java, by the Toronto-based Subgraph group: https://subgraph.com/orchid/index.en.html It was, at one point, integrated into the Martus human rights documentation platform. The developers are likely on this list, or if not, easily reachable to ask for any lessons learned. +n ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Alternative Implementations of Tor
-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