@Patrick No biggie wrt the paid developer to implement. I like your idea on the Qubes GitHub ticket, of posting an article on the website. I'll email you separately, to coordinate on that. Said website post, I'd like to accomplish two things: one, solicit user input on any/all UX work. Two, put out the call for paid GUI dev work.
May 19 2020
May 14 2020
ninavizz (nina eleanor alter):
ninavizz added a comment.@Patrick I am currently working on a funding proposal, to get the UX work required to get production-ready handoffs to a developer, created.
May 13 2020
@Patrick I am currently working on a funding proposal, to get the UX work required to get production-ready handoffs to a developer, created. The above was just a shared idea, to kickoff the conversation. My apologies for not being clear on that. I would like to work on a parallel proposal to get the development work done, to improve all of the Whonix GUI stuff; the time-sync widget menu, and the windows that enable deeper settings control.
I am not a GUI developer at this point so please don't wait for me to implement this. sdwdate-gui is from a time when Whonix had a contributor doing GUI development.
Apr 16 2020
Feb 16 2020
So... keeping an eye on user-needs as the priority driving this story: the list of "What needs doing" is ordered, below, as I see it:
Dec 23 2019
Nov 6 2019
This was done. If not, please create specific tickets where it isn't done.
Jun 14 2019
Apr 14 2019
Apr 12 2019
Apr 6 2019
Dec 7 2018
Oct 1 2018
Sep 20 2018
Sep 18 2018
Actually, the "apt-daily.timer: Adding 1h 17min 24.927437s random time" message have real impact, not only noise. Each time sdwdate change time, systemd adds a random delay to those timers. which means the timer will never expire (unless that random delay will happen to be very close to 0 - i.e. below the time until sdwdate change the time, which looks to be 1s).
Sep 12 2018
Sep 11 2018
Aug 15 2018
Aug 7 2018
In theory, we could make sdwdate provide a local (default) (or optional opt-in server) NTP compatible time provider. Could be useful anyhow. -> sdwdate-server No idea how hard that would be.
And then configure NTP to connect only to that local NTP server.
Aug 6 2018
/usr/sbin/ntpdate as far as I know doesn't accept a command line command to take an offset (or anything). It connects to remote servers in its default design.
Yes, not readily accessible from command line.
The easy way: calculating the offset between local time and the onion average in timesync then using ntpdate's slew option if the offset is less than 0.5s. Otherwise you tell it to step up the time immediately so that you are accurately mimicking the default behavior. However you can force slewing all the time with -B. This way you won't need to touch kernel syscalls as ntpdate should be able to do the operation for you.
From what I understand, this code path is only relevant when timesyncd is talking directly with NTP servers and reacting to replies about deltas between local and remote times. There is no way you can call that function from the command line when using timedatectl standalone AFAICT.
Aug 5 2018
Jul 27 2018
Since we are interested in ntpd's default behavior (for blending in purposes) it turns out that it performs instant clock jumps once the delta difference is excessively large otherwise its slewing algorithm would take forever to adjust the time.
It doesn't seem that timedatectl supports gradual time adjustment. Our next best option is ntpd which can do so but cannot coexist with timedatectl - we can only run either but not both. According to popcon, ntpd is the mos widely used time daemon so its the natural choice.
Currently time is set using gnu date (clock jump) (initial run after current boot) or sclockadj (consecutive run) (slow clock adjustment).
Jul 25 2018
the time could be set with timedatectl by feeding it the time with this command:
Stretch+ uses systemd-timesyncd by default therefore its the most popular.
This is sorted in a later version of systemd.
sclockadj3 is done -> T686.
Jul 24 2018
Jul 21 2018
Jul 18 2018
The easiest way would be to have a new entry for qubesdb-read, in addition to qubes-gateway which holds the IP address.
Something like qubesdb-read /qubes-gateway-name.
Jul 17 2018
For the time being, the vm's whonix gateway is hard coded in two files, the one watching and sending sdwdate satus and the one sending the shutdown notification.
What happens in case of multiple Whonix-Gateway ProxyVMs? I.e. in case of sys-whonix, sys-whonix-two, etc.? How would anon-whonix-two know it has to connect to sys-whonix-two?
Jul 9 2018
From sdwdate log. Clock was right but I got this using a bridge.
Jul 7 2018
Have run the fuzzer unit test simultaneously in sys-whonix and five anon-vm.
Jul 5 2018
Update, after my post in the forum.
Mar 11 2018
Mar 7 2018
Mar 5 2018
Mar 4 2018
A new Tor controller GUI.
Mar 1 2018
NB for the record: with qemu-ga a guest can still shut itself off via crafted input to the agent. So besides removing timer access to the guest, there was no other advantage to removing ACPI.
Actually we don't have to suspend the guest. Execution of any command on the host after resume is enough to create a uniqu event in the qemu-ga's log file.
The proper and direct way to use virsh to communicate with guest agent:
The YAJL parser used in libvirt is tiny, modern (written in2007) and has no CVEs. It is an SAX type event-driven parser unlike the vulnerable, top-down recursive descent type that was used in QEMU.
Feb 28 2018
It turns out the QEMU guest agent warning was not relevant to those who use libvirt. With libvirt a safe parser is used. Breakouts can only happen if a process on the host is designed to parse guest input because there is no way to control that otherwise it should be safe for our uses. This potentially simplifies the design in many respects but a host package will still be needed. I will update the task list.
[libvirt-users] QEMU guest-agent safety in hostile VM?
Feb 16 2018
Added the relevant icon in show_message (after resizing the sdwdate icons from mediawiki, the original are huge).
Feb 15 2018
Some progress here.
Feb 14 2018
Yes there are less moving parts especially when multiple WSs share a GW. Some way to exempt timesync traffic from the WS would be needed though.
Feb 12 2018
HulaHoop added a comment.
With qemu-ga code the whole clock drift detection code becomes redundant. If a
suspend event is triggered the GW should assume clocks are out of sync and
With qemu-ga code the hwclock drift detection code becomes redundant. If a suspend event is triggered the GW should assume clocks are out of sync and trigger lockdown.
Oops didn't realize ntpdate requires query of remote servers. ntpdate is obsolete anyhow but the newer clockdiff still talks to online servers instead of comparing local values. hwclock can give us that:
It's a very good rehash!
Feb 11 2018
@Patrick I wrote a rehash. If you think is too complicated, let me know. It was the simplest and most reliable way I could think of:
Feb 4 2018
If possible: it should only show Tor restart gui / anon-connection-wizard if these are installed. Otherwise not show such a menu entry.
Have pushed an updated version with Restart Tor and Anon Connection Wizard commands from the menu, so you can have an idea of the look and feel. This is of course not written in stone. The standalone restart-tor-gui was updated for testing. https://github.com/troubadoour/restart-tor-gui
Implemented some defensive code against qubes-dband qubes-qrexec-agent just in case. Now if one or both of those services stop, it just ensures that the sdwdate-gui programs don't crash, and that's it.
Didn't rehash. What's next here? Looks like we learned a lot, but then things stalled. Could you please rehash, and then create a follow-up ticket with the way forward? @HulaHoop