- User Since
- Jun 8 2015, 12:40 AM (252 w, 1 d)
Fri, Apr 3
qvm-prefs -D sys-whonix ip
Dec 11 2019
It looks like bpfilter is in rather early stages, and it's few years until we'll see it in Debian.
Sep 27 2019
Jul 21 2019
Sounds good, thanks.
Does lowering "severity could be lowered to "info" and not causing non-zero exit codes" + `journalctl -p err -b` sound like a good solution?
Jul 16 2019
Jul 15 2019
Can you give some more context here? Is it the problem that user is created too early (before /etc/skel is fully populated)? Or is it a problem that it's created at all? Should there be a difference between Qubes and non-Qubes case?
Jul 6 2019
It was copied from native setup_ip script, details here:
It definitely was relevant for old stubdomain hosting qemu (which is still possible to use in R4.0). Not sure if applies to new linux-based stubdomain.
It may be not needed anymore. To verify that, try removing those lines and check networking in Windows (or other OS without Xen PV drivers).
Jun 29 2019
Jun 27 2019
BTW it's certainly about fonts. here you can select whonix_firstrun-whonix-14-firstrun-20180915 from the dropdown above the screenshot (click eye icon at the right) and slide vertical bar to see old and new version.
Maybe different fonts installed? Is there a reason for fixed geometry of those widgets, instead of letting Qt figure it out based on the content? I suppose there may be more problems like this in the future. Especially if proper HiDPI support will come into play...
Jun 23 2019
How have you created sys-whonix? Default applications list is copied from template only at VM creation time. If you modify it (using VM settings for example), or just switch template, it isn't re-copied from template (it would break user's changes).
Jun 21 2019
It works for me (checked with qubes-template-whonix-gw-15-4.0.1-201906201340).
I cannot reproduce. I've installed qubes-template-whonix-15-4.0.1-201905241112, updated it with qubes testing repository enabled and I see all the actions available in thunar.
But I do see some warnings on thunar's stderr, like this:
(Thunar:27375): Gtk-WARNING **: 01:41:41.317: Refusing to add non-unique action 'uca-action-1507455450991127-4' to action group 'ThunarActions'
Looks like actions are added multiple times to /etc/xdg/Thunar/uca.xml, which is later copied to /home/user/.cnfig/Thunar/uca.xml. Relevant code in https://github.com/QubesOS/qubes-core-agent-linux/blob/master/debian/qubes-core-agent-thunar.postinst
Apr 18 2019
I suggest not permanent redirection, otherwise browsers may cache old version.
Apr 4 2019
This looks like focused on kernel protection from attacker having full user (or even root) access already. Something very desirable on server/multi user systems, but not so much meaningful in a single-user AppVM.
Also, disabling modules loading at all may break attaching devices (block, usb etc).
Other than modules loading, it shouldn't harm, though.
Feb 15 2019
To build a package with qubes-builder, you need to add Makefile.builder file with just one line: DEBIAN_BUILD_DIRS := debian. This will tell qubes-builder that given repository contains Debian package.
Alternatively, if that would be too much of a problem, it should be easy to add an option that do auto detection (probably just looks for debian directory).
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?)