https://github.com/Whonix/whonixcheck/commit/5c8bf9be88f9951d2263b23aa82818935aa3f733

In T598#12298, @Patrick wrote:

That worked in Debian jessie based Whonix. Currently broken in Debian stretch based Whonix. Apparently the KDEDIRS variable was abolished and hopefully replaced by something else. Still TODO to figure that out and fix.

Thanks for reporting!

Awesome! Works for me. Merged.

Just an update.

Should fix the right click menu freeze issue

I'll check in the next developers-only build.

I do not see the issue in my case. I have latest sni-qt installed and the sdwdate icon is also visible.

Works for me! Merged.

Tested standalone using - python3 url_to_unixtime 127.0.0.1 9050 check.torproject.org 80 true

Sorted out 2. and 3. in git master. 1. is todo.

sdwdate-gui generally works, but after installing the sni-qt package, sdwdate-gui is invisible.

TODO:
Need to check if this is solved once I have a new image working.

Added some fixes on top.

One more typo fixed
https://github.com/joysn/sdwdate/commit/27c547c2e84616feb25cc0f0de65f8442e0a83c7

usr/share/sdwdate/unit_test shows some broken output:

porting to python3 should fix this.
https://github.com/joysn/sdwdate/commit/a25819834c8ed813696f52f003297ec04c40892c

Merged. And added a few minor fixes on top. Please merge my changes.

Probably also needed: python3-gevent

https://packages.debian.org/search?keywords=python3-gevent

This has couple of commits involving
/usr/lib/python3/dist-packages/sdwdate/config.py
/usr/lib/python3/dist-packages/sdwdate/proxy_settings.py
/usr/lib/python3/dist-packages/sdwdate/remote_times.py
/usr/lib/python3/dist-packages/sdwdate/timesanitycheck.py
and
/usr/bin/sdwdate

update dependencies to python3
https://github.com/Whonix/sdwdate/commit/c735652569531b3f6443ae57357612b6ccccca66

In T624#12127, @joysn1980 wrote:

https://github.com/joysn/sdwdate/blob/master/usr/lib/sdwdate/url_to_unixtime

This is the first one to go. This change requires the following
sudo apt-get install python3-socksipy

In T624#12101, @joysn1980 wrote:

Are there any other files/path involved here?

This is the first one to go. This change requires the following
sudo apt-get install python3-socksipy
sudo apt-get install python3-dateutil

In-between, if anyone, else wants to give this a try, are welcome to do so

Let me give this a try, but probably once I am done with the porting of all the sdwdate/sdwdate-gui scripts to python3

In T598#12098, @joysn1980 wrote:

I see the same issue (repeated right click , restart ) is present even in the older version. Can you verify that once?

Infact, these files itself needs quite a lot of work to convert into python3. It is probably not just changing the shebang.
It requires new modules to be installed, changes in those modules needs to be incorporated too. So modularizing the work will help me.

I am trying to list down the files that needs conversion

Yes it is indeed by design.
Some comments in the code

I see the same issue (repeated right click , restart ) is present even in the older version. Can you verify that once?
If so, we can fork "unresponsive right click" issue out of this ticket.

sdwdate-gui -> right click "exit" ->
Segmentation fault

Well this issue is seen only in "Jessie" not in "Stetch". Still I fixed this.

Great! Merged. show_message (the popup) now functional again.

Here it is Patrick.
https://github.com/joysn/sdwdate-gui/commits/master/usr/lib/sdwdate-gui/show_message

1. These packaging related changes are done in git master. (And can be seen in the git history.)

Few things

1. I am not sure what changes are needed to make sure that we do

These screenshots were useful to create a homepage for sdwdate-gui. There is now a homepage for both, sdwdate and sdwdate-gui.

Looks great!

As discussed with Patrick the issue is with the new KDE 5 (Plasma) architecture

Excellent! All merged.

whonix-setup-wizard, 1 change required, to be merged

So we are done with

From guimessages - 1 change required and it done
https://github.com/joysn/python-guimessages

From sdwdate-gui

br_add - nothing to add
striphtml nothing to add
generic_gui_message - done
tb_updater_gui - done

A few more projects are involved, where this is TODO. Btw there are all our components where python is involved.

When sni-qt is installed:

In T533#11156, @Patrick wrote:

• add timesync-fail-closed considerations to ipv4_input_rules / https://github.com/Whonix/whonix-ws-firewall/blob/master/usr/bin/whonix_firewall#L196

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...

• https://github.com/Whonix/whonix-gw-firewall/commit/00823a325d104e04d065fda8ae96992d1f90e184
• https://github.com/Whonix/whonix-ws-firewall/commit/df5183dcecd62dae9329571c5ab0e57916bd6eb4
• https://github.com/Whonix/qubes-whonix/commit/1c99edbbce1f375591f2e42aaf679ba7492b4dd8

That's a good idea.

What about retrying qubes-whonix-torified-updates-proxy-check.service on
connection failure?

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.)

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.

I'd expect some more problems, but nothing serious. For example CUPS may
not work...

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
localhost:0.

On Whonix-Gateway:

• https://github.com/Whonix/whonix-ws-firewall/commit/9a02fb1cc429bc5450a671708d3dff0da2df257c
• https://github.com/Whonix/whonix-gw-firewall/commit/e55b6213a4d284368a4d3736590f516b712a109e

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.

restricted mode -> timesync-fail-closed mode

Added to bootclockrandomization package. Non-ideal, but less overhead (no additional package just for this) and more code can be reused.

Yes.

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?

It's a bit more difficult.

Maybe instruct them to:

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?

clock jump detection would be useful independently from this ticket also.

WIP

WIP

WIP

WIP

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?

Split task iptables block network access until sdwdate succeeded:
T533