For now, I think it’s fine. Maybe it could be renamed to whonix-qemu or something? As that’s what all the files in there have in common. I do actually think a whole new package for two XML files (i.e. the UTM plist files) is overkill anyway.
I’ve never used it, does it have the same concept of a Gateway and Workstation? I can take a look at it a bit later, but for now I’ll prioritise getting the Mac UTM setup working well and updated on the relevant wikis.
Yes, as far as I can tell there is no way to currently package them together. I know it’s not as simple as Virtualbox then, but for anyone using UTM that’s what they would be used to. I don’t think it’s too bad.
It looks relatively fine. One question on it: is this run as part of the overall build script or something which is run manually when you want to package a new release?
Thanks for all the feedback as always!
Thank you! Hm, on my existing Intel Mac with Whonix clipboard sharing works. Maybe I enabled that afterwards? I know it’s a possible leak, so I will default it to disabled for our repo then (will issue a PR for that). Will also do the other cleanups you mentioned, thanks for the review!
Clipboard sharing: Whonix VirtualBox has it (usability). Whonix KVM doesn’t have it (security). We had a lengthy forum discussion about it, I swear, but I cannot find it anymore. Maintainer specific call.
It’s separately wrong. (With same parameters as whonix_build.)
Cannot be run during whonix_build since it requires all VMs to be already build.
(Unless some assumption was added such as “if workstation was build, consider we’re done and start prepare_release”. Or if there was some whonix_build_multi script which existed before but just made the build process / script look more complex than it is.) Best design I could think off. Unless someone has a better idea how to structure things.
Right. I ever considered having the UTM files in Whonix/Whonix (same as build script) but that also seemed non-ideal.
OK.
Worth combining both folders into one archive (KVM uses .xz to support sparse images) in prepare_release script? (Similar to Whonix KVM.) Then also the usual download table could be shared among VBox, KVM, UTM.
Thanks for all the hard work that’s gone into this. I can confirm that I’ve got Whonix working on M1 locally after following these instructions, great work from all involved!
Got the downloader installed. When I launch it I get an error that tor is not fully bootstrapped possibly due to having no internet connection.
When I boot up the Gateway VM for the first time I get an error that greater onion service is not running, but if I relaunch everything I can just browse and install packages like normal. Maybe this has something to do with it.
These are general issues. Unrelated to tb-updater. These issues might be fixed in the testers repository if you enable that and upgrade all packages in gateway and workstation, the issues might be gone. Are they? If not, we have to debug because I thought these are resolved. These issues however will break tb-updater “as a side effect”.
Meanwhile to work around and isolate testing tb-updater, the --no-tor-con-check parameter which will Skip Tor bootstrap connectivity check. might be helpful.
I upgraded all packages in both VM’s, the issues persist. I downloaded TBB with your workaround and installed tb-starter, but it seems that it downloaded the normal TBB. When I try to launch it I get “Tor browser requires a CPU with SSE2 support”
That was it, I didn’t enable it. Tor Browser is installed and launches! Can’t wait for the UTM port so it will have the full user experience.
I might have made a typo earlier when trying to get the Daemon Log View, so maybe that’s why it didn’t work. Here is the output when I use sudo journalctl -b --no-pager -u onion-grater :
I have Whonix running with UTM with the build commands of @GavinPacini. I just used the UTM build commands, unpacked the tar files and opened the .utm files. Didn’t touch any other files. Copy and paste with the host works out of the box. A couple of issues I notice rightaway:
Moving windows has terrible graphics issues. This sometimes is resolved by making the VM another fullscreen window. Videos also don’t play smoothly.
When entering mission control and back out of it when the VM is another fullscreen window, two black bars occur above and under the desktop
The Whonix desktop takes up more horizontal space than the “borders” of the VM for some reason. As a result, when I try to make a window fullscreen in the VM it goes beyond the right side of the VM screen.
