sdwdate and sdwdate-gui development thread

2018-06-28 01:37:21 - sdwdate - WARNING - Maximum allowed number of failures reached in pool 1 (6 of 18). Giving up.
If the problem occurs too frequently, please report it.
Sleeping for 13 minutes.

Bad usability design by me especially in context of blocking networking until sdwdate finished.

Do you see the case for waiting randomized minutes and nanoseconds to improve anonymity (to avoid being detected as Whonix / sdwdate users) by avoiding predictable traffic between sdwdate time fetches?

On success sdwdate is currently waiting randomly between 60 and 180 minutes. (Plus always randomized nanoseconds.)

On error (even at first boot!) sdwdate is currently waiting between 5 and 15 minutes.

What about not waiting at all in case of error? Consequences:

  • possibly continuous traffic to onion time sources
  • predictable traffic?
  • sdwdate log size ever increasing (but could find a solution maybe)

Maybe on error wait between 0 and 10 seconds? Or between 5 and 15 seconds? Or between 5 and 60 seconds? Or…?

//cc @HulaHoop

No - as network observers outside Tor are not in a position to perform traffic analysis at this level and if you have a malicious guard you are vulnerable to a lot more attacks than them knowing you use Whonix.

I’m in favor of eliminating the delays and making it perform the checks immediately to improve response time especially with the blocking until sync feature.

1 Like

HulaHoop:

No - as network observers outside Tor are not in a position to perform traffic analysis at this level and if you have a malicious guard you are vulnerable to a lot more attacks than them knowing you use Whonix.

Imagine an idle Whonix-Gateway. Not issuing any traffic. But predictable
every “33” minutes it issues traffic. Since Tor does not use any
padding… That would at least be ground for suspicion that
Whonix/sdwdate is in use?

I’m in favor of eliminating the delays and making it perform the checks immediately to improve response time especially with the blocking until sync feature.

How many retries? Infinite retries? Perhaps increased waiting time with
ever failed attempt to save traffic?

(Until some maximum waiting retry time is reached. Meaning, wait maximum
5-10 minutes before next attempt or so after 10 failed attempts.)

Tor cells are fixed size so completely opaque to an outside observer. Tor has recently gained padding inside the network but its a multi-part project and some parts of the implementation are being worked out. There is always some form of communication between the client and relays even when idle - whether closing circuits or switching. There is no reason to worry about it being a problem.

Three successive retry attempts before checking at the next time interval that its currently programmed to do - so as to not overload the network or use up resources.

1 Like

Bunch of commits to master done.

Retry logic changes:

  • The first 3 retry attempts wait less than 1 second.
  • wait minimum: retry_on_error_counter multiplied with 1
  • wait maximum: retry_on_error_counter multiplied with 5

For example after 5 retries

  • wait minimum: 5 multiplied with 1 = 5 seconds
  • wait maximum: 5 multiplied with 5 = 25 seconds

So wait a random amount between 5 and 25 seconds. (Plus nanoseconds randomization in any case.)

But there is also a “wait maximum maximum” of 180 * 60 seconds (180 minutes).

How does that sound?

Any idea what is causing this / what is so special about that use of kdesudo?

Upgrade for non-qubes sdwdate-gui.

  • same menu as sdwdate-gui-qubes in Whonix-Gateway
  • same menu minus Tor actions in Whonix-Workstation
  • the sdwdate/tor status message popup is updated too.
1 Like

Sorry for the delay in reviewing this. python isn’t my strong skill and this is quite difficult stuff for me. I am finally on it now though

sdwdate_gui.py

It changes from
## Copyright (C) 2015 - 2018 ENCRYPTED SUPPORT LP <adrelanos@riseup.net>
to
## Copyright (C) 2015 - 2017 Patrick Schleizer <adrelanos@riseup.net>
so I wonder if it was based on an older revision?
Wondering if some of the smaller bug fixes I introduced got lost in the process?

Could you please try git merge origin/master?

Not sure that was a typo. & launches the process into the background.


Did you try…?

/usr/share/sdwdate-gui/unit-test/fuzzer

