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

sys-whonix starts unintentionally

I entered the above script and applied the latest updates to debian, whonix-ws-16 and whonix-ws-16-TEST and got the following results:

debian updates via sys-net

whonix-ws-16 via sys-whonix

whonix-ws-16-TEST via sys-whonix-TEST

If you now call whonix-ws-16-TEST or whonix-gw-16-TEST in the Qube-Manager, sys-whonix-TEST will now start correctly.

This is a very good result!

The only error I still detect is the following:

If I call whonix-ws-16-TEST with any function in the app menu (e.g. tor-browser-downloader or terminal), sys-whonix-TEST starts correctly.

With whonix-gw-16-TEST this does not succeed, here sys-whonix starts incorrectly.

I am not sure whether I can configure this extra with a rule in qubes.UpdatesProxy.

Could be qrexec.

In dom0. Watch journalctl and see qrexec calls.

sudo journalctl -f

Thank you, I´ll try this and summarize the results, perhaps there is any solution.

I think I have found the solution.

I have added the following line in qubes.UpdateProxy as first (so before the others). It defines a rule extra for whonix-gw-16-TEST:

#Upgrade whonix-gw-16-TEST through sys-whonix-TEST
whonix-gw-16-TEST $default allow,target=sys-whonix-TEST

Only then come the rules for whonix-ws-16-TEST, then those for the whonix templates and the “normal” templates, as described above.

This not only fixed the update problem via QubesUpdater, but also causes the correct sys-whonix-TEST to now start in the app menu when calling any app.

I will post this in the Qubes forum as well. It should work with any whonix clone.

So obviously nothing needs to be changed in the new policy system. How it will be when qubes.UpdateProxy is no longer available, we will have to try then.

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