Feb 18 2019
Dec 7 2018
Dec 3 2018
Jun 20 2018
nftables transition info:
Jun 18 2018
Dec 21 2017
May 26 2017
Note to self: try to disable and see if konsole and kwrite are still functional in timesync-fail-closed mode.
Mar 14 2017
Feb 16 2017
Feb 5 2017
Dec 25 2016
Dec 24 2016
First I thought allowing incoming traffic on Whonix-Workstation in timesync-fail-closed mode would be okay, since outgoing traffic would be blocked. On a second thought, it would not be useful if a hidden service was reachable but the backend server could not reply (still blocked in timesync-fail-closed mode). So...
Dec 23 2016
That's a good idea.
What about retrying qubes-whonix-torified-updates-proxy-check.service on
The current workaround (to unbreak Whonix developers repository) allowing full outgoing access to 127.0.0.1 is as bad as not implementing this ticket. (One could run apt-get update which results in uwt apt-get update connecting to 127.0.0.1, where Tor would accept it.)
Dec 16 2016
Blocking outgoing connections to 127.0.0.1 in timesync-fail-closed mode creates massive issues. For example konsole starts but then is unresponsive (frozen) due to the blocked localhost tcp packages. (And since we'll stay with kwrite.) A solution needs to be found.
Sep 16 2016
I'd expect some more problems, but nothing serious. For example CUPS may
Only kwrite does not work without localhost access. Strange.
Network shouldn't be needed for GUI applications as long as DISPLAY
environment variable is correctly set. Make sure it's :0, and not
Sep 9 2016
Sep 7 2016
Up to you but I still think timesync-fail-open sounds more technically descriptive from a dev POV than using normal/regular. That isn't a problem because regular users should not even know about it.
Sep 5 2016
restricted mode -> timesync-fail-closed mode
Sep 4 2016
Added to bootclockrandomization package. Non-ideal, but less overhead (no additional package just for this) and more code can be reused.
Sep 1 2016
OK. Do you suggest a simple sdwdate input box for them to put their current time in, then it applies the offset range we think is safe before setting the guest time?
Aug 30 2016
It's a bit more difficult.
Maybe instruct them to:
Aug 29 2016
- separate whonixcheck help message when Tor bootstrap succeeded but timesync failed - avoid too technical word "bootstrap" - output - comments
Aug 28 2016
Instead of monitoring the clock for changes we can assume that an interrupted Tor connection was caused by suspend event that initiates syncing. Is the tearing down of stale circuits when waking up the machine detectable in Tor's log? Can this be checked via a controlport event?
Aug 27 2016
clock jump detection would be useful independently from this ticket also.
Aug 26 2016
Aug 25 2016
Aug 24 2016
Aug 23 2016
Thank you for participating in this one! I can really use some input here.
I like the idea but how do you plan to tackle the case when a user resumes a guest from sleep?