This enhancement got lost.

/usr/lib/sdwdate-gui/log-viewer

Not sure which version of restart_sdwdate is the correct one.

    def restart_sdwdate(self):
        if self.tor_status == 'running':
            if os.path.exists('/var/run/sdwdate/success'):
                Popen('sudo --non-interactive rm /var/run/sdwdate/success', shell=True)
            Popen('sudo --non-interactive systemctl --no-pager --no-block restart sdwdate', shell=True)
    def restart_sdwdate():
        Popen('sudo --non-interactive /usr/lib/sdwdate/restart_fresh', shell=True)
        Popen('sudo --non-interactive systemctl --no-pager --no-block restart sdwdate', shell=True)

Taking the latter.

Why would should sdwdate only be restarted if Tor is running? if self.tor_status == 'running':
Otherwise silently ignored? Doesn’t look right.

sudo --non-interactive /usr/lib/sdwdate/restart_fresh gives us more flexibility and keeps it out sdwdate-gui.

Using this branch now:

Could you please have a look if this makes sense?

def stop_sdwdate(self):
    if self.tor_status == 'running':
        Popen('sudo --non-interactive systemctl --no-pager --no-block stop sdwdate', shell=True)

Why stop sdwdate only if Tor is running?

Few more minor commits to that branch.

sdwdate-gui (non-Qubes)

  • exit menu entry missing
  • left click does no longer show popup?
  • starts with Unexpected error: <class 'NameError'> but otherwise working
sdwdate-gui
+ set -e
+ command -v kdesudo
/usr/bin/kdesudo
+ command -v /usr/lib/sdwdate-gui/sdwdate-gui
/usr/lib/sdwdate-gui/sdwdate-gui
+ id sdwdate-gui
uid=122(sdwdate-gui) gid=129(sdwdate-gui) groups=129(sdwdate-gui)
+ kdesudo -u sdwdate-gui /usr/lib/sdwdate-gui/sdwdate-gui
kdesudo(10672) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display  ":0" 

Unexpected error: <class 'NameError'>

I see if caller == 'tor': and elif caller == 'sdwdate': but where caller gets set? Can’t find any caller =?

I was hoping to introduce this in Whonix as soon as possible but due to missing dom0 policy files it will be postponed 10-14 days I expect until it reaches Whonix stable-proposed-updates.

Until then we can’t start sdwdate-gui-qubes by default since the dom0 qrexec prompt would confuse too many users.

I was wrong. Already available from Qubes testers repository. As a side effect. Due to add Qubes-Whonix tags on domain-load rather than VM creation time to avoid missing tags for users that upgraded · Issue #4094 · QubesOS/qubes-issues · GitHub Marek made an upgrade. Can be tracked here when it enters Qubes stable repository.

Merged into master. Excellent work!

It’s now in Whonix testers repository.

Testers welcome! //cc @nurmagoz

1 Like

Merged your commits.

Testing in Whonix-Gateway (VirtualBox).

The line if self.tor_status == 'running': is not necessary, but does it make sense to restart sdwdate when tor is stopped? Any how, minor.

Yes. ⚓ T534 make sdwdate-gui Qubes friendly (sdwdate-gui-qubes)

sdwdate-gui (non-Qubes)

  • exit menu entry missing
    That is on purpose. It was left for testing or debugging. The question is, once sdwdate-gui is thoroughly debugged, do we still want it? It is just commented.in the code.

  • left click does no longer show popup?
    It does, on the second left click, or randomly on the first one, for an obscure reason seemingly created in KDE5, one among other annoying issues.

  • starts with Unexpected error: <class 'NameError'> but otherwise working
    I could not reproduce this one.

The call is done in lines 186 and 215. update_tip('_caller_') runs show_message('_caller_'), which then runs run_popup('_caller_'), under conditions.

This code could be simplified, but I remember trying a couple of times, without much success.

1 Like

Yes.

Yes.

I’d like to say that when installing sdwdate with --no-install-recommends (I don’t like the KDE dependencies) the python3.stem module doesn’t get installed and borks everything. Maybe that should be a required package?