Hello everyone.
Am I the only one getting the message “Whonix 17 deprecated”-alike while starting template, or it’s dvm’s dispvm?
I tried in-place upgrade, which went ok, but now getting error “Denied sdwdate. ConnectCheck from dispvmxxx to sys-whonix”.
Any feedback?
There is no Whonix 18 yet, so what/how did you upgrade?
What’s the exact message?
You’re probably using the developers repository - don’t.
Impact: Breaks sdwdate-gui: Secure Distributed Web Date Graphical User Interface.
To silence that error, run…
In Template:
sudo systemctl mask sdwdate-gui-qubes-proxy-helper.service
Indeed.
Once available it will be announced in the usual places. (Follow Whonix Developments)
related:
Primarily, pull request QubesOS/qubes-core-admin-addon-whonix#21 has been merged for Qubes R4.3 but we didn’t backport it to Qubes R4.2 yet.
This would cause qrexec
sdwdate.ConnectCheckdenied messages on Qubes R4.2.
Thanks for the feedback, @adrelanos. In addition, for some weird reason. when I try to update Whonix 17, qubes-contrib repo goes to trixie, instead to stay on bookworm…
What are the consequences of silencing that notification? Any security related?
.
Thanks. I did read the topic, but what I’m not comprehending is does it just blocks gui, or service itself… I’d like to know in general, not strictly related to this specific issue that caused the message about denying sdwdate. On the other hand, the message is pretty self-explanatory: sdwdate is denied to check the connection, as it is written…
It breaks sdwdate-gui. End of story.
sdwdate.ConnectCheck is implementd in sdwdate-gui package only.
Calling the qrexec service sdwdate.ConnectCheck instead of sdwdate-gui.ConnectCheck can be considered a minor bug.
You can Search the Source Code for file or string sdwdate.ConnectCheck.
It looks sometimes it’s just easier to ask AI:
In Qubes/Kicksecure/Whonix, sdwdate-gui-qubes-proxy-helper.service is not the actual time‑syncing logic — it’s the little helper that lets the sdwdate service in a qube send its status to a GUI indicator in another qube (usually sys‑whonix) via Qubes’ qrexec messaging.
What systemctl mask does here
Masking a unit in systemd means it’s replaced with a symlink to /dev/null.That prevents it from being started at all, manually or automatically.
In this case, you’re preventing the GUI proxy helper from ever running.
Consequences of masking this service
You will no longer get sdwdate status notifications in the Qubes panel/tray for that qube.The underlying sdwdate service (the one that actually fetches and sets the time over Tor) will still run normally — masking the GUI helper does not stop time synchronization itself.
No direct security loss from masking the GUI helper — the secure time‑sync still happens if sdwdate.service is enabled and running.
The risk is indirect:
If sdwdate fails for some reason, you won’t see the warning in your panel.
That means you could be unaware of a time‑sync failure, which in Whonix/Kicksecure can affect Tor circuits, certificate validation, and some anonymity protections.
Bottom line
Masking sdwdate-gui-qubes-proxy-helper.service only silences the GUI notifications — it does not stop the actual secure time sync.Security impact: only that you lose the visual alert if time sync fails. If you’re disciplined about checking systemctl status sdwdate or logs manually, you can live without the GUI.
If you want to stop time sync entirely, you’d have to disable/mask sdwdate.service itself — which is not recommended unless you have another trusted time source (like a ClockVM).
