When trying to update whonix-worksttion to Tor Browser 11.0.3 today I get this:
ERROR: Digital signature (GPG) could NOT be verified.
Tor Browser update failed! Try again later.
gpg_bash_lib_output_alright_status:
gpg_bash_lib_output_failure:
gpg_bash_lib_output_diagnostic_message:
gpg_bash_lib_internal_gpg_verify_status_fd_file: /var/cache/tb-binary/.cache/tb/gpgtmpdir/gpg_bash_lib_internal_gpg_verify_status_fd_file
gpg_bash_lib_internal_gpg_verify_output_file: /var/cache/tb-binary/.cache/tb/gpgtmpdir/gpg_bash_lib_internal_gpg_verify_output_file
gpg_bash_lib_output_gpg_import_output:
gpg: keybox '/var/cache/tb-binary/.cache/tb/gpgtmpdir/pubring.kbx' created
gpg: /var/cache/tb-binary/.cache/tb/gpgtmpdir/trustdb.gpg: trustdb created
gpg: key 4E2C6E8793298290: public key "Tor Browser Developers (signing key) " imported
gpg: Total number processed: 1
gpg: imported: 1
gpg_bash_lib_output_gpg_verify_output:
gpg: Signature made Fri 17 Dec 2021 02:18:25 PM UTC
gpg: using RSA key 3D1B08D7D5F58676B838DC925601A3DC64D6E363
gpg: Can't check signature: No public key
gpg_bash_lib_output_gpg_verify_status_fd_output:
(repeated 2 times to make sure it wasn’t just a bad download)
gpg: Signature made Fri 17 Dec 2021 02:18:25 PM UTC
gpg: using RSA key 3D1B08D7D5F58676B838DC925601A3DC64D6E363
gpg: Can’t check signature: No public key
pub rsa4096/0x94373AA94B7C3223 2013-07-30 [SC]
35CD74C24A9B15A19E1A81A194373AA94B7C3223
uid [ unknown] Georg Koppen gk@torproject.org
sig 3 0x94373AA94B7C3223 2014-02-01 Georg Koppen gk@torproject.org
sig 3 0x94373AA94B7C3223 2014-02-01 Georg Koppen gk@torproject.org
uid [ unknown] Georg Koppen gk-tpo@riseup.net
sig 3 0x94373AA94B7C3223 2021-09-06 Georg Koppen gk@torproject.org
uid [ unknown] Georg Koppen groeg@vfemail.net
sig 3 0x94373AA94B7C3223 2013-07-30 Georg Koppen gk@torproject.org
uid [ unknown] Georg Koppen georg@getfoxyproxy.org
sig 3 0x94373AA94B7C3223 2014-02-01 Georg Koppen gk@torproject.org
sub rsa4096/0x5601A3DC64D6E363 2021-09-06 [S] [expires: 2022-09-11]
sig 0x94373AA94B7C3223 2021-09-06 Georg Koppen gk@torproject.org
sub rsa4096/0xC1FD319BC1C66DA2 2021-09-06 [E] [expires: 2022-09-11]
sig 0x94373AA94B7C3223 2021-09-06 Georg Koppen gk@torproject.org
For Qubes-Whonix, can I manually download Tor Browser via _https://www.whonix.org/wiki/Tor_Browser/Manual_Download , replacing /var/cache/tb-binary/.tb as temporary solution?
Would it also work to place the download tor binary in /home/user/.tb ?
In other words: Are all of the Tor browser customizations (like Tor-over-Tor prevention) stored in system config files or do I need to adjust about:config values inside manually downloaded Tor Browser?
I have read your new wiki chapter _https://www.whonix.org/wiki/Tor_Browser#Tor_Browser_Download.2C_Installation_and_Digital_Software_Verification_Issues , but I am unsure, if the procedure in point B) differs between Qubes-Whonix and Tor Browser Bundle (TBB) installations in a non-whonix template.
just so you know, anti-tor-over-tor is done on the whonix gateway, not the tor browser
whonix does not give the tor browser a choice of where it wants to connect to so that from the workstation, ip leaks are impossible
so it depends on what kinds of configuration you want, but IIRC whonix does not modify anything in the regular tor browser because of fingerprinting risks except for disabling circuit viewing and disabling the tb launcher
mentions environment variables, which are changed in WorkStation files.
Concerning desired configuration:
I just would like to replace the stale Whonix WorkStation TBB with a manually downloaded/verified one , while still using Whonix security and privacy features (not Tor Browser over Debian)
When a App Qube starts and it has never copied Tor Browser before (likely only at first boot), and there is no copy of Tor Browser in /home/user, Tor Browser is copied from /var/cache/tb-binary to /home/user.
Existing copies of Tor Browser in the home folder are not overwritten. This is due to an explicit design goal to avoid data loss; see tb-updater in Qubes Template VM for technical details.
Another good alternative to replace the binary in /var/cache/tb-binary of the Workstation template itself. This has the advantage to have updated Tor Browser versions for all template based AppVMs of this template.
How does switching to a ‘direct’ signature verification fix this issue, if the issue was with the public key Tor used for this Tor release?
Also, I just had something very weird happen to me this morning. I opened a Qube based on a Whonix-ws-16 template, opened Tor Browser, and the browser auto updated to 11.0.3. A small window popped up informing me of this update, which I tried to click out of because I knew of this verification issue, but it continued anyway and 11.0.3 was installed. This made me feel very uncomfortable, so I contacted a colleague I know who also runs Qubes, and he opened a Whonix based Qube as well, and the same exact thing happened after a few times of opening and closing Tor. Has anyone else here had this experience?
Even odder, the Tor Browser Downloader in my Whonix-ws-16 Template informed us both that we were now updated to 11.0.3. This shouldn’t be the case due to Qubes’ compartmentalization - only Tor in the App Qube had been updated. Neither of us had performed this update yesterday because we were unable to (because of the problem discussed above in the forum posts).
We then updated the whonix templates using Qubes Updater, which updated tb-updater, and ran Tor Browser Downloader in Whonix-ws-16 template again. We continued forward for a fresh install of 11.0.3. It was able to verify now because of the change to direct signature verification posted by Patrick above. What concerned me again, was that it showed ‘previous signature’ as December 9th, and ‘last signature’ as December 20th, even though both versions were supposedly 11.0.3 (Again - I was just trying to download a fresh browser profile and ensure I had a proper version). This doesn’t make sense, as 11.0.3 was released on December 20th, a signature couldn’t have been created before that date. When I run Tor Browser Downloader one more time, it now shows me as both signatures on December 20th - this makes me think that the auto updated December 9th sig 11.0.3 wasn’t legitimate.
Does anyone else have the above experience or possible explanations?
I appreciate your comments.
When I verify the linux download in a disp Qube, it properly verifies with the correct key listed on the Tor website, and the key listed by you, just as it should:
gpg: Signature made Sun 19 Dec 2021 10:37:45 PM EST
gpg: using RSA key E53D989A9E2D47BF
gpg: Good signature from “Tor Browser Developers (signing key) torbrowser@torproject.org” [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290
Subkey fingerprint: 6131 88FC 5BE2 176E 3ED5 4901 E53D 989A 9E2D 47BF
I don’t see 35CD74C24A9B15A19E1A81A194373AA94B7C3223 anywhere.
Someone on Qubes IRC had this (another different key)
gpg_bash_lib_output_gpg_verify_output:
gpg: Signature made Fri 17 Dec 2021 02:18:25 PM UTC
gpg: using RSA key 3D1B08D7D5F58676B838DC925601A3DC64D6E363
gpg: Can’t check signature: No public key
gpg_bash_lib_output_gpg_verify_status_fd_output:
That all makes a lot of sense. Always a bit on the paranoid side
Thanks for walking me through it step by step, especially on Christmas!
The only thing that still confuses me is that for the internal update, I swear I did not select ‘Check For Updates’ or ‘About Tor Browser’. Maybe for 11.0.2 it did it by itself? Anyway, it seems like everything is ok as 11.0.3 has verified.