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

Tor Browser Downloader needs to update its PGP keys

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)

1 Like

A standard (“everyday”) update needs to be performed first to get the updated tb-updater package.

Actually that does not help.

Despite signing key was already updated:

The key mentioned on

That is:
https://keys.openpgp.org/vks/v1/by-fingerprint/EF6E286DDA85EA2A4BA7DE684E2C6E8793298290

Is already up to date. Mentioned key matches the local key on the disk.

diff EF6E286DDA85EA2A4BA7DE684E2C6E8793298290 /usr/share/torbrowser-updater-keys.d/tbb-team.asc ; echo $?

0

Also if EF6E286DDA85EA2A4BA7DE684E2C6E8793298290 gets manually imported I couldn’t manually perform digital software signature verification.

gpg --verify sha256sums-unsigned-build.txt.asc sha256sums-unsigned-build.txt

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

Investigating the key which the file was signed with. That key must NOT be used blindly with verification that it’s a authorized key.

scurl --output 35CD74C24A9B15A19E1A81A194373AA94B7C3223 "https://db.torproject.org/fetchkey.cgi?fingerprint=35CD74C24A9B15A19E1A81A194373AA94B7C3223"

Imported and show key signatures.

gpg --list-sigs 35CD74C24A9B15A19E1A81A194373AA94B7C3223

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

That key is listed on torproject.org/about/people.

It is currently undocumented in the upstream, The Tor Project documentation (How can I verify Tor Browser's signature? | Tor Project | Support) that this key can/should be used to verify this or any releases.

(I am ignoring the 2019.torproject.org subdomain since it seems to be an archive, lists and older key and it’s almost 2022.)

  1. Make this issue unspecific to Whonix.
  2. “Forget” about Whonix for a while.
  3. Imagine wanting to use Tor Project on the Debian platform by downloading it from upstream, torproject.org.
  4. Report a bug upstream. → Information Booster might be Available!

Organisational background: Linux User Experience versus Commercial Operating Systems

Related:

New wiki chapter written just now:
Tor Browser Download, Installation and Digital Software Verification Issues

1 Like

Upstream bug: sha256sums-unsigned-build.incrementals.txt and sha256sums-unsigned-build.txt are not signed with torbrowser key (#40759) · Issues · The Tor Project / Applications / Tor Browser · GitLab

2 Likes

Until the upstream bug gets fixed:

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.

Thanks for your effort!

like Tor-over-Tor prevention

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

1 Like

I may have misread somehting, but

_https://www.whonix.org/wiki/Dev/anon-ws-disable-stacked-tor#Environmental_Variable_Adjustments

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)

Tor Browser: Manual Download can be used at any time.

Above documentation link is complete.

Documentation slightly clarified just now.

Tor Browser Download, Installation and Digital Software Verification Issues

None of it is needed.

Tor Browser: Manual Download is complete.

Dev/anon-ws-disable-stacked-tor - Whonix is in /Dev. It’s developer design documentation. It describes what is. It’s not user documentation, what a user should do.

1 Like

Thanks for the detailed answer!

It works as expected.

(Update)
Ended up placing the manually downloaded TBB in ~/tor-browser_en-US
/home/user/.tb of anon-whonix.

To quote the docs:

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.

Robert

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:

Because only the sha256 signature is singed by the wrong key. The signature of the archive tarball is signed with the correct key.

That is Tor Browser Internal Updater which uses a different technical implementation and is unrelated to this issue.
(Sign our MAR files (#13379) · Issues · The Tor Project / Applications / Tor Browser · GitLab)

tb-updater package (Tor Browser Downloader by Whonix developers) was updated. See:
In Qubes-Whonix ™

Also very much by design.

Installation Confirmation Notification

Nothing unexpected. → Tor Browser Update: Technical Details

Google (not duckduckgo unfortunately) has pretty good search results for:

35CD74C24A9B15A19E1A81A194373AA94B7C3223

Georg Koppen
IRC: GeKo
Currently lead of the Network Health team.
https://db.torproject.org/fetchkey.cgi?fingerprint=35CD74C24A9B15A19E1A81A194373AA94B7C3223

See:

gpg --fingerprint 3D1B08D7D5F58676B838DC925601A3DC64D6E363

And.

gpg --fingerprint 3D1B08D7D5F58676B838DC925601A3DC64D6E363 | grep --color 5601A3DC64D6E363

And.

gpg --with-subkey-fingerprints --fingerprint 3D1B08D7D5F58676B838DC925601A3DC64D6E363

gpg is a usability mess. By default,

  • uses short main key fingerprints
  • short sub key fingerprints (needs --with-subkey-fingerprints)
  • inconsistent spacing within key fingerprints

Example:

35CD 74C2 4A9B 15A1 9E1A  81A1 9437 3AA9 4B7C 3223

Only 1 space but in the middle there are 2 spaces. This makes it hard to find through search engines.

  • Sometimes notations of fingerprints require using no spacing at all.

That all makes a lot of sense. Always a bit on the paranoid side :slight_smile:

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? :man_shrugging: Anyway, it seems like everything is ok as 11.0.3 has verified.

Happy holidays

Tor Browser Internal Updater downloads the update by default - this is a default set by The Tor Project and unmodified in Whonix.

If it installs by default I am not sure. It didn’t. Didn’t notice if that changed.

Thank you! Merry Christmas!

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