On 10/04/2016 03:54 PM, George Kadianakis wrote: > Hello Jesse, > > glad to hear you are still working on the OnioNS project, and happy to > hear that the paper got accepted in PoPETS. We have great plans for > hidden service naming layers, and it's great to see more people working > on this topic. Thanks for updating the wiki as well. My pleasure. I'm looking forward to see what you guys have in store. > FWIW, I feel that using Github (or any other third-party git) for code > hosting and ticket tracking is fine for now. If you still want a > personal repository on gitweb, check out these docs: > https://help.torproject.org/tsa/ Thanks, I'll look into it. > I'm also not sure what's the exact policy on gitian and > deb.torproject.org, and whether third-party applications (like OnioNS) > can be placed there. That's fine. It's not a big deal, but I would eventually like to have reproducible builds on the official system. For now I have a few ideas for reproducibility, so it's not a priority at present. > Personally, I'm hesitant of giving the impression that Tor officially > supports any of the proposed naming systems so early. I'd feel more > confident about them after they get deployed and used by the wider > community. I can understand that. How did other software, such as obfs4, get supported? I'm sure an early version of it was buggy and vulnerable, but at some point it was integrated in to the system. I'm just wondering what the requirements are and what the timeline looks like. I was hoping to get started with the process. > On this topic, what's your deployment strategy? If you really really > need Tor project infrastructure to achieve it, let's talk about it. I don't need Tor's build system, no. I can probably deploy just fine on third-party systems (Github, Launchpad, etc) but it seems very disjointed. I was hoping to get started on the process in moving towards *.torproject.org so that it's easier to deploy. Everyone is already familiar with the process and they have deb.torproject.org in their sources. At present, I am envisioning a deployment strategy like this: 1) I will finish all the primary components and ensure that they all mesh together nicely. This involves a lot of testing and changes on my end. This is currently where I am. 2) I will deploy an alpha build to the approximately dozen volunteers that have expressed interest so far. I will distribute RPMs, DEBs, and a build of the Tor Browser that includes my libraries. I will help run the servers and they can test out the components, particularly the onion service and client software. 3) Fix bugs and deploy into beta. 4) I'll post on tor-dev or tor-relays asking for volunteers to help test the server end. This is part where the system starts to become decentralized. 5) Fix bugs, grow based on interest, add more documentation, expand the project page, etc. 6) When everything seems stable and feature-complete, announce it so that everyone can test out the stable builds. > BTW, monitor this list, there will soon be a proposal specifying a Tor > API for naming systems like OnioNS, similar to the one we have for > pluggable transports. That will be neat. At present the "intercept circuit requests, auto-attach or rewrite based on TLD" approach seems pretty reliable, but I will look forward to seeing what you guys come up with. -- Jesse
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev