Reverted https://github.com/Whonix/Whonix/commit/eb0f7e942ef4bd76e32de56b8596d87f536bde4a
Included in 15.0.1.8.1-developers-only.
Hope that unbroke it?
A firewall blocking connections to localhost IP 127.0.0.1 port 3142? Try:
curl http://127.0.0.1:3142
Expected output:
Some html. Otherwise a firewall is faulty.
Is there any way to get these patches of yours to work against the latest stable instead of master? If so, how would I go about that?
Too much to explain, document, complicated. Creating a support mess (more and more documentation, options, but taking away time from next stable version). Also too early for that.
Whonix usually doesn’t backport features in favor scarcely available development time for getting goals implemented for the next stable version of Whonix.
Is it likely these changes will make it into next stable?
Very likely the source code changes will be kept. Stable binary download release of Mac M1 / ARM cannot be predirected.
So I did try building it again, starting with a whole new Debian VM. The Workstation built, but the Gateway failed. I selected the text from the terminal starting a bit before the first error occured:
https://justpaste.it/5brx5
I have the two .raw files in my filesystem. Both are exactly 107.4 gb it says.
https://deb.torproject.org/torproject.org/dists/buster/main/binary-arm64/Packages / Why and how I can enable Tor Package Repository in Debian? | Tor Project | Support seems broken. It has
Package: tor-geoipdb
Version: 0.4.5.8-1~d10.buster+1
Depends: tor (>= 0.4.5.8-1~d10.buster+1)
but only
Package: tor
Version: 0.4.5.7-1~d10.buster+1
background: Tor integration in Whonix Development Notes
Thanks Patrick. Is there a way to fix this? Or will this prevent a Whonix port to M1 until the tor project fixes this?
Please help.
Tried to install the packages thorugh the page you linked and that is indeed the error.
Just sent them an email. Will let you know if they respond.
Also another question: if I would get this running with qemu on my M1 Mac (still have to wait until they fix a bug in the qemu patches so I can install them), can I just update to new Whonix versions when they are released like normal? Or do I have to rebuild for ARM every time if I want to update?
I guess e-mail work’t work. Needs a ticket at https://gitlab.torproject.org.
Hard to predict. The goal is usual updates being functional. I.e. no rebuild required.
The good thing is that https://deb.torproject.org / Why and how I can enable Tor Package Repository in Debian? | Tor Project | Support supports arm64.
Otherwise would be messy. Reason to reconsider Tor integration in Whonix Development Notes for Debian bullseye based Whonix 15.
Thanks Patrick. I tried to open a ticket on gitlab but you need an account which they have to approve, so I am waiting now for them to allow my account or get a response to my email. If people want to have it fixed faster and have already done this earlier they should open a ticket on gitlab
EDIT: just opened a ticket on gitlab: Can not install tor-geoipdb because it depends on an unreleased version of the tor package (#40436) · Issues · The Tor Project / Applications / Tor Browser · GitLab
EDIT: They responded and it should be fixed now
So they just released a fix for the qemu patches and I managed to get something going. The gateway launched, but gave an error the second time that the greater onion service was not running. (Though now it seems to be fine). The workstation did not launch with the listed qemu commands, it gives:
qemu-system-aarch64: -netdev socket,id=internal,listen=:8010: can't bind ip=0.0.0.0 to socket: Address already in use
Anyone an idea how to solve this?
I’m happy that I have the gateway running though!
@GavinPacini how is it going with the UTM implementation? Let me know if I can help with something (I am a beginner though). UTM might have an additional security benefit as well as it uses the solid MacOS sanbox. Don’t know how well normal qemu is sandboxed.
I got the Workstation to boot up as well using the qemu commands that @GavinPacini sent on the 28th of april, but leaving out -drive "if=pflash,format=raw,file=./edk2-vars-work.fd,discard=on" \ for both VM’s
When I try to open the browser I get an error that there is no browser installed that supports open-link-confirmation, so I installed firefox-rse for now. Am I correct that the tor browser is not there because it has not been ported to arm64 yet? So for now the only option is to use firefox or another browser that has been ported?
Networking seems to be ok now. If I map an address in the gateway that translates to the workstation. Issues I see on first impression are absence of tor browser, bad fluency and poor scaling (everything is really small) and resolution.
Hey Sholenka, thanks a lot for being an alpha tester! 
Your discoveries are correct. Tor doesn’t have an official arm64 build, at least to my knowledge. I’ve also been using Firefox for now. Regarding -drive "if=pflash,format=raw,file=./edk2-vars-work.fd,discard=on", you’re correct that it’s better to leave it out actually. I have updated the guide here with that already.
Regarding poor scaling and resolution, this is fixed when we use UTM as a frontend, because it has a SPICE implementation (basically a newer VNC protocol supported by QEMU).
The last few weeks have been very busy in work, but I’ll hope to get the tutorial updated for UTM this coming week.
I tried the qemu commands in the guide, but that resulted in the error I described above. I got it working with the commands you posted in april where
-netdev user,id=external,ipv6=off,net=10.0.2.0/24 \
-netdev socket,id=internal,listen=:8010 \
is
-netdev socket,id=internal,connect=127.0.0.1:8010 \
for the workstation. So you might have to take a look if that has to be updated as well.
Maybe the Tor project will have some interest in porting the browser to arm64 now that Whonix has been ported? Could also be that it depends on libraries that have not been ported yet though. Seems to me that a significant part of the privacy/anonimity benefits of Whonix are only profited from when using the Tor browser.
Maybe something like this (https://github.com/ptitSeb/box86) could be used until then to run it? I don’t know much about methods of browser fingerprinting though so maybe this would make you stand out a lot.
Tickets for Tor Browser arm64 already exists on Tor project issue tracker.
It seems like development for it is dead for about a year now and does not seem to be a priority. I might add a comment maybe pointing out that adaption of the arm platform has been very rapid in the last year and that people would really benefit from Tor browser on arm now on Linux so maybe someone will become interested in woking on it (it runs fine under Rosetta translation on M1 Macs and under emulation on Windows on Arm, but native would always be better as well). I don’t know the dynamics of the open source community though as I am very new to it.
I might also open issues for other Whonix bundled apps that are also not present, like Onionshare.
Even though the Bitcoin wallet is not included, it seems to have been ported: Download - Bitcoin
And there is a Thunderbird build available without update support for now, and if there is sufficient interest they will work on it further: Thunderbird:AArch64 - MozillaWiki
Also, would having Whonix on aarch64 make it more suitable for running Android apps?
Not present doesn’t necessarily indicate a Whonix or arm64 port specific issue. Unless available in current Whonix releases.
Onionshare is written in python. Hence, most likely architecture dependent. Please check if these applications work on Debian (buster) arm64 first. See also beginning from here: OnionShare Whonix integration development discussion - #27 by Patrick
Debian -- Details of package thunderbird in buster shows arm64. I would expect Thunderbird to be installable as per usual in Debian.
Also FYI:
An interesting, new QEMU based virtualization option for Mac worth watching: