This python change may need to be added to any Qubes source code. For example the python based Qubes dom0 file /etc/qubes-rpc/qubes.GetDate might need it.
Furthermore, to improve the robustness (and perhaps even fix this bug) any invocation of date should be prefixed with --utc, i.e. date --utc for any Qubes shell/bash scripts.
Internally, programmatically Qubes should always handle time in UTC. The time shown to the user when manually running date or looking at the systray can remain as is in user local timezone, no problme.
The Whonix template is ~half a minute in the past. If it’s close enough that the 5 minutes makes a difference (date -s +5min is enough to fix), then I can very well believe that 30s in the past may be problematic at times too. Something clearly is making Whonix’s clock be in the past, and I’d say we should avoid it at all regardless if that’s 30s or 5min.
qvm-sync-clock is unwanted in sys-whonix and anon-whonix because sdwdate runs there.
qvm-sync-clock is disabled in Qubes-Whonix ™ Templates until version Qubes-Whonix ™ 16.0.3.7. To be re-considered for later versions. Qubes-Whonix ™ get their time from dom0 at VM startup, which is then randomized using Boot Clock Randomization.
Future: qvm-sync-clock should be equally safe to run inside Qubes-Whonix ™ Templates, if passed though clock-random-manual-cli.
Now working on making timesync in Qubes-Whonix Template similar to Non-Qubes Templates.
As for usefulness of Boot Clock Randomization in Qubes-Whonix Template, see:
I am still not sure Boot Clock Randomization is the cause since then this issue should be equally happening to Non-Qubes-Whonix users and a lot more users. But to find out…
Now I am a bit more sure this is caused by Boot Clock Randomization. It’s not happening in Non-Qubes-Whonix since that is using sdwdate which has much higher accuracy than Boot Clock Randomization. Qubes-Whonix Templates however use only Boot Clock Randomization and do not use sdwdate at time of writing.
Still not sure why this isn’t happening more often to more users and wasn’t reported earlier.
It would probably be easy to make sdwdate connect through Qubes UpdatesProxy - similar to how already APT and Tor Browser Downloader by Whonix ™ are using networking in Qubes-Whonix Templates.
A more secure solution might be something like ⚓ T387 Qubes-Whonix-Gateway as ClockVM, i.e. Qubes-Whonix Templates receiving a timestamp with sdwdate accuracy from an App Qube, but also quite harder to implement.
I’m resurrecting this thread, because the issue is still happens in Whonix 17. And is rather common with Debian fasttrack repository. Looking at automated tests results, about 30% of update attempts fails due to InRelease is not valid yet error. Example with specific time:
whonix-gateway-17:err: E:Release file for tor+https://fasttrack.debian.net/debian/dists/bookworm-fasttrack/InRelease is not valid yet (invalid for another 2min 37s). Updates for this repository will not be applied.
I’m not sure which component specifically causes this (boot time randomization? sdwdate? something else?) but can you make it to not set time into the past, but only (slightly) in the future? or maybe disable time randomization in templates at all (if that’s okay from privacy standpoint)?
Technically probably easy to implement. (+ or - sign is random. Easy to hardcode to “+” in Qubes Templates.)
As for privacy implications, not sure yet. Might not be ideal but perhaps a compromise we have to make.
A wholly different approach would be commenting out fasttrack for Qubes by default as it isn’t very important for non-users of VirtualBox. (Fasttrack is primarily added to acquire VirtualBox Guest Additions which aren’t needed/useful/installed in Qubes(-Whonix).)
But the technical implementation as well as the delta between the various platforms would be messy.
Unhandled Exception ("RuntimeException")
strlen(): Passing null to parameter #1 ($string) of type string is deprecated
Wouldn’t then the issue still happen on VirtualBox? I’m not using this setup, so I don’t know. But if time randomization is used in VirtualBox too, I’d expect updates failing there similarly often.
BTW, we’ve seen the opposite issue too - signature made in the future was rejected by qubes builder. Not applicable to templates really, but may be worth considering when changing how time randomization works. Maybe a better solution would be to reduce the range to +/- few seconds (including random miliseconds offset) instead of few minutes?
I couldn’t decide what amount of time should be randomized at boot in Qubes Template. Now i arbitarily settled for up to 1 second +/- nanoseconds. In other words:
