[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

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

Yes, seen that. A question: where do we keep the development discussion? Here in “Whonix Setup Wizard” or in Phabricator “Whonix Tor Controller”?

I don’t have a strong opinion about that. I don’t mind either way.

In this case, I was just cross posting it. To notify the public that something is going on. I thought if someone cares strongly enough for it, they’d join phabricator.

Forum:

  • more people reading
  • more people sharing thoughts
  • threads fall down getting ignored
  • threads get long
  • stuff can be forgotten if no ticket exists

Phabricator:

  • nothing gets forgotten if properly tagged (by release milestone for next release or just by application “for some day some contribution”
  • not so much feedback
  • less wasting time on debating to no avail (aka “I am an expert user, I need the bikeshed to be blue, I need this extra debug info” and so forth but not contributing any actual research or code)

In an ideal world, everything would share the same data base and just provide different interfaces into it. (I wrote a bit about that dream here https://www.whonix.org/blog/future-goals-for-whonixs-website.)

In this case, after talking to an actual UI designer (Brennan Novak), I was quite sure that it’s best to re-implement exactly how tor-launcher is looking. Therefore continued on phabricator. Better than having all the advanced users try to reinvent something that mortals understand.

Your master branch is looking quite strange.

changelog.upstream | 24 ++++++++++++++++++++++++ debian/changelog | 6 ++++++ usr/share/translations/whonixcheck_apt_repository.yaml | 16 ---------------- usr/share/translations/whonixcheck_control_port_filter.yaml | 9 --------- usr/share/translations/whonixcheck_hostname.yaml | 31 ------------------------------- 5 files changed, 30 insertions(+), 56 deletions(-)

[hr]

Please reset. I am not the biggest git crack, but the following is how I’d do it. Should work.

Unstaged changes after reset: M changelog.upstream M debian/changelog
Removing usr/share/translations/whonixcheck_apt_repository.yaml Removing usr/share/translations/whonixcheck_control_port_filter.yaml Removing usr/share/translations/whonixcheck_hostname.yaml
Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory)
    modified:   changelog.upstream
    modified:   debian/changelog

no changes added to commit (use “git add” and/or “git commit -a”)

HEAD is now at 47074cd bumped changelog version

Need to git push force.

Alternatively I could merge your changes and revert.

Please rebase tor-launcher-clone on origin/master. This removes superfluous content from the “git diff --stat”.

(Have a backup [git branch] in case git messes up something.)

There wlll be more leftovers.

git diff --stat master etc/apparmor.d/local/usr.bin.obfsproxy | 4 + etc/bridges/default.json | 26 +++++ usr/share/pyshared/whonix_setup_wizard/whonix_setup_wizard.py | 699 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------- usr/share/translations/whonix_setup.yaml | 8 +- usr/share/translations/whonixcheck_apt_repository.yaml | 16 +++ usr/share/translations/whonixcheck_control_port_filter.yaml | 9 ++ usr/share/translations/whonixcheck_hostname.yaml | 31 +++++

Not sure how to best get rid of them. Perhaps just delete and commit. Or “git log filename”, then revert.

We’re missing.

(Because ‘whonix-setup-wizard repository’ uses whonix_repository command line tool.)

The diff issue in masters should be solved.

I have been working in my branch without bothering about master :-[. In github, the default branch was set to tor-launcher-clone, and I cloned from there after installing Qubes…

Switched the branch to master in github, cloned again, fetched Whonix (there was a big diff), merged and pushed.

Could you recheck?

There are still extraneous files from the previous experiment in master branch.

git diff --stat troubadoour/master usr/share/translations/whonixcheck_apt_repository.yaml | 16 ---------------- usr/share/translations/whonixcheck_control_port_filter.yaml | 9 --------- usr/share/translations/whonixcheck_hostname.yaml | 31 ------------------------------- 3 files changed, 56 deletions(-)

Branch tor-launcher-clone still has the problems.

Made a bunch of commits in branch tor-launcher.

I removed the local repository, cloned whonix-setup-wizard from Whonix, merged tor-launcher in master and pushed. The default branch in https://github.com/troubadoour/whonix-setup-wizard is now set to master.

git diff --stat origin/master shows the changes I have made, and apparently nothing else.

git diff -C --stat origin/master troubadoour/master

 usr/{share/pyshared => lib/python2.7/dist-packages}/whonix_setup_wizard/__init__.py            |   0
 usr/{share/pyshared => lib/python2.7/dist-packages}/whonix_setup_wizard/whonix_setup_wizard.py | 402 ++++++++++-------------------------------------------------------------------
 usr/share/pyshared/whonix_setup_wizard/tor_status.py                                           |  87 -----------------
 usr/share/translations/whonix_setup.yaml                                                       |   8 +-
 4 files changed, 52 insertions(+), 445 deletions(-)

Does this look as expected?

Yes, From https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html:

When binary packages ship identical source code for multiple Python versions, for instance /usr/lib/python2.6/dist-packages/foo.py and /usr/lib/python2.5/site-packages/foo.py, these should point to a common file. Version specific directories for identical source code are not required for python3 and must not be used for this. Since python2.7 is the last python2 version and the only supported version in wheezy and later releases, a common location to share arch-independent files across Python versions is no longer needed. Historically the location for this was /usr/share/pyshared. For python2.7, use of /usr/lib/python2.7/dist-packages is sufficient. For python3, a special location is not required, use /usr/lib/python3/dist-packages

This approach makes it a lot simpler. We are ending with .done files only.

  • whonixsetup.done in KVM-VirtualBox only.
  • whonix-connection.done
    created after the wizards have successfully completed. No status files from the package.

Merged.

Please make that sudo anon-connection-wizard -> kdesudo.

Sudo on graphical application leads to issues. Or perhaps it’s time to reconsider this. Fedora apparently has sorted this out in meanwhile since I’ve read in Fedora instructions to use sudo on gui applications… Perhaps also Debian sorted out this issue also?

Done.

For information, “sudo graphic_app” works in Debian in a Qubes VM. It does not in plain Debian jessie nor in VirtualBox.

And in Qubes, kdesudo pops

kdesudo(13007) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display “:0”

Did not investigate that.

It (sudo graphical) works initially, but can lead to confusing issues later one.

Merged.

((( Btw, Qubes does not need locale_settings, because in Qubes that is all up to dom0 and passed to any VM. A great solution. )))

There were some commits before (and after) this one. The proposal for Whonix 13


is fully implemented.

whonix-setup-wizard setup is forbidden in Qubes-Whonix, both from whonixsetup-check-for-start, and in the wizard in case someone tries kdesudo whonix-setup-wizard setup

The .skip files are no longer required.
Only whonixsetup.done is left for Non-Qubes-Whonix workstation.

The finish page is deprecated.

TPO has changed the default bridges transport to obfs4. ( https://www.whonix.org/wiki/Warning ) So we should do that also.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]