Time stamp is in the future

User Support
1

when updating any qube, which apparently completes successfully as i see the green checkmark, after it is finished i see this at the end

Removed packages:

None

Hit:1 no tor even though i selected for it to be done through tor

Hit:2 no tor even though i selected for it to be done through tor

Hit:3 no tor even though i selected for it to be done through tor

Reading package lists…

Reading package lists…

Building dependency tree…

Reading state information…

Calculating upgrade…

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

tar: agent/_pycache_: time stamp 2026-08-19 22:14:32.3442677 is 32454.131455641 s in the future

tar: agent/source/_pycache_: time stamp 2026-08-19 22:14:32.3645133 is … in the future

tar: agent/source/apt/_pycache_: time stamp 2026-08-19 22:14:32.3645133 is … in the future

tar: agent/source/apt: …

tar: agent/source/common/_pycache_: …

tar: agent/source/common: …

tar: agent/source/dnf/_pycache_: …

tar: agent/source/dnf: …

tar: agent/source/pacman/_pycache_: …

tar: agent/source/pacman: …

tar: agent/source/plugins/_pycache_: …

tar: agent/source/plugins: …

tar: agent/source:

tar: agent: …

at the top i also see

Fetching 280 packages

Fetched.

…W:Download is performed unsandboxed as root as file couldn’t be accessed by user ‘_apt’. -pkgAcquire::Run (13: Permission denied)

even though I have not enabled root during setup and only use an administrator qube

my clocks seem to be in sync, even though when i first installed qubes whonix failed to initialize 2 times and i had to restart sdwdate-gui

2

timedatectl in dom0 and one of the qubes in which it happened (happens in all) return the same time, so my clocks appear to be synced.

what particularly worries me is this message

…W:Download is performed unsandboxed as root as file couldn’t be accessed by user ‘_apt’. -pkgAcquire::Run (13: Permission denied)

due to the following explanation on ubuntu’s forum:

The security implications of the download running as root is that if someone is manipulating your network traffic and there is a security vulnerability in apt, the attacker might be able to exploit that vulnerability and take over your computer.

3

i have not installed any additional software in the qube or configured it in any way, it is the default template qube that came with the install, and i am updating it over the gui, with the “update” button. is this normal?

4

can someone tell me why i didn’t see tor + https

Hit:1 https://...
Hit:2 https://...
Hit:3 https://...

instead of

Hit:1 tor+https://...

when i enabled updates over tor?

and why am i seeing the message that the time stamp is 12-18 hours in the future?

5

You need to onionize repositories:

I guess you have a wrong system time.

6

how come i have never done this in the past yet my updates usually showed tor+https on all except 1 hits (when there were 3 it would usually be 3/3 tor+https)

so is https:// still routing it through tor just not onionized if i set it to update over tor in the setup?

i have stated in this topic that i have checked the time on dom0 and the affected qube and i have also checked it on sys-whonix in the meantime, they all show the correct time

7

apt-transport-tor and tor+ in repositories are not needed behind a torifying gateway:

What’s the output of the date command in dom0?

8

can you explain what that means? was my assumption then correct that it is still routed through tor just not onionized?

dom0 Wed Aug 19 07:46:31 PM BST 2026

sys-whonix Wed Aug 19 06:46:45 PM UTC 2026

affected qube Wed Aug 19 07:46:45 PM BST 2026

my understanding is that this is normal and that sys-whonix uses coordinated universal time for anonymity reasons, but either way i don’t see a desync that explains what was at one point an 18 hour difference and is now gradually getting reduced

9

It’s described in the link:

apt-transport-tor is a package that allows non-Kicksecure that are not behind a torifying gateway to torify their APT traffic for individual repositories.

apt-transport-tor (tor+http) is the default from Kicksecure 14 onward because it provides better error handling.

That said, it might make sense to use a-t-tor anyhow even if not strictly needed as it will deal better with certain tor anomalies given that it knows tor is involved reporting better errors (like telling you that the .onion address you typo’ed is too long/short; saying “unreachable host” if a service is… well, not reachable, instead of saying “TTL expired” which is reported by Tor and technically more correct but unhelpful), will use different circuits for different sources and stuff.

For instance it reports if the .onion address is too long or short, and will use different circuits for different sources.

Yes.

What’s the timestamp of your last post that you see?

10

sorry for the delayed response, i had to help my little sister

if by that you mean the last post on this forum then sys-whonix time, makes sense since i’m using it

11

Can you post the full update log to see which package produced these errors? Maybe it’s a problem with a specific package and not with your system clock.

12

i closed the update log, according to google it’s the qubes core agent unless the agent is simply saying that the time stamp of what it’s handling is in the future. if there’s a way to check packages specifically then i will do it, but rn idk how and google isn’t helping me much

tar: agent/source/apt/_pycache_: time stamp 2026-08-19 22:14:32.3645133 is … in the future

this (one of the many examples) is the full text, there were no packages being referenced besides that agent/source/apt/_pycache_ (and in other examples other agent associated files)

13

Do you still see these messages if you run the update again?

14

no i don’t, i suppose the time frame expired by now as it was gradually decreasing which makes me think it had nothing to do with my clock since it was a fixed thing and my clock was configured correctly (but it was almost 24 hours at one point). it also happened multiple times in multiple qubes that only had the default apps. combined with the lack of apt-transport-tor that i’m used to seeing and with the …W:Download is performed unsandboxed as root as file couldn’t be accessed by user ‘_apt’. -pkgAcquire::Run (13: Permission denied) message it does make me feel uneasy

15

so any conclusions?

16

It’s most likely that at the time of an update you had a wrong time.

You can check the update logs to see when the update was started (/var/log/apt/history.log for debian).

17

that is not possible because i received the same messages after having checked my time and it happened multiple times

it shows the correct time. i will leave the topic open without a solution because while the issue is gone, the solution and cause remain unknown and this topic will be mostly unhelpful to any future reader with the same issue