three things that have caught my attention lately:
The update function for the new Tor Browser update (15.024) does not work properly under Qubes-Whonix.
After the download, a window briefly appears with bold black text stating that the download cannot be verified. It may be because the Tor project has issued a new subkey (see blog).
The Sdwdate-Gui icon in the taskbar on Qubes often cannot be operated properly, or the menu cannot be accessed, for example, when you want to restart Sdw-Date or access the log. It could also be a Qubes problem, but I’ll post it here anyway.
Generally, Sdw-Date takes much longer than it did two or three months ago to complete the full process (“full red circle”) for deployment. You often have to restart, and sometimes it only works on the third try.
No matter what I cant get tor-browser to update in the workstation template (and thus updated in dispvms etc).
I get:
update-torbrowser (tb-updater) [ERROR]: Digital signature (OpenPGP) could NOT be verified.
Tor Browser update failed! Try again later.
sqop_output: No acceptable signatures found
Don’t want to be annoying, but how long does it take to fix this? Isn’t this just copy and paste the new gpg key and therefore could have been done in like 5 minutes?
Having fairly recently installed the latest version of Qubes fresh, my whonix vms are 16! versions behind the latest tor-browser. Is there a way I can download it in the template VM manually or something?
No, it is not. Releasing a change takes time, testing, peer review (two people independently verifying the new key is the right key), and critically, can get entangled with other changes in the pipeline. It’s not an ideal situation and there is discussion internally about how to make changes like this quicker in the future, but it’s the situation we have at the moment.
Note that the vast majority of our development efforts are focused on getting a new release out, so this should not be a problem for very long if all goes according to plan.
Unfortunately I agree this is the best solution for the moment. A manual download won’t help for DispVMs because Tor Browser is installed in a system-wide location in the template and updating that location is somewhat hard. (Not impossible but difficult.)
Launch a terminal to open a new DispVM and keep it open. Then open Tor Browser in the newly launched DispVM, allow it to update, and restart the browser. The open terminal window will keep the VM alive. Once it restarts, use it.
Ah that makes sense, thanks. I am new to qubesos. I will do that until the updater works instead of messing with trying to manually update things on the template, seems more sensible.
I just open a Tor-Browser-DisposableVM “Tor Browser (Anon Dist)” and use the internal Tor Browser update mechanism, right?
You just have to enable the “menu bar”, then click on “Help” and then on “About Tor Browser”. The window that opens will instantly check for updates and download the new update and then you only have to click on “Restart Tor Browser”.
I mean you would always have to do that again for a new Tor-Browser-DisposableVM, but since the Tor-Browser-update is only about 7.8 megabyte, the download and install is done very fast. You just have to remember to update it every time you open a new Tor-Browser-Disposable-VM.
That should also do it, at least for the Tor-Browser-Disposable-VM in which the update was manually applied through the internal Tor Browser update mechanism, right? Or are there any security concerns regarding this method of updating the Tor Browser for the Tor-Browser-Disposable-VM?
Doing that will restart the browser. DispVMs automatically forcibly shut down when the first app opened in them is closed, so if the first app you launch is the browser, doing this may cause the VM to shut down mid-browser-update. (At least, that’s what I expect to happen; I’m using the whonix-developers repos so my template’s Tor Browser is up to date and I can’t test the theory. If you’re able to omit the terminal step, go right ahead, there shouldn’t be any downsides to that.)
Oh no, what I meant is, if it works, which it definitely seems to, because I have tested it multiple times…if there are hidden drawbacks/mistakes that I overlooked. Because technically it seems like it’s working, but I’m no expert and that’s why I fear that maybe it could just look like everything is good, but maybe under the hood there is something not working right and that’s why, maybe, I shouldn’t do it with this method.
That’s why I asked, because only an expert/experienced user would know if that method is really safe to use or just looks fine, but actually isn’t.
Ah, that makes sense. If it seems to work, it probably does work. Double-check the Tor Browser version shown in the About Tor Browser dialog; if that looks right, you should be set. The only risk I had in mind was the automatic shutdown.
There is no shutdown of the Tor-Browser-DisposableVM at all, just a restart of the Tor Browser when you click on “Restart Tor Browser” to apply the update. But the VM stays open the whole time. And yes, of course I checked at the “About Tor Browser” windows if I got the new version and yes, it showed me that the new version of the Tor Browser is installed.
Again, maybe I’m a little too paranoid, but I fear, since it’s not the official way of updating, there might be some hidden stuff, that comes to bite me in the ass later.
Yeah, it’s perfectly fine. What you’re doing actually is an official way of updating, it just is one we try to avoid users needing to do too often since constantly re-updating is not great from a UX standpoint. Persistent AppVMs like anon-whonix rely on Tor Browser’s built-in updater to keep the browser up-to-date after it’s launched the first time, since re-copying it from the system-wide location would wipe any state the user might want to save like downloads. DispVMs can do the same thing, but there’s “no point” there since any state is wiped on shutdown anyway. In this scenario though there is a good reason to use the built-in updater.
Only thing that is obvious: I must remind myself to always first to go to “About Tor Browser” and let the Tor Browser download the update, which is then applied if I click on “Restart Tor Browser” after the download of the update.
And if you think the right way, that the best security and anonymity practice is to open a new Tor-Browser-DisposableVM for (almost) every new tab, so that you have that stream isolation, that could amount to downloading and installing the Tor Browser update like 50 times a day, every day. Depending of how many new tabs you open per day of course.
No, it is not. Releasing a change takes time, testing, peer review
(two people independently verifying the new key is the right key), and
critically, can get entangled with other changes in the pipeline. It’s
not an ideal situation and there is discussion internally about how to
make changes like this quicker in the future, but it’s the situation
we have at the moment.
Is this the first time Tor Project upstream rotated its keys? As with @InLegolaswetrust I would expect a faster response to this issue.