[tor-dev] Joining Tor Project's software infrastructure

[Jesse V]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 691 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161004/1a031ef7/attachment.sig>