[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

sdwdate and sdwdate-gui development thread


#221

#222

Merged sdwdate python branch into master.


#223

Merged.

(But your branch is behind now. Please fetch/merge before making new changes.)


#224

Merged Whonix branch.

Removed usr/share/test_d_files.

Cherry picked sdwdate pool configuration.

About

Conflicts:
usr/lib/sdwdate/modules.d/sdwdate

it was removed early in the development of the python branch.


#225

But in the wrong branch. Let’s move on to the sdwdate master branch.
Please checkout master, merge origin/master, and apply your work on top
of the master branch.


#226


That’s a solution to get sdwdate-gui shown in all environments.

There is a subsequent commit for running sdwdate-gui as sdwdate.

A question about NotShowIn=QUBES. according to freedesktop.org, the string should exist in a variable XDG_CURRENT_DESKTOP. Cannot find it in the environment.


#227

Why do we need etc/xdg/autostart/sdwdate-gui-other.desktop?

Does Exec=kdesudo /usr/bin/sdwdate-gui fail in Non-Qubes-Whonix?


#228

Yes, it pops up a gui asking for the password.


#229

That’s why xhost +local:root was implemented first hand.


#230

How does Qubes prevent this?
And can we implement the same solution in Non-Qubes-Whonix?


#231

As far as I can see, whonix-gw and whonix-ws terminals are passwordless (sudo or kdesudo never prompt for a password). Guessing we would have to implement the same in non Qubes-Whonix.


#232

(https://github.com/Whonix/whonix-setup-wizard/blob/master/etc/sudoers.d/whonix-setup-wizard vs https://github.com/troubadoour/sdwdate-gui/blob/master/etc/sudoers.d/sdwdate-gui)


I am not sure anymore. Did we suppose to run sdwdate-gui as user sdwdate?

Please try.

kdesudo -u sdwdate /usr/bin/sdwdate-gui

That should work everywhere. Including without password in Non-Qubes-Whonix. I think we can make kdesudo work without password in Non-Qubes-Whonix somehow.


#233

That works everywhere, don’t know what went wrong in my previous tests.


#234

I should re-read myself. In Qubes,

2 - if started as user sdwdate, a d-bus error pops up.

Client failed to connect to the D-BUS daemon:
Failed to connect to socket /tmp/dbus-xxxxxxxxx: Connection refused

We may have run sdwdate-gui as root.


#235

Not so quick. If there is such an issue in Qubes, we should make sure it’s already been reported or at least report before we add the workaround.

@marmarek any idea about this?

Perhaps this issue is similar to this one:
https://phabricator.whonix.org/T424
?


#236

I did find something (forgot to bookmark) about the dbus connection refusal related to starting a program as a different user.


#237

kdesudo -u sdwdate /usr/bin/sdwdate-gui also fails for me in a Qubes Debian VM also.

kdesudo(14366) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display  ":0" 


(process:14375): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Failed to connect to socket /tmp/dbus-JvqUfOKDDa: Connection refused

So for now this issue isn’t releated to /etc/xdg/autostart. Investigating…


#238

That error happens in Qubes Debian VMs, but not in Non-Qubes-Whonix. I try reproduce with something simpler.


#239

Do you have $DBUS_SESSION_ADDRESS set in that environment?


#240

Doesn’t look like.

env | grep -i DBUS
KONSOLE_DBUS_SERVICE=:1.16
KONSOLE_DBUS_WINDOW=/Windows/1
KONSOLE_DBUS_SESSION=/Sessions/1