[graphical gui] Whonix Setup Wizard / Anon Connection Wizard - Technical Discussion

Development
#242

Thank you so much for your suggestion! I will let you know the result very soon!

1 Like
#243

torrc.d coming.

2 Likes
torrc.d is comming
#244

Thank you for informing me this, Patrick! I have read all the discussion in the tickets.

I have not looked at the latest implementation of torrc.d yet, so I assume what has been implemented is the same as what Hans proposed:

Weasel and I (aka Hans) sketched out how we would use it in the Debian package, closely following the Apache pattern but with naming that is more appropriate in Tor:

/etc/tor/torrc::
%include /etc/tor/services-enabled/.torrc
%include /etc/tor/instances-enabled/.torrc

These dirs are present for the actual snippet files:
/etc/tor/services-available
/etc/tor/instances-available

These dirs include relative symlinks to *-available:
/etc/tor/services-enabled
/etc/tor/instances-enabled

For example:
/etc/tor/services-enabled/sparkleshare.torrc → …/services-available/sparkleshare.torrc

The sparkleshare package would include:

/etc/tor/services-available/sparkleshare.torrc

The davical package would include:

/etc/tor/services-available/davical.torrc

Please correct me if I am wrong, the /etc/tor/services-available/anon-connection-wizard.torrc and /etc/tor/services-instances/anon-connection-wizard.torrc are the two files that are expected to be generated by the anon-connection-wizard.

Still, I am not sure how the Tor will actually handle the priorities of and potential conflicts between different .torrc files.

It seems that the priority of anon-connection-wizard.torrc should be lower than /etc/tor/torrc so that we can still suggest users who want to configure the Tor manually editing the /etc/tor/torrc.

Or we can suggest users who want to configure the Tor manually editing a .torrc file that has very high priority instead.

1 Like
#245

I don’t know if we still need the edit marker approach for a transitional period. Depends on when the Tor version supporting that feature will enter deb.torproject.org stretch repository. Could you find that out please?

I don’t know that. Could you please ask in that ticket?

1 Like
#246

Sure thing! Done!

I don’t know how long it will take to get an answer so I will work on other implementation first (like UI implementation based on Linda’s paper).

Also, the edit marker approach seems not to be a large amount of work (just a file IO), so it is fine for me to take it as a transitional approach if we still do not get the response back. :slight_smile:

1 Like
#247

Could you create a Whonix phabricator please?

Please check this out.

https://phabricator.whonix.org/T684

Would you like to write a Whonix blog post announcing your GSoC anon-connection-wizard project? Just very briefly to announce it with references. You could reuse some other announcement text used elsewhere already.

1 Like
#248

Please check out ⚓ T676 fix obfs4proxy AppArmor issue in Whonix 14 as well.

1 Like
#249

@iry Please keep me updated on your progress! (So I can provide feedback on writing & usability).

1 Like
#250

A small discussion related to the anon-connection-wizard happened at #tor-dev on May 30.

The benefits of adopting anon-connection-wizard as new generation of the Tor launcher is better compatibility with future sandboxing wirk.

Full chat log can be seen here.

18:32:07 A related issue is something I was discussing with Yawning a couple of days ago, as a result of his email thread on tbb-dev.
18:32:31 He’s wondering how the tor-launcher automation fits in with sandboxing.
18:32:53 That is, his sandbox approach probably requires a separate-process tor-launcher.
18:33:51 So the question is whether the new UI should be developed in the same JS extension or as a new separate program using QT or similar.
18:34:57 Or possibly iry’s python-based project would be a way to do it.
18:35:54 Anyway I don’t have an opinion, but it seems like a valid question.
18:36:26 hm. so the ui for tor launcher won’t be radically different with the automation
18:36:46 there will be some dialogs moved/adapted but that’s probably it
18:37:29 I think sandboxing may drive us to a different (non XUL) solution but we do not understand all of the requirements yet (basically what GeKo said in that tbb-dev email thread).
18:37:32 And where will the code for the automation itself live? Inside tor-launcher JS or in tor?
18:37:38 there will be more effort needed under the hood to get the automation part going properly
18:38:56 i think the main part will live in tor-launcher for the time being
18:39:32 i doubt we will have the pieces for the new archtiecture ready to start with that one and get the deliverables done until later this year
18:39:58 oh, “until” is probably wwrong
18:40:00 *wrong
18:40:18 what i meant was we have deliverables to do and the automation is part of those
18:40:29 and we have time to november
18:40:48 If we also try to re-write in QT we will probably fail to deliver on time (that’s my guess anyway).
18:40:55 (nit that I like QT)
18:41:00 s/nit/not/
18:41:15 yeah, that’s what i meant
18:41:30 Right. I think Yawning’s concern was about duplicated effort. And also maybe delaying adoption of the sandbox.
18:42:03 well, yes, but this kind of duplicated effort can’t be avoided it seems to me, alas
18:42:20 Because of the deliverables schedule?
18:42:29 yes
18:42:52 the adoption of the sandbox is probably not delayed due to the automation effort
18:43:11 i mean we don’t have anybody working on the sandboxing stuff right now
18:43:30 nor do we have the money for that at the moment i think
18:43:56 so what we need is a plan first, then break that one down to pieces
18:44:08 we can use to apply for money with
18:44:28 at least that’s how i see it currently
18:44:42 I think we should try to find time to work on the plan (and then ask for money or shift priorities or whatever). I think that is what everyone is saying.

1 Like
#251

The tbb team has already had a work around solution to the drop of support of XUL/XPCOM-based extensions. So anon-connection-wizard is not an essential/competitive candidate in that case.

18:29:19 and it seems mozilla will drop the support of the Tor launcher
18:29:35 so I am wondering what’s the plan for TBB team?
18:29:53 iry: Do you mean because of WebExtensions?
18:30:07 yes
18:30:26 we can work around that for the time being
18:30:49 let me find you the comment and the ticket
18:31:25 #17248, comment 16

1 Like
#252

Sure! It is a great honor to me to post on the Whonix blog!

1 Like
#253

Hi Patrick! I have done two pull requests related to the issue in the ticket.

1 Like
#254

Hi @JasonJAyalaP ! Thank you so much for offering me feedback!

This is my fork of anon-connection-wizard:
GitHub - irykoon/anon-connection-wizard: anon-connection-wizard is a python-based application that help users in different Internet environment connect to the Tor network.

Currently, I has been working on the “edit mark approach”. And hopefully I can push the commit to my repository in 24h.

Looking forward to further discussion with you!

1 Like
#255

I joined the #tor-dev irc meeting for tbb today, the following is some log related to anon-connection-wizard:

arthredelstein said:

<arthuredelstein> We're interested in sandboxing on Linux, Mac, and Windows.
<arthuredelstein> And one of the things we might want is a new tor-launcher in a separate process.
<arthuredelstein> So if your python implementation is going to fit the bill, it would need to work on all 3 platforms
<arthuredelstein> (Sorry if I'm just repeating what you already know!)
<arthuredelstein> And, if you're interested in getting feedback on it, I'd be happy to take a look at it.
<arthuredelstein> (I'm a Tor Browser dev)

As @Patrick said, anon-connection-wizard should be general purpose that can run in many platform. Currently, it is Whonix support only. It even doesn’t work in debian, since it lack the guimessage module and tor_status.py module.

I am lack of knowledge on how to make the dependency available in debian or other linux distribution? Do we need to submit it to the upstream or can we include it in our own debian package? A better case is someone who is interested in anon-connection-wizard can test it by doing a git clone and installing some dependencies available in debian repository.

1 Like
#256

Link to tor launcher automation irc meeting on 06/02/2017:
http://meetbot.debian.net/tor-project/2017/tor-project.2017-06-02-18.04.log.html

#257

https://github.com/Whonix/whonix-setup-wizard/blob/master/usr/lib/python3/dist-packages/whonix_setup_wizard/tor_status.py - just move it to anon-connection-wizard. It won’t be required anymore in whonix-setup-wizard once anon-connection-wizard replaces that functionality.

guimessage - It does have its own package already. https://github.com/Whonix/python-guimessages

True. That would simplify some things. Curenty it has two dependencies not in Debian:

To run anon-connection-wizard on Debian, one has to install these two dependencies first.

guimessages could be removed by figuring out another way to show messages and to provide a mechanism to later get anon-connection-wizard translated.

genmkfile is used for packaging, but could be removed by moving to imo more complicated packaging using the python setup framework. If necessary, do it. It would be a pity. All Whonix packages are currently packages using genmkfile. Changing this would require changes to the build system. I would hope to get genmkfile uploaded to Debian one day.

Perhaps you can find a DD (debian developer) that would be willing to upload these dependencies to Debian? These packages are lintian --pedenatic clean, stable for a long time and Whonix, and generally shouldn’t create a lot work to maintain in Debian, I hope.

(Whenever I say something in public like in Whonix forums you can of course quote me on that.)

1 Like
#258
  • implemented edit mark approach
  • minor GUI changes
  • added a help button on proxy page
  • added an option on censorship circumvention tools options page
#259

This may not be a good idea since more options lead to more confusions. I can remove it if it’s considered necessary.

1 Like
#260

It would be better if anon-connection-wizard can remember user’s last options and adjust the GUI according to it. The problem is how should we implement this?

  • Solution 1:
    parse the lines between the two edit marks in /etc/tor/torrc, and adjust it to GUI when starting the anon-connection-wizard
  1. Solution 2:
    output a user-last-option.config files every time anon-connection-wizard is used. And parse that file when starting the anon-connection-wizard

I prefer the second solution, since sometimes same output in /etc/torc/torrc may caused by different user-options in anon-connection-wizard.

1 Like
#261

TODO:

Tor launcher will detect if the /etc/tor/torrc has the same configuration as the /etc/tor/torrc.orig. If not, user will be asked if they want to abolish the previous customized setting and connect to the Tor network with the setting in /etc/tor/torrc.orig.

Currently, anon-connection-wizard will override the /etc/tor/torrc without asking, which is not good.

It should be implemented.

1 Like