Warning: this packages cannot be authenticated

I have upgraded whonix-gw without issues, but while I executed the same command in whonix-ws, showed up that the packages (were the same) couldn’t be authenticated. I installed them. Did I make a mistake?

Thank you

1 Like


You are at McDonald’s and you order a Big Mac. But instead of the employee handing you your sandwich, some guy in a trench coat comes along and says, “Here, take this. Here’s your Big Mac.” Wouldn’t you want to know that the Big Mac was actually made by the people behind the counter? (Not the best example because a Big Mac from any source can probably be considered malicious, but anyway…)

Run sudo apt-get update before dist-upgrade.
Are you compromised? Probably not but how would I know? You just ate a burger that some random guy handed to you.

1 Like

What is usually the goal of this? Do they want to poison me? For now I’m ok
If I want to eject this burger from my body, how I could do?
Is there a command to see what burger I have eaten? (I don’t remember more it)

1 Like

You could try putting your head in the toilet, but if he just sneezed Ebola all over the burger… good luck.

If I was using Virtualbox, I would roll back to an earlier snapshot.

Unfortunately, Qubes doesn’t have a built-in snapshot mechanism, which is why you have to be very, very careful when handling templates. If you’re concerned, best option is to reinstall template.

You also didn’t say if you were using Debian .onion mirrors. At least in that case, you would at least know that you were getting whatever is on the server.


1 Like

I reinstall it but can I save some text file, downloads or are infected?

Has been the first time that I haven’t run apt-get update before because I have upgraded together and thought that if in whonix-gw apt-get update have installed nothing this could happen also in whonix-ws. I usually upgrade them not together

apt-get update = tell me what needs to be upgraded
apt-get dist-upgrade = do it

Doesn’t make any sense to not run update first. TBH, I don’t know what happened in your case. Perhaps you ran update a long time ago, forgot to run dist-upgrade, and in the meantime, the packages on the server changed? Just random speculation, I have no idea.

Assuming that you are getting updates over Tor, the attack we’re talking about is much more likely (unless you’re already compromised) to be an attack of opportunity and not an attack targeting you specifically. So the attacker shouldn’t know what’s on your machine prior to the attack. Text files should be safe and downloaded documents probably safe. Downloaded executables should be re-downloaded or autheniticy verified.

The real question is, “Why do you have Downloads on your templateVM?!?!”

1 Like

We don’t have a guide for converting maybe-compromised data to safe data. Text files is a format where this is easier than with other types of files since these are a lot less complex.

Do all of this in a non-networked dispvm or temporary VM. Use an editor you are usually not using. (To reduce the chance that your text file has been prepared with an exploit against your usual editor.) Open the file, copy and paste the contents to another VM.

Also not a very Whonix specific question. Rather a general security question.

No, I haven’t downlods in my template, I mean in anon-whonix.
Close this topic about downloads, I have deleted all

I removed my template and have reinstalled another. First day done the upgrade without issues. Today there weren’t other upgrades to do in gw and ws. In gw all is gone well. In ws I run “sudo apt-get update”, in the list of link that showed there were only 3 Get (Get:1, Get:2, Get:3 – usually should show Get:19). Run immediately after “sudo apt-get dist-upgrade” and showed up 4 packages to upgrade, click y and another time

WARNING: the following package cannot be authenticated

Close the terminal, go in root mode, apt-get update,(load all Get link), apt-get dist-upgrade and install the same packages without issues.

Question from an “incompetent” is: Could be this an error when the command apt-get update can’t log all the link and for this doesn’t authenticate the packages?

  1. Have you made any changes to your apt sources? /etc/apt/sources.list.d/
  2. Are you waiting until Tor is fully bootstrapped?
  3. Do you have an unreliable network connection?

Next time, do this in a terminal:

sudo apt-get dist-upgrade

(whonixcheck confirms Tor connectivity and runs apt-get update for you.)

1 Like

1 From the time that I have installed ws, no
2 For this I don’t know, sometimes I don’t wait the message “connected to Tor” because I think that I haven’t seen it or it isn’t appeared
3 No

So, no need to run “sudo apt-get update && sudo apt-get dist-upgrade” in a terminal, only sudo apt-get dist-upgrade"?

Operating System Software and Updates - Kicksecure

If I read this correctly and please correct me if wrong, it’s only necessary to run “sudo apt-get update” and only need to run “sudo apt-get dist-upgrade” if there are problems when running “sudo apt-get update”?

Not correct. Sorry to add confusion.

If you type man apt-get in any terminal, you will find a very good description of what those commands do.

The reason I said that apt-get update was not necessary is because it is built in to whonixcheck. If you run whonixcheck first and let it complete, then you don’t need to run apt-get update again.

1 Like

What could add confusion is that whonixcheck as of Whonix 13 runs in different modes. In autostart mode if whonixcheck previously recently completed, it only does the Tor connected check. No apt-get update check.

Manual full runs of whonixcheck always run apt-get update.

When whonixcheck is not involved, it boils down to the Debian default. Always update then upgrade.

1 Like

Wrong! Sorry, I wasn’t aware that there is a limited recovery function. You can rollback one time with qvm-revert-template-changes.

See: https://www.qubes-os.org/doc/dom0-tools/qvm-revert-template-changes/

Hi all,

Following the guideline here:

and using the command:

sudo qubes-dom0-update --action=reinstall qubes-template-whonix-gw

leads to the error message:

ERROR: yum version installed in VM host does not support --downloadonly option
ERROR: only ‘install’ and ‘upgrade’ actions supported (reinstall not)

Hmm… this is Qubes 3.2 if that matters.

I have often thought that template VMs should be reinstalled from time to time, as the ‘Snowden effect’ has probably made Qubes a very interesting target for attack by determined adversaries.

Ditto deleting and recreating AppVMs somewhat regularly. I expect that the /home and /rw directories (which are vulnerable i.e. persistent) are already being exploited by Qubes malware. It’s an obvious thing to do as part of 1st stage pwning, before leveraging a Xen exploit.

As an aside, it is time for people to upgrade their Fedora 23 templates in Qubes to Fedora 24, following this guideline below. Fedora 23 will be EOL sometime next month. Works smoothly for networking etc. I’m surprised a ready-made template isn’t already available.



ERROR: yum version installed in VM host does not support --downloadonly option

I guess you need to update your fedora template first. Or download the
newer version. Then set your UpdateVM to the updated template.

If you are using a Debian (and thereby also Whonix) based template you
might need a newer yum from Debian backports or testing repository.
Temporary install in updatevm appvm should suffice. Untested by me.

Marek is hard at work on it: Fedora 24 template · Issue #1986 · QubesOS/qubes-issues · GitHub

1 Like

Downloadable Fedora 24 template was announced:


1 Like