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

Development
21

Ok, great. I am not insisting on this approach, though. Just having best practices, clean code, easy re-usability and such in mind. Makes the code more readable and Whonix overall more logical, understandable, extensible, auditable and so forth. I mean, in past there were no separate Whonix packages, all files were in whonix_(gateway|workstation|shared) folder. Technically it was not the slightest bit less safe, but difficult to get into for newcomers, and now much more grasp and work on Whonix.[/quote]
Whonix splitting in separate packages was a great move, from my point of view!

I am trying to write as logical and readable code as possible. Now, we should be careful with tools such as pylint. For example, whonix_repository_wizard.py scores an honorable 3.31/10 against 0.41/10 for launcher.py in trorbrowser-launcher. The latter is packaged in Debian. The tool might be useful to discover some obscure issues (I have a couple of them), but we should not try to stick to all the recommendations.

For [re]readability, adding docstrings once the scripts are deemed usable should help. As for re-usability, concerning guimessages especially, I fully agree after writing the wizards that it’s a lot more logical to have a dedicated .yaml file per package. A single file would quickly become hardly manageable.

Pushed three packages.
https://github.com/troubadoour/guimessages

whonix-repository-wizard is in a new repository, the original one was deleted.

whonix-setup-wizard is only for Workstation so far. Not knowing yet if there will be a second package for Gateway, depending on the complexity. May be an extra module, or a wizard Help button to avoid too many pages.

There are some minor issues left, but you can review (all three packages have to be installed). I think the wizard approach is becoming neat.

22

Nevermind pylint. If no one obeys it, we don’t have to do either. There is no need to become slave of some tool.

There are some issues with the guimessages package. It contains some binary files (.pyc) and we ought not to mix them into the source packages. When removing them, for testing, if you have a backup, please try “sudo make uninstall” so the pyc files are wiped from your disk. I guess the pyc files are generated on the fly or during installation by debian maintainer scripts? I am also not sure about the name. As far I observed, python libs are called python-libname, i.e. python-guimessage would be better. I am not sure about singular vs plural.

Just saw the other packages also contain .pyc files.

There are quite some packaging instructions in Debian wiki.

https://wiki.debian.org/Python/Packaging
https://wiki.debian.org/Python/LibraryStyleGuide
https://wiki.debian.org/Python/AppStyleGuide
https://www.debian.org/doc/packaging-manuals/python-policy/
https://wiki.debian.org/Python#Debian_Python_Policy_for_Python_developers

If that looks overwhelming, I guess it looks worse than it is, If you wish I can figure out the packaging part.

23
There are some issues with the guimessages package. It contains some binary files [i](.pyc)[/i] and we ought not to mix them into the source packages. When removing them, for testing, if you have a backup, please try "sudo make uninstall" so the pyc files are wiped from your disk. I guess the pyc files are generated on the fly or during installation by debian maintainer scripts?
My mistake. The [i].pyc[/i] (bytecode) are not required in the source package. They are generated when the modules are imported.

[Basically, at first import, the module source is searched in the python path and “byte-compiled”. If the bytecode .pyc exists, those two steps are skipped before possible execution. That improves both loading and execution speed. Python is not a purely interpreted language. There is a lot of literature on stackexchange about that.]

The binary are removed.
https://github.com/troubadoour/guimessages/commit/833ea10cdd62b7ba79155015a49f543e54943e92

I hope that takes care of the packaging issue and that we can carry on with Debian standard packages (files in their path).

I am also not sure about the name. As far I observed, python libs are called python-libname, i.e. python-guimessage would be better. I am not sure about singular vs plural.
I cannot see any packages with a "python-" prefix in /usr/lib//python2.7/dist-packages (wheezy or jessie). Would have to define exactly what a library is, though. May be we should modify the text in debian/control description, from "guimessages python library" to "guimessages python utility".
24

Looking it it soon.

I don’t mean the folder path. I mean the package name. The name of the folder and github link.

(You know this already… (Telling for others.) For Whonix build at the moment, package folder name = package name.)

The python lib dateutil is packages with package name python-dateutil:
https://packages.debian.org/wheezy/python-dateutil

I.e. https://github.com/troubadoour/python-guimessage might be better.

I think this is the standard.

25

[quote=“Patrick, post:24, topic:650”]Looking it it soon.

I don’t mean the folder path. I mean the package name. The name of the folder and github link.

(You know this already… (Telling for others.) For Whonix build at the moment, package folder name = package name.)

The python lib dateutil is packages with package name python-dateutil:
https://packages.debian.org/wheezy/python-dateutil

I.e. https://github.com/troubadoour/python-guimessage might be better.

I think this is the standard.[/quote]
Yes, some misunderstanding. Will rename the package on the next push.

26

whonix-repository-wizard:
I think the path whonix-repository-wizard/usr/lib/python2.7/dist-packages/whonix-repository-wizard would be more expectable than whonix-repository-wizard/usr/lib/python2.7/dist-packages/whonixrepository? Maybe that works?

27

whonix-repository-wizard:

  • lintian --info --display-info --fail-on-warnings
    W: whonix-repository-wizard: new-package-should-close-itp-bug
    Can be fixed with “make deb-chl-bumpup”; git diff; git commit.
  • Will test more later.
28

Overall really nice! :slight_smile:

guimessages package build doesn’t work yet, but it’s easy to fix. I can do that once the package has been renamed.

29

[quote=“Patrick, post:27, topic:650”]whonix-repository-wizard:

- https://github.com/troubadoour/whonix-repository-wizard/blob/master/usr/lib/python2.7/dist-packages/whonixrepository/__init__.py is currently completely empty. Is that the usual way?
Yes. One can put some initializing code there, or license text, but it can be empty.

[quote=“Patrick, post:24, topic:650”]The python lib dateutil is packages with package name python-dateutil:
https://packages.debian.org/wheezy/python-dateutil

I.e. https://github.com/troubadoour/python-guimessage might be better.

I think this is the standard.[/quote]
Done. GitHub - troubadoour/python-guimessages: Translatable GUI Messages - python library
The last commit has added a button option (for the bash gui messages, it might be yes-no) and a position option (possibility to show the message box in the top left corner.)

[quote=“Patrick, post:26, topic:650”]whonix-repository-wizard:
I think the path whonix-repository-wizard/usr/lib/python2.7/dist-packages/whonix-repository-wizard would be more expectable than whonix-repository-wizard/usr/lib/python2.7/dist-packages/whonixrepository? Maybe that works?[/quote]
New paths, with undescores, to comply with Python standard:

whonix-repository-wizard/usr/lib/python2.7/dist-packages/whonix_repository_wizard

There is an commit in the .yaml file, for the new message box options.

whonix-repository-wizard/usr/lib/python2.7/dist-packages/whonix_setup_wizard

Commit cleanup. · troubadoour/whonix-setup-wizard@0c6cf83 · GitHub includes many changes listed in the commit message. The main one is the addition of the Help button, which should be 'helpful for the “real” gateway connection wizard.

Let us say that we have a good template to start with and that from there, we could have some option on the way to design it.

Could you let me know when you have merged and made the (most likely) necessary corrections for packaging and small typos? That would prevent pushing too many changes in a single commit after I base my git origin on yours.

30

In process. Done very soon.

Maybe I misunderstood. Changing the git remotes is actually quite simple. Example.

reponame=python-guimessage git remote rm adre git remote rm troubadoour git remote rm origin git remote add adre git@github.com:adrelanos/$reponame.git git remote add troubadoour git@github.com:troubadoour/$reponame.git git remote add origin git@github.com:Whonix/$reponame.git
31

Packaging fixes done:

  • whonix-repository-wizard
  • python-guimessages

(No more huge changes planned.)

In process:

  • whonix-setup-wizard
32

Can you add license headers please?

  • guymessage.py
  • translations.py
33

Can you wait for the next push. There is an issue with the files in /usr/bin.

34

Sorry. Too late. Missed this before. But our commits are unlikely to conflict anyhow. Git manages simultaneous commits quite well. As long we’re not working on the same files, there is zero risk. We could even work on the same file if we don’t simultaneously change the same lines.

Done with packaging fixes for whonix-setup-wizard.

35

whonix-setup-wizard. Merged your branch + commit 82b7ed4e: path corrections.

36

Yes, we’re on the same page now. (At same git head at the moment.) So far so good. :slight_smile:

37

All three repositories should be OK.

38

(Small typo above. [Missing whonix-setup-wizard.])

So what’s next?

We need to remove these files from whonixsetup.

And adapt and add them to whonix-setup-wizard.

I don’t mind at all if you or me. Can do when you’re feeling ready.

39

[quote=“Patrick, post:32, topic:650”]Can you add license headers please?

  • guymessage.py
  • translations.py[/quote]
    Do you mean something like
## Copyright (C) 2014 troubadour <trobador@riseup.net>
## Copyright (C) 2014 Patrick Schleizer <adrelanos@riseup.net>
## See the file COPYING for copying conditions.

?

40

Yes.