#6 Updated by anonym almost 3 years ago
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 20
Currently Tails Server always starts the service before generating the onion address. Some services need the onion address for their configuration, so the order we do this (start the service, then generate the onion) won't working then. We need to either:
- Separate the onion address generation part into a step of its own that we run before starting the service.
- Introduce an option that starts the service after the onion address has been generated and published.
- Simply switch the order so the service always is starter after the onion has been published. I don't really see a reason why this isn't the case. Was there a reason for the current order?
# XXX: The connection string is user controlled, but because subprocess # handles escaping and quoting of arguments, this should still be secure.
The way you invoke
exec() will be used, not the shell, so there is no escaping and quoting to worry about. I.e. you can kill this comment.
sudo -u "$RUN_AS_USER" /usr/local/sbin/tails-server $@
You'll want to quote
$@ to retain the quoting of the parameters for the wrapped application.
@is_installed.setter def is_installed(self, value):
It feels odd to have a setter with the
is_-prefix. Not a blocker.
#16 Updated by intrigeri over 1 year ago
- Assignee changed from anonym to segfault
- QA Check set to Info Needed
At this point I think we should treat this review just like anything else => please ensure all the info for the review (pointers to the code, design, etc.) is on this ticket and the branch builds and works fine, and then I'll happily find you a reviewer :)