Re: [Tails-dev] Persistent torrc [Was: Tails Server: updated…

Delete this message

Reply to this message
Author: anonym
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] Persistent torrc [Was: Tails Server: updated plan and GSoC!]
segfault:
> anonym:
>> segfault:
>>> anonym:
>>>> segfault:
>>>>> anonym:
>>>> [...]
>>>> However, if possible, let's try an approach that doesn't rely on this,
>>>> ok? But I still guess you'd like to have this for the persistent
>>>> configuration/date for services (i.e. the non-Tails Server bits, e.g.
>>>> mumble-server's database and similar) as we've discussed before?
>>>
>>> ACK. I agree that the other options are better than making the torrc
>>> persistent. But I still need to make single configuration files
>>> persistent (e.g. /etc/mumble-server.ini).
>>
>> Ok, I created #11533 [0] to track this and pushed a branch with a first
>> attempt at patching live-boot. I haven't tested it, so please do! If it
>> doesn't work, perhaps the patch gives you enough context to fix it
>> yourself (it should be confined to `activate_custom_mounts()`)? :) But
>> please don't waste time on it -- this code is my own baby Frankenstein.
>>
>> [0] https://labs.riseup.net/code/issues/11533
>
> I tested it and it works! Thanks so much for implementing this :)


Wow, cool! Next step is to properly upstream it, then.

[...]
>>>>>> # add_onion
>>>>>>
>>>>>> By using stem to communicate with Tor over the control port/socket to
>>>>>> add the hidden services, just like onionshare does (which would be a
>>>>>> good source for inspiration, code-wise), you don't need any torrc
>>>>>> persistence just like in the previous approach. This is probably the
>>>>>> most "proper" solution of these three (and requires implementing less
>>>>>> logic on our side), and it might even be the easiest after you've
>>>>>> familiarized yourself with the API. This seems like the best option to me.
>>>>>
>>>>> Right. I didn't see this option either, but I think this would work too.
>>>>> I will try this :)
>>>>
>>>> It's ~new, which might explain it. Any way, I really hope this approach
>>>> works out since it looks the cleanest of those presented so far!
>>>
>>> I'm positive that this will work. But I think I will use the old
>>> create_hidden_service() [1] instead of the new
>>> create_ephemeral_hidden_service() [2], because the latter does not
>>> create a hidden service directory, which I need to make the service
>>> persistent. Also, only create_hidden_service() supports client
>>> authentication, which I want to support.
>>
>> Sounds great!
>
> Unfortunately, it seems like the create_hidden_service() won't work with
> the sandboxed Tor we use, because the sandbox prevents Tor to access the
> hidden service directory, which create_hidden_service() needs to access.
> Micah Lee ran into the same problem with OnionShare [1] (He fixed it by
> using create_ephemeral_hidden_service(), but I need the hidden service
> directory for persistence, so I think this is no option for me).
>
> [1] https://github.com/micahflee/onionshare/issues/179


That's unfortunate. :/ I was gonna suggest to try SETCONF (via whatever
interface stem has for it) instead, but I guess it's affected by the
same issue. Otherwise, maintaining it with SETCONF and RESETCONF (and
SAVECONF so restarting tor during the same session doesn't drop the
HSes) might be easier and prettier than the regex soup I imagine for...

> For now I'm back to the "# Maintain HiddenService{Dir,Port} lines in
> /etc/tor/torrc" option, which is working fine.


... this approach. Still, it's good enough, so I think you should just
stick with this. Just try to abstract these parts in the code so that it
will be easy to change implementation to add_onion in the future.

Cheers!