Aug 9 2021
Any updates on this?
Jan 12 2021
I am not sure sdwdate-gui would be a strong enough notification if networking was actually blocked if sdwdate did not succeed yet.
Dec 11 2019
It looks like bpfilter is in rather early stages, and it's few years until we'll see it in Debian.
Or skip nftables and use Berkeley Packet Filter (BPF)?
Oct 21 2019
Added requested NFTables example from duclicsic #netfilter freenode.
Oct 17 2019
Starting with Bullseye nftables will be the default:
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 15 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
Sep 15 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 29 2016
It's a bit more difficult.
Maybe instruct them to:
- 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.