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:
E:Release file for tor+https://fasttrack.debian.net/debian/dists/bookworm-fasttrack/InRelease is not valid yet (invalid for another 1min 22s). Updates for this repository will not be applied.
I guess it’s because the template in the repository doesn’t have the fix yet, and installing the fix failed because of the above. Is it a good time to build updated template?
