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)
anon-ws-disable-stacked-tor is in /Dev. Itâs developer design documentation. It describes what is. Itâs not user documentation, what a user should do.
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.
Anyway, it seems like everything is ok as 11.0.3 has verified.