- User Since
- Jun 8 2015, 12:40 AM (189 w, 3 d)
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 2 2018
I'd guess breeze-icon-theme.
Do you have non-qubes instance to compare?
whonix.onion links looks invalid (I know what you meant...)
Jul 18 2018
Jan 29 2018
Json handling looks fine. Not sure about using the data loaded from there - for example if self.message require sanitization. AFAIR some Qt widgets support html formatting, so it may be undesirable to allow that.
Jan 26 2018
Jan 22 2018
Obviously they'll have to be in sdwdate. They are some issues regarding the format of the argument in qrexec-client-vm sys-whonix whonix.test+"[argument]" when it reaches the target vm. It's sanitized, no problem there, it can be parsed, but it's truncated at 51 bytes, which limits what we can pass.
Jan 12 2018
Nov 9 2017
Well, google is going to deprecate HPKP in chrome/chromium.
Nov 3 2017
VM do not need to be a ProxyVM or have provides_network=True to serve as updatevm on Qubes 4.0. You just need to start updates proxy there (tinyproxy, enabled with qvm-service --enable vmname qubes-updates-proxy), and just qrexec policy of qubes.UpdatesProxy to direct the traffic there.
Oct 29 2017
(highest available version is 3.2.18-1+deb9u1)
Oct 28 2017
Will that really works for 4.0? There is also qubes-gui-agent package, so it isn't clear to me that pulseaudio-qubes will really be installed. Perhaps pulseaudio-qubes | qubes-gui-agent (<< 4.0.0)?
Oct 20 2017
Is that changing to 127.0.0.1 work on Qubes 3.2? Anyway, yes, it should be good enough for Qubes 4.0.
sys-whonix is started by first request to updates proxy (if not already running). In most cases it will be that connectivity check. I think connect timeout doesn't matter here, as connection (in terms of TCP) is to localhost, instant. Only the response comes later.
I guess the problem is that the warning is displayed, while the connectivity check is still running (i.e. race condition). Since sys-whonix takes some time to start, it happens reliably. Maybe some dependencies between those services would help (is it possible to order GUI application after system service startup?). Or some lock file to synchronize those things?
If none of above is possible, some solution would be ordering connectivity check with Before=qubes-gui-agent.service. But I'd treat this as last resort.
Oct 8 2017
Just setting tbb_version or tbb_hardcoded_version variable isn't enough, because it isn't propagated through all the layers to postinst of tb-updater. But creating temporarily a configuration file works (in /etc/torbrowser.d).
Use tbb_version there, because tbb_hardcoded_version is unconditionally overridden by /usr/share/tb-updater/tbb_hardcoded_version. But later is ignored if tbb_version is already set.
Oct 7 2017
The problem is back again, 7.0.4 is no longer available at https://dist.torproject.org/torbrowser/
What is the easiest/elegant way to choose different version, without modifying tb-updater package? Some env variable? Some config file? I don't consider https://github.com/SimonSelg/qubes-template-whonix/blob/SimonSelg-fix-tb-updater/whonix-gateway/04_install_qubes_post.sh#L65-L79 elegant...
Sep 26 2017
Sep 24 2017
As for policy for updates proxy, see this: https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/commit/977362ee27ccc116512fc428c0807063600655cc
Sep 20 2017
Since https://github.com/Whonix/qubes-whonix/commit/01964e3c8c53b49aa14e56f7924fce5e88b5a448, other places can simply source /usr/lib/qubes-whonix/utility_function.sh and use PROXY_SERVER variable to get appropriate proxy address.
Sep 14 2017
qubes-devel discussion: https://groups.google.com/d/msgid/qubes-devel/0f80b2a7-af84-fe3c-db9b-5d9bbeedfea6%40riseup.net
Sep 12 2017
Sep 11 2017
Note that I've created PR against Whonix13 branch instead of master intentionally. While it should be mergeable to master too, it would be good to have it in Whonix13. The current version from master branch is already incompatible with Whonix 13.
According to debian policy, << is the syntax for "strictly older than".
Aug 26 2017
Yes, it works now: https://travis-ci.org/marmarek/qubes-template-whonix/builds/263033873
Aug 25 2017
The idea was to keep X newest entries. not oldest, right? So the first order is right (the code skip X "first" directories). Also, I'd trust more file names, not modification time - the later is easy to mess up (and a consequence will be removing wrong directory - possibly containing just modified data).
Aug 15 2017
I've tried glob, but I need reversed order and failed to do that with glob. ls -dr should do. Unless $tb_browser_folder itself contains spaces...
Aug 12 2017
Proposed fix here: https://github.com/Whonix/tb-updater/pull/1
Aug 10 2017
Indeed, TEMPLATE_OPTIONS variable wasn't properly propagated. Fixing this fixes whonix-gateway build:
Aug 9 2017
Also, it worked before (when tor browser 7.0 was still downloadable)... See builds history on travis (https://travis-ci.org/marmarek/qubes-template-whonix/builds).
In above linked travis job, workstation build (17.6) fails with:
(Debugging information: curl_status_message:  - [HTTP page not retrieved. The requested url was not found or returned another error with the HTTP error code being 400 or above. This return code only appears if -f, --fail is used.])
Probably package installation order is non-deterministic here...
Are you sure about that? According to build log, the issue with whonix-ws is missing 7.0.0 version on server. anon-gw-dns-conf is not installed in whonix-ws
Ah, you're right. So the second line in my comment _is_ a blocker too.
I prefer the proper fix, which is a chain of three tickets in total: https://phabricator.whonix.org/T671#14310
Independently (not a blocker), it would be good to find out why tb-updater is installed in whonix-gw.
Aug 7 2017
What exactly is the use case when removing old /var/cache/tb-binary/.tb/tor-browser.old.* is bad?
IIUC this ticket is blocking tb-updater stable upgrade (T690), which would fix qubes-whonix build failure (T710). Which is a blocker for having Whonix templates for Qubes 4.0.
Jul 30 2017
What does it mean in practice?
Also "Couldn't resolve host" doesn't look like file removed from torproject's download server...
Jul 29 2017
Jul 7 2017
Yes to both of you:
- should just work on Qubes 4.0 (savefiles are not used there anymore)
- calling qubes.GetRandomizedTime as post-suspend action would fix that too
Jul 4 2017
Jun 8 2017
Looks like at least NTP and chrony use ntp_adjtime/adjtimex
Jun 7 2017
adjtimex/ntp_adjtime looks quite complex, but also allow precise control on how time should be adjusted. From those two, according to manual page ntp_adjtime is preferred.
Jun 5 2017
I've left you some minor comments here: https://github.com/JasonJAyalaP/sclockadj/commit/e9bf84e3a400f7a8ef01e5f00dcefc013d0a9efe
What about using adjtime() syscall instead of all this? It would avoid trashing logs with Time has been changed every single second, and possibly other side effects.
May 20 2017
Well, if you explicitly type/paste "https://" in the url, sslstrip and
similar do not apply. But very few people do that, most follow some
link, or type just "www.torproject.org" instead of
Apr 14 2017
Apr 13 2017
What about hiding sdwdate-gui icon when time is synchronized? So, have an icon only when there is some problem or sdwdate is still bootstrapping? This isn't ideal as actions like restart/stop will be unavailable, but maybe good enough for now?
I'm not sure about sdwdate-gui details, but could it be started in a mode without tray icon and only show notifications? Maybe also make sure that notifications do not expire until sdwdate succeed. Or maybe hide tray icon when time is synchronized?
Those should be much easier to do than full T534.
Mar 16 2017
Can't find what debian package ship debug symbols, there is no -dbg package there: https://packages.debian.org/source/stretch/ruby2.3
Ah, it's ruby... So, python-dbg is irrelevant, but trying gdb may still be a good idea.
I don't see any loop there and only very simple function calls, so I don't see how that would trigger such bug...
Mar 5 2017
@marmarek If the problem is only with applications listening on both AF_INET and AF_UNIX,
Mar 1 2017
Also, Python >= 3.4 comes with great API for concurrent execution - asyncio - much more powerful version of asyncore. In this case it could be used to avoid threads at all. But I'm still learning how to use it... You may want to read/watch this: https://fosdem.org/2017/schedule/event/python_coroutines/ if you want quick intro.
Where the other thread is created? For me it looks like get_time_from_servers is running in the main thread, so simply not catching SystemExit should be enough. At the point where it was raised, you already called sys.exit (which is how SystemExit is raised), so exit_handler was already called.
Feb 23 2017
The problem is not in connect function, but in bind. It assume AF_INET family, casting sk pointer to struct sockaddr_in. But if socket family is something different, the structure also may be different (for example struct sockaddr_un for AF_UNIX). In practice, besides misusing this library, the problem only applies to applications listening on both locak (AF_UNIX) and network (AF_INET) sockets. Because you don't use this library for AF_UNIX-only applications.
Feb 20 2017
Slightly reduced duplication:
if [ -z "$XDG_CONFIG_DIRS" ]; then XDG_CONFIG_DIRS=/etc/xdg fi export XDG_CONFIG_DIRS=/usr/share/kde-dolphin-menubar-enable/:$XDG_CONFIG_DIRS
Try adding the default value too (/etc/xdg).
Jan 30 2017
Related: https://github.com/QubesOS/qubes-issues/issues/2572 (meta-packages for Qubes)
As for the above list:
- drop all notification-related packages - those are not up to qubes-whonix
- gnome-*, network-manager* - should be moved to some qubes-metapackage (recommended flavor, probably not installed in Whonix)
Please note that Qubes 4.0 will use nftables (if available):
Jan 21 2017
Perhaps it's better to implement this rather minimally inside the https://phabricator.whonix.org/tag/qubes-whonix/ package? A simple one socat listener port 9050 only redirection from whonix-gw TemplateVM to sys-whonix?
Jan 19 2017
What about tor-over-tor issue here? And starting tor in template by having apt-transport-tor installed? Are those issues mitigated somehow else?
Jan 11 2017
Jan 6 2017
Dec 24 2016
The above application grabs the input device, randomly delays the key
events, and writes the events to a user-level input device via uinput.
Dec 23 2016
What about retrying qubes-whonix-torified-updates-proxy-check.service on
Dec 19 2016
Oct 6 2016
Actually the later is also done (slightly differently - see my comment there).
Default static firewall (blocking INPUT etc) still uses iptables, but it doesn't matter on Whonix, since it uses its own version. Dynamic part (qubes-firewall service) use nftables (when installed) and should not interfere with other firewall rules.
Sep 27 2016
Sep 23 2016
On Qubes it results in kernel message: sysrq: SysRq : This sysrq operation is disabled.
Default value of /proc/sys/kernel/sysrq on Qubes dom0 is 16. Changing to 1 does not work either:
[1363616.422789] sysrq: SysRq : Power Off [1363616.423456] xenbus: xenbus_dev_shutdown: backend/console/1069/0: Initialising != Connected, skipping [1363621.427069] xenbus: xenbus_dev_shutdown: backend/vbd/1069/51760 timeout closing device [1363626.430065] xenbus: xenbus_dev_shutdown: backend/vbd/1069/51744 timeout closing device [1363631.434062] xenbus: xenbus_dev_shutdown: backend/vbd/1069/51728 timeout closing device [1363636.437593] xenbus: xenbus_dev_shutdown: backend/vbd/1069/51712 timeout closing device [1363636.437595] xenbus: xenbus_dev_shutdown: backend/console/1068/0: Initialising != Connected, skipping [1363641.441056] xenbus: xenbus_dev_shutdown: backend/vbd/1068/51760 timeout closing device [1363646.443064] xenbus: xenbus_dev_shutdown: backend/vbd/1068/51744 timeout closing device [1363651.446038] xenbus: xenbus_dev_shutdown: backend/vbd/1068/51728 timeout closing device [1363656.447016] xenbus: xenbus_dev_shutdown: backend/vbd/1068/51712 timeout closing device [1363656.447016] xenbus: xenbus_dev_shutdown: backend/console/1067/0: Initialising != Connected, skipping [1363661.448050] xenbus: xenbus_dev_shutdown: backend/vbd/1067/51760 timeout closing device [1363666.451077] xenbus: xenbus_dev_shutdown: backend/vbd/1067/51744 timeout closing device [1363671.454069] xenbus: xenbus_dev_shutdown: backend/vbd/1067/51728 timeout closing device [1363676.457060] xenbus: xenbus_dev_shutdown: backend/vbd/1067/51712 timeout closing device [1363676.457118] xenbus: xenbus_dev_shutdown: backend/console/711/0: Initialising != Connected, skipping [1363681.460065] xenbus: xenbus_dev_shutdown: backend/vbd/711/51760 timeout closing device
And finally shutdown after timing out for every VM - 20s per VM. Not good, at least.
Sysrq-c makes dom0 frozen for some time (5s?) and then reboots. Also after changing sysctl setting.
Sep 21 2016
nc connection to cpfpy no longer works. (Should work, because it also works with real Tor Control Port.)
I'm on it.
Sep 19 2016
Sep 18 2016
Working on it, will push something in half an hour.
Sep 17 2016
Commented in that last commit. Generally looks good. Few things to consider:
- switching to asyncore completely - even for handling new incoming connections, replacing StreamServer - not sure if worth the effort, but will make the code even cleaner. Generally better use one API for handling sockets at the time.
- filtering responses (is it needed?)
Sep 16 2016
I'd expect some more problems, but nothing serious. For example CUPS may
Network shouldn't be needed for GUI applications as long as DISPLAY
environment variable is correctly set. Make sure it's :0, and not
Aug 3 2016
I'd expect that PV VM can't control c-states, so on Qubes it will not be
that simple, at least in default configuration. But worth a try.
Aug 1 2016
In the failed one (job #13.5)
For 3.1 - yes, this is expected, qubes-core-agent package currently is available only in testing repository (will be in stable in two days) - https://github.com/QubesOS/qubes-issues/issues/2205
It means the service will not be stopped at VM shutdown. In case of
firewall indeed it may be ok, but for network setup I think it may be a
Jul 31 2016
In Qubes (or Xen in general), VM cannot disable c-states. This is possible only from dom0. Using this command (at every system startup):
xenpm set-max-cstate 0
There is probably also Xen command line option for this, but as you've pointed out, it's easier to maintain a command running at startup.
Jul 30 2016
I think that's fine. Because it serves very similar purpose as
networking.service. But this alone probably will not fix all the
problems, as it will have the same dependencies, which are added using
user@host:~$ systemctl status networking ● networking.service - LSB: Raise network interfaces. Loaded: loaded (/etc/init.d/networking) Drop-In: /lib/systemd/system/networking.service.d └─40_qubes.conf /run/systemd/generator/networking.service.d └─50-insserv.conf-$network.conf /lib/systemd/system/networking.service.d └─network-pre.conf Active: inactive (dead) start condition failed at Tue 2016-07-26 22:45:03 UTC; 3 days ago ConditionPathExists=!/usr/lib/qubes-whonix was not met
Jul 29 2016
Hmm, this is all strange. As you can see in the build log, I've build from https://github.com/marmarek/qubes-template-whonix, master branch. And there I see WHONIX_APT_REPOSITORY_OPTS ?= stable
Is this setting ignored?
Apparently network-pre.target is implicitly ordered before basic.target, which is automatically added (as After=) by DefaultDependencies=yes. Which would mean that any service with Before=network-pre.target also needs 'DefaultDependencies=no`.
I can't find any other example with Before=netowork-pre.target, but all the units I can find on Debian with Before=network.target also have DefaultDependencies=no. On the other hand, on Fedora I see multiple services with Before=network.target, but with DefaultDependencies=yes, so this looks like something Debian-specific. I guess it's about networking.service:
$ systemctl show networking.service |grep 'After=\|Before=\|DefaultDependencies=' Before=sysinit.target shutdown.target network.target After=mountkernfs.service local-fs.target systemd-random-seed.service network-pre.target systemd-journald.socket system.slice DefaultDependencies=no
This impose ordering: networ-pre.target -> networking.service -> sysinit.target (which is before basic.target).
I have no idea whether it is some design decision, or unexpected side effect...
Jul 28 2016
R3.2-rc2 is already released...
But - the whole thing applied only to workstation template - gateway build was ok and new one is included there - I've just checked and it has legacy function in /usr/lib/qubes-bind-dirs.d/41_qubes-whonix.conf.
Maybe nothing pulls in network-pre.target? I think network-pre.target is only for ordering, not for starting services (so, only After= or Before= dependencies, but no WantedBy=). Generally quite good description is in systemd.special man page.