Re: [tor-dev] Potential projects for SponsorR (Hidden Services)

[David Stainton <dstainton415@xxxxxxxxx>]

correction... I meant #11291.


On Wed, Oct 29, 2014 at 1:04 AM, David Stainton <dstainton415@xxxxxxxxx> wrote:
> Any Twisted application written in a network endpoint agnostic manner
> may be used with the txtorcon hidden service endpoint...
> For instance serving files from a Tor hidden service can be done with
> Meejah's one-liner:
> pip install txtorcon && twistd -n web --port "onion:80" --path ~/public_html
>
> However I see the current txtorcon design (without 12911 resolved) as
> lacking security isolation since tor is launched as the same user as
> the python process. Using the control port to create hidden services
> seems like the obviously better way to do this.
>
> Currently Tahoe-LAFS is used with torsocks and manually configured Tor
> hidden services in order to hide the the identity of the tahoe client
> and server operators. We'd like for Tahoe-LAFS to have native Tor
> integration... Using the txtorcon endpoint would greatly simplify
> deployment for Tahoe-LAFS storage operators wishing to hide their
> identity/location.
>
>
> David
>
> On Tue, Oct 28, 2014 at 10:40 PM, meejah <meejah@xxxxxxxxx> wrote:
>> Nick Mathewson <nickm@xxxxxxxxxxxxxx> writes:
>>> On Mon, Oct 20, 2014 at 9:37 AM, George Kadianakis <desnacked@xxxxxxxxxx> wrote:
>>
>>>> this is an attempt to collect tasks that should be done for
>>>> SponsorR. You can find the SponsorR page here:
>>>> https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR
>>
>> I see that #11291 is not on that list. I think it should be.
>>
>>> * Get somebody who wants to access hidden services over the controller
>>> API to explain what they want to build.  Then design an API as needed
>>> to support it.
>>
>> Currently, at least the way Tor is deployed on Debian, you cannot add a
>> new hidden-service to a running Tor if you're "just" in the right group
>> (in this case, debian-tor). #11291 would fix this, and is pretty close;
>> dawuud has a branch that's got more utests etc (*not* asking for more
>> review yet ;) )
>>
>>> * Look at what somebody might want to do with hidden services via the
>>> controller API; then design an API to expose that.
>>
>> One issue with hidden services and the overall controller API, is that
>> they are the only "special" thing that has multi-line configuration
>> where order matters. So controllers have to do "non-trivial" things to
>> make hidden serivces "go".
>>
>> Unfortunately, I don't have a concrete suggestion here, beyond "take a
>> ground-up look at the controller API", which I'm guessing is
>> out-of-scope? Basically, something more structured might make sense?
>> *However* since hidden services are the only thing that actually makes
>> order important (as far as I recall), perhaps re-thinking those alone
>> within the existing framework would be much less disruptive *and*
>> simplify controller logic (i.e. eliminate the "order is important" bit).
>>
>> The only concrete use-case I can offer is carml's "pastebin" command,
>> which would like to add and delete hidden services from a running
>> Tor. Currently, it always launches a new Tor instance (so "add" is
>> launch, and "delete" is kill). Perhaps this is the best way anway,
>> separation-wise...?
>>
>> I can imagine that adding the equivalent of add/delete for
>> authorize-client lines would be a Good Thing, too.
>>
>> Just brainstorming here, but could both the above be accomplished with
>> some sort of "change configuration" command? That is, instead of forcing
>> controllers to remember enough to make a SETCONF work, the opportunity
>> to add or delete things exists? (And perhaps only for hidden services,
>> since they're the only "special" things currently anyway?) This probably
>> implies an ID for each hidden service...
>>
>> This also would map fairly well to most UIs, which then just have to
>> remember what the user did (e.g. "clicked delete on the 3rd line, then
>> clicked add with options X, Y, and Z").
>>
>> --
>> meejah
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev