No, I didn’t see it that way. Interesting! I always thought people are quick to dismiss. When they see “whonix-something” they immediately dismiss as “for Whonix - not for me (Debian)”. I will leave the naming to you. Rather minor point for me.
Yes.
Ordering of tests: perhaps quick and less likely to fail tests go first? Tests could be numbered.
somenumber_name-of-test
Numbers shouldn’t be direct decrescendos. I.e. not 1, 2, 3. Better 100_somehing. 200_something. If we later add something there will be enough “space” to insert numbers without having to rename existing files.
Both CLI and GUI tests. Did you find a list of tests that Tails is running?
Some ideas (higher → higher priority. Very unfixed priorities.):
- Start Tor Browser, visit some websites, visit onion websites, close Tor Browser. Did it properly terminate with exit code 0 or some other? Did the process terminate or is it lingering?
- change password
- run upgrades
- reboot
- run
whonixcheck --verbose --leak-tests --gui --cli, check if there is a whonixcheck CLI output, if there is a GUI window popup, if that is dismissable using OK or close button - other activities users are doing such as start dolphin, browse some files, open a file in a text editor, type something, save file.
- edit file with root rights
- other common activities which come to your mind?
- screen resolution (vs virtualbox guest addition bugs)
- copy/paste text from host to vm and back
- shared folder tests
- boot into recovery mode
- normal boot and switch to virtual console
- switch back to graphical console
- set up serial console
sudo apt install serial-console-enable sudo apt install debug-misc- lower VM RAM to 256 MB
- RAM Adjusted Desktop Starter (rads)
- login in console
- enough for now or should I come up with more?
The tests ideally would be aware in which boot mode (normal, recovery, future others) it would boot and which virtual terminal it would run the test in. Maybe that could be an abstraction.
Some tests are virtualizer specific. A lot tests will function in Qubes-Whonix hopefully (such as Tor Browser tests) but shared folder tests are different for VBox / KVM.
If it succeeded: maybe nothing (except when --verbose list all tests that succeeded).
Otherwise: if it failed: perhaps just write what failed, link to the test’s source file and perhaps (low priority) a screenshot (or video?)
This is a good resource. Yes, v3 is latest.
It links to How to Use GNU Licenses for Your Own Software - GNU Project - Free Software Foundation
either version 3 of the License, or (at your option) any later version.
is preferred by me (in case there are license upgrades) but also v3 only is OK. I.e. both GPL-3 or GPL-3+ is OK.
No. It’s just tests. Nothing sensitive running in the cloud. For higher security, everything can be run locally too.
Yes.
That is a tough question.
In https://github.com/Whonix/whonix-developer-meta-files/blob/master/usr/bin/virtualbox-test-vm I experimented with that for VirtualBox and used
vboxmanage guestcontrol. That is rather “clumsy”. If I remember right it can run commands. And even receive output by commands? But stdin isn’t connected.
Serial console perhaps?
(Though, serial-console-enable package won’t be installed by default in future due to VirtualBox issues.)
google “how to execute command inside VM”? sort of?
Error - KVM any useful?
Modify KVM to use its VNC implementation if any?
VBox VNC requires proprietary VBox extension pack, not good.
Or we need to install an SSH server inside the VM? Passwordless SSH?
It’s possible:
^ Long time not tested. Can help with this if this will be your choice. Hopefully SSH will be reliable enough for this.
Also currently experimenting with x2go (VNC but faster) which can be run over (local) LAN and SSH too.
How does Tails do this? What is the usual way to do this?
If that works, great!
Also great!
Yes, priority.
(Since this will be easily installable (or even installed by default), and also re-usable on the host.)
Outside VM talking to inside-VM support is lower priority.
CI is lowest priority.