{{Header}}
{{title|title=
ToDo for Developers
}}
{{#seo:
|description=TODO
}}
{{devwiki}}
{{intro|
TODO
}}
{{Developers-only}}
= TODO DEV =
== qubes-db versus API comment ==
* please comment regarding missing API event
** https://github.com/QubesOS/qubes-issues/issues/1447#issuecomment-3758939809
** In case, Qubes does lack an API event, if this can be phrased as a missing feature or bug, could you open a Qubes issue please and link to it?
* would it be useful if Qubes had an API that qubes-core-admin-addon-(kicksecure|whonix) packages could use?
** https://forums.whonix.org/t/qubes-4-2-4-3-whonix-17-18-denied-sdwdate-gui-connectcheck-from-anon-whonix-to-sys-whonix/22656
* Why would the following be required?
** https://forum.qubes-os.org/t/kicksecure-compatible-with-qubes/38917/8
qvm-tags sys-net add sdwdate-gui-client
qvm-tags sys-firewall add sdwdate-gui-client
qvm-tags sys-usb add sdwdate-gui-client
* Aaron: I think (?) most likely this is necessary if you switch sys-* to be based on Kicksecure, and then don't reboot or restart qubesd before trying to use them. qubesd should tag them otherwise. Already created AppVMs do "inherit" tags (not true inheritance, but rather tags being applied because of a kicksecure=1 feature or similar), but only when a domain-load event is sent, which happens at qubesd startup.
* Perhaps if qvm-tags were previously missing, an App Qube created, already created App Qubes do not inherit the qvm-tags even if the Template these App Qubes were based on got these tags? In other words "post App Qube creation qvm-tag inheritance from their Template". Would such an API event make sense?
** Aaron: We already have something akin to this, this is the mechanism in qubes-core-admin-addon-{kicksecure,whonix} that triggers on qubesd restart (domain-load events). I asked Ben if we could use domain-pre-start, which should remove the need for a qubesd restart.
* https://github.com/QubesOS/qubes-issues/issues/10645
== qubes-core-admin-addon-kicksecure StandaloneVM tagging issue ==
* the addon only checks if a VM's template has the kicksecure feature set, this will break for VMs with no template
== systemcheck - catch faults, killed processes ==
* add checks for 'fault', 'segfault', and 'killed'
* to catch bugs like https://forums.kicksecure.com/t/black-login-screen-crash-due-to-nouveau-gsp-killing-labwc/1556/7
== nvidia - research raw framebuffer driver ==
* nouveau is unstable on some NVIDIA hardware
* users may want to avoid proprietary drivers or may be unable to use them if they have an old enough graphics card
* determine if there is a working raw framebuffer driver for NVIDIA that we could offer as an option or possibly use by default
* we can provide NVIDIA driver configuration options in sysmaint-panel
== non-Qubes CLI version - zsh issue at first login ==
* file ~/.zshrc does not exist and zsh shows an unwanted greeting message
* this is zsh-newuser-install module (ideally we could get rid of that entirely)
/etc/zsh/zshenv
zsh-newuser-install() { :; }
* problem is maybe that pam_mkhomedir does not run (early enough) before login
== non-Qubes CLI version - systemcheck reports non-login environment at first login ==
* bug
== Whonix-Starter for Windows Improvements ==
* prettify a bit (start button is much too big)#
* fix (currently fails to start VMs)
== one-time popup support for passive popups ==
* one-time-popup (from msgcollector) currently only works with "invasive" window-style popups.
* passive popups can have buttons
* add functionality to one-time-popup that can create a passive popup with a "Don't show again" button
== bug: "Open in Folder" button in Tor Browser broken ==
* https://forums.whonix.org/t/is-catfish-the-new-default-in-the-qubes-domain-open-file-manager-quick-widget-for-whonix/20233/22
* Preferred fix: Get upstream to accept the needed components to allow pcmanfm-qt to be D-Bus activated (if those components aren't already there), add them ourselves for now or fix them if they exist and just aren't working
** Difficult, not supported yet, see https://github.com/lxqt/pcmanfm-qt/issues/2127#event-21832277851 and https://github.com/lxqt/pcmanfm-qt/issues/1834
** We might be able to write a lightweight daemon that listens for a file manager launch request, execs PCManFM-Qt with the appropriate arguments when requested, and then wait to start itself again until PCManFM-Qt is closed.
* Alternate fix: Launch pcmanfm-qt in "daemon mode" under Qubes OS, on both Whonix and Kicksecure
== autologinchange - improve robustness ==
* see todos in helper-scripts/usr/sbin/autologinchange
* make the script impervious to non-standard configuration as much as possible
== keyboard LED brightness controls ==
* https://forums.kicksecure.com/t/macbook-pro-keyboard-backlight-issue/1462
* Add to backlight-tool-dist
== sysmaint-panel - add gsmartcontrol and smart-notifier ==
* non-Qubes only
* hardware only
* [[Troubleshooting#Hard_Drive_Health_Check|Hard Drive Health Check]]
* add gsmartcontrol? Might be incompatible with Wayland. In that case, we could use a different tool.
* also add smart-notifier, if sensible to task bar?
** Aaron: smart-notifier is already present and running on non-Qubes. It does not generate a tray icon, but it does display a graphical popup window if smartd detects that something may be wrong.
== change program menu icons ==
* sysmaint-panel and live-indicator: these are currently using the python logo
* please use different icon (not necessarily project logo)
== Qubes OS - whonix-workstation-18 performance issues compared to debian-13-xfce ==
* Overview: https://openqa.qubes-os.org/tests/158005/file/system_tests-whonix-workstation-18_graph_08_template_mean.png
* More detailed analysis:
** Debian 13: https://openqa.qubes-os.org/tests/158005/file/system_tests-debian-13-xfce_graph_04_line_0_exec.png
** Debian 13: https://openqa.qubes-os.org/tests/158005/file/system_tests-debian-13-xfce_graph_04_line_2_total.png
** Whonix 18: https://openqa.qubes-os.org/tests/158005/file/system_tests-whonix-workstation-18_graph_04_line_0_exec.png
** Whonix 18: https://openqa.qubes-os.org/tests/158005/file/system_tests-whonix-workstation-18_graph_04_line_2_total.png
* Whonix is about 1.5 to 3 seconds slower in app startup in many test cases.
* Investigate, find ways to reduce the performance delta
== genmkfile and or developer-meta-files - scan for empty folders and abort ==
* cause reproducible issues
* Patrick: Done, fixed in developer-meta-files and genmkfile.
== dracut improvements ==
* install bash module by default? vs qubes initial memory
* set SYSTEMD_SULOGIN_FORCE=1 by default to allow login into dracut emergency console even if root account password is locked
https://github.com/QubesOS/qubes-core-agent-linux/pull/526/files
== vm-config-dist ai review ==
* https://github.com/assisted-by-ai/vm-config-dist/pull/1
== terminal login messages ==
* adjust cli (virtual console) login manager messages based on session type (user session versus sysmaint session)
grep -r -i "default username"
find . | grep --fixed-strings issue.d
find . | grep --fixed-strings motd.d
== heads - add whole disk boot mode ==
* Kicksecure's ISO does not boot easily on Heads because booting it requires mounting the full disk device, whereas Heads is only designed to open individual disk partitions.
* Add a new option to the boot menu for the whole disk device, for compatibility with ISOs like Kicksecure's.
* Might not be needed it Heads upstream implements it first.
== VirtualBox - shared folder - error handling ==
* user story: I think that I added a shared folder alraedy. But I am mistaken without knowing. The following error message by mnt-shared-vbox.service leads to hunting non-existing issues. The only issue is the omitted host configuration.
Nov 06 16:29:18 localhost mount-shared[1099]: /sbin/mount.vboxsf: mounting failed with the error: No such file or directory
== VirtualBox - shared folder - confusing readme ==
* The readme shows up even after shared folder is perfectly functional.
* Maybe best to abolish the readme.
* Readme is copied over and over again?
== apparmor - allow_disconnected concerns ==
* https://github.com/ArrayBolt3/kloak/commit/691d1512cd870db7297f5d38aeba421f08543311
* is allow_disconnected.path=/disconnected safe? Any upstream documentation on what exactly leads to a path becoming "disconnected" and why this is necessary?
* Possible to avoid needing this? Why does Python attempt to access /dev/null through a disconnected path?
* use include abstractions/python?
== approx - work around and report metadata caching problems ==
* Sometimes the data in the approx cache goes out of date and approx fails to update it, resulting in failed builds and possibly resulting in builds containing outdated packages
* Reproduce issue, report upstream, create workaround in derivative-maker
* Aaron: Issue reported: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1118031
* Aaron: Workaround created: https://github.com/ArrayBolt3/derivative-maker/commit/42f6e3ba146e60a89167acba67c041aecb49d505
** Patrick: Merged.
== qubes - qrexec to NetVM ==
* investigate if it is possible to get the name of a qube's NetVM from within the qube, or otherwise send qrexec requests to the NetVM
* contribute feature to upstream if it doesn't exist
* use case: don't require sdwdate-gui in Qubes-Whonix-Workstation to be explicitly configured to talk to the appropriate Qubes-Whonix-Gateway in a multi-gateway setup
== compiled code - investigate using clang ==
* clang provides a minimal UBSan runtime which may be usable as an additional hardening feature.
* Investigate if this is worthwhile.
* gcc supports more warnings, perhaps use gcc and clang together for "diagnostic builds" and static analysis, and clang for release builds?
* Perhaps build twice with, first with gcc for testing only, then with clang?
** Patrick: Keeping gcc support might be worthwhile as per non-technical reasons: [[Miscellaneous_Threats_to_User_Freedom#GCC_vs_Clang-LLVM|GCC vs Clang-LLVM]]
== port to sequoia-pgp ==
* port all code base from gpg to sequoia-pgp as much as sensible
* related - not part of this task - only for reference - https://github.com/QubesOS/qubes-issues/issues/8241
* https://sequoia-pgp.org/blog/2022/12/19/202212-chameleon-0.1/
* https://packages.debian.org/trixie/sequoia-chameleon-gnupg
** Can we just symlink /usr/bin/gpg to /usr/bin/gpg-sq?
* Aaron: Unsure if replacing gpg with gpg-sq wholesale is a good idea. Quoting the blog post on gpg-sq:
** "A consequence of not modifying GnuPG’s state but using an overlay is that changes made using the Chameleon will not be picked up by GnuPG. For example, if you import a certificate using the Chameleon, it will only be inserted into the overlay, and GnuPG will not see it."
** Would prefer porting to sq's native API instead, to avoid consistency issues.
* Aaron: Delay until after the release of Kicksecure 18 perhaps? That way the work done here doesn't end up causing us major problems before the release is complete.
** Delaying this may be essential, as Whonix 18 should release before Qubes OS R4.3 does.
** Please move to WAITING ON if good to delay, move back to TODO if we should pursue this now.
*** Patrick: Please do in sequoia branch.
== kloak - Qubes OS mouse anonymization improvements ==
* https://github.com/QubesOS/qubes-issues/issues/10292
== research apparmor dbus rules ==
* AppArmor supports restricting the D-Bus calls an application can make. Investigate how we could use this to strengthen confinement on applications that run without a true sandbox.
== optimize accountctl / get-user-list / get-password-status-list ==
* current implementation: forks frequently, has to re-open and re-parse /etc/shadow and related files for every query. Results in noticeable performance delays in some scripts, also is non-atomic and vulnerable to race conditions.
* better implementation: a library that caches /etc/shadow and related files when the library is sourced. Queries rely on in-memory data and avoid forking if possible.
* refactor existing bash code? rewrite in Python? Python may be simpler and faster, but existing bash implementation seems very stable.
== real fix for graphical-session.target bug in Qubes OS ==
* Aaron:
** currently we start msgcollector-gui.service under Qubes using a file under /etc/xdg/autostart
** this seems to be causing hung shutdown bugs: https://openqa.qubes-os.org/tests/162679/#downloads
** find and create a real fix for the issue if possible, then drop the workaround from our code
* https://github.com/QubesOS/qubes-issues/issues/9576
* might be same root cause: https://openqa.qubes-os.org/tests/163533/file/system_tests-qubes.tests.integ.dispvm.TC_20_DispVM_whonix-workstation-18.test_010.guest-test-inst-dvm-alt.log
* Lowered priority, Marek reports that the issues we were seeing with hung shutdowns are done after fixing sdwdate-gui's systemd configuration.
== three finger salute ==
* https://forums.kicksecure.com/t/ctrl-alt-del-three-finger-salute-action/1197
* the three finger salute should so something useful similar to what it does on Windows
** lock screen (Qubes does that)
** start task manager
** emergency shutdown button
* Open a sysmaint (or root) shell?
** This feature can be deferred.
** SAK alike?
*** Can a compromised Wayland swallow the three finger salute and mount a login spoofing attack?
**** Aaron: No, because the salute is read by the handler via evdev, which is provided directly by the kernel. It could receive the keypress despite emerg-shutdown or similar seeing it too, but emerg-shutdown would SIGSTOP the compositor before running the actual Ctrl+Alt+Delete handler.
*** Perhaps we should use the real SAK, but reconfigure its action, if that is at all possible?
**** Aaron: Does not appear to be possible, see https://www.kernel.org/doc/html/v6.0/security/sak.html
** research SIGSTOP
*** Aaron: Looks like it works reliably, even when a stuck kernel thread is involved
** research locked up kernel threads and their abuse potential
*** Aaron: It appears the worst they can do is prevent processes from fully exiting, which isn't a problem for us. They also seem to be very hard to create, unless you have root access. See https://chrisdown.name/2024/02/05/reliably-creating-d-state-processes-on-demand.html
** anti-phishing code
*** static
*** TOTP - perhaps at a later time
== live-hardener vs efi bug ==
* probably already resolved?
Aug 10 08:30:55 host live-hardener[767]: mount: /boot/efi: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error.
* Patrick: Was already fixed
== emergency-shutdown - bug - breaks Calamares installer ==
* todo
* Patrick: Still an issue? Duplicate of [[Dev/todo#Kicksecure_installer_versus_live-hardener_bug|Kicksecure installer versus live-hardener bug]]?
** might have been fixed in: https://github.com/Kicksecure/security-misc/commit/c59a3b233bd8893d466c020a2e2695ab545c6e60
** KVM affected?
== emerg-shutdown - delayed shutdown ==
* emerg-shutdown may be triggered by accident, users should have an opportunity to cancel unless the root device has vanished entirely
* for delayed shutdowns, show a warning of some sort and provide clear instructions on how to cancel the shutdown
** switch to a TTY and display a red screen with warning text on it?
*** may conflict with agetty, investigate how to suppress it (or switch to a TTY that isn't in use and that agetty isn't configured to spawn on)
* some users may need instant shutdown without warning, allow configuring the shutdown timeout, including making it 0
== emerg-shutdown - versus ram-wipe ==
* an init (systemd) wrapper?
* root disk must be unmounted so kernel deletes {{fde}} key from RAM
== emerg-shutdown - bugs ==
* Qubes:
** Should probably not run in Qubes at all? Disable using systemd unit file conditional?
Aug 10 06:10:23 host emerg-shutdown[635]: Failed to find any input device supporting panic keys!
Aug 10 06:10:23 host systemd[1]: emerg-shutdown.service: Main process exited, code=exited, status=1/FAILURE
Aug 10 06:10:23 host systemd[1]: emerg-shutdown.service: Failed with result 'exit-code'.
Aug 10 06:10:35 host memlockd[677]: Mapped file /lib/x86_64-linux-gnu/libgpg-error.so.0
* Non-Qubes:
** So far only observed in non-Qubes.
Aug 11 08:27:57 localhost memlockd[1006]: Error mmaping /etc/resolv.conf: Invalid argument
* With raid.
emerg-shutdown[202738]: path: /
emerg-shutdown[202738]: is block device: no
emerg-shutdown[202738]: path: /dev/md3
emerg-shutdown[202738]: is block device: yes
emerg-shutdown[202738]: Could not find backing device(s)! reason: Failed to look up backing item! (code 11)
== emergency-shutdown - debugging improvements ==
* add more debug output:
** every relevant code path should be written to journal
** trigger needs to be recorded
** action needs to be recorded
** purpose: in case of bugs (such as above), it should be able to debug this at least with a (virtual) serial console
== chvt hardening ==
* https://forums.kicksecure.com/t/chvt-change-foreground-virtual-terminal-vt-tty-prevent-malware-from-forced-tty-change/1274
== Qubes OS IPv6 DNS ==
* https://github.com/QubesOS/qubes-core-agent-linux/pull/592
== Qubes in-vm kernel boot mode support ==
* GRUB patch for Xen command line parsing has been merged
* implement boot mode support for in-vm kernels in qubes-core-admin
* Qubes issue: https://github.com/QubesOS/qubes-issues/issues/9872
== Qubes in-vm kernel support in general ==
* https://github.com/QubesOS/qubes-issues/issues/9570
* https://github.com/QubesOS/qubes-issues/issues/8649
* https://github.com/QubesOS/qubes-issues/issues/9759
== timesync developer wiki page improvements ==
* https://www.whonix.org/wiki/Dev/TimeSync
* [[anondate]]
* https://www.kicksecure.com/wiki/Dev/sdwdate
* please study, improve
* take note of Tor consensus and replay attacks
* in preparation for follow-up tasks
== sdwdate refactoring and improvements ==
* study sdwdate source code
* lightweight refactoring (such as no longer using classes because these are used inconsistently)
* separate into sdwdate-daemon and sdwdate-time-fetcher?
** Aaron: sdwdate-daemon is a very interesting idea, most likely useful for the ClockVM idea, however it is only feasible in situations where one either has multiple networked physical machines or multiple connected virtual machines (i.e. VBox with one Whonix-Gateway and many Whonix-Workstations, or Qubes OS). This is because the daemon has to be able to change the system's time as it sees fit in order to get Tor working (i.e. first get consensus to work by using certificate lifetime if possible, then get circuits to work using consensus, then get real time from three separate servers which are now accessible since circuits work). There is no way to isolate CLOCK_REALTIME changes from the rest of the system, Linux has time namespaces but they don't virtualize CLOCK_REALTIME. Thus sdwdate-daemon would have to be able to modify the system time freely in its mission to find the right time.
** In theory, this could be avoided if time changes could be communicated to the Tor daemon without modifying the system's wall clock. I do not know if this is possible, I suspect it isn't. Even though it is technically feasible, it would potentially be immensely complicated to implement.
** Perhaps implement sdwdate-daemon as a process that only returns whatever the next time step is, and also indicate whether there are further steps? Then sdwdate-time-fetcher could either ignore the date if the daemon indicates more steps are still to come, or accept it. The ClockVM itself would unconditionally accept sdwdate-daemon's reported time values in order to assist it in finding the correct time, then client VMs would only update their clock once the "final step" was reached.
* sdwdate oneshot feature (pick the median time from the 3 pools, output to console, then exit) if considered useful for the next bullet point
* add support for sdwdate to be used as a [https://forums.whonix.org/t/qubes-whonix-gateway-as-clockvm/19015 Qubes-Whonix-Gateway as ClockVM]
* note: sdwdate can already fix the clock if it is very slow (with the help of Tor consensus and anondate)
** Aaron: If the clock is very very slow, this seems to not work. Might be possible to use Tor certificates to get within a year of the correct date, then attempt to brute-force a month that will allow Tor consensus to work. As long as the Tor network itself will not work if the clock is too far off, we don't have to worry too much about replay attacks, untrusted data, etc. - the worst an attacker could do is denial of service, we'll only get working connectivity if we get very close to the correct time (or an adversary controls so many of the servers we're using it can trick us into thinking our time is correct, which is statistically unlikely...? is it actually statistically unlikely?)
* add feature to sdwdate to allow it fixing the clock if it is very fast too
** it may not be possible to implement such a feature securely (setting the clock forward has no security risk but setting the clock backwards makes already expired keys valid again). perhaps should just be a manual action? in theory, by setting the clock backwards very far into the past, sdwdate should be able to fix it. Perhaps we could try once to set the clock backwards just a few hours (not years) based on Tor consensus / anondate? Or perhaps this should only be possible by manual user action?
* use chrony - time setting only - not time fetching - as a replacement for sclockadj as per [[Dev/sdwdate]]
** or if easier, saner, port sclockadj from clock_settime to adjtimex?
** Aaron: Probably easier to port sclockadj, chrony looks a bit dangerous to me.
** please research, consider various options
== kicksecure - update torification improvements ==
* current implementation:
** only shipped-by-default APT repositories go use tor+https
** tor+https is worthwhile to keep (for stream isolation) but not the best implementation
* ideally, newly added apt repositories should go through Tor as well, as should flatpak installation and updates
* new implementation:
** Kicksecure would need to use something similar to what Whonix does in package uwt (torsocks wrapper)
** Flatpaks can be made to go through Tor by enabling an HTTPTunnelPort in Tor, then setting http_proxy and https_proxy to http://localhost:9080 (assuming your port number is 9080) when running Flatpak. There doesn't appear to be a way to set a proxy in Flatpak's configuration, thus this would probably require a wrapper.
** https://github.com/Kicksecure/browser-choice/issues/1
** pre-configured /etc/extrepo/config.yaml file
== flatpak update integration ==
* users are given the ability to easily install flatpaks via browser-choice, but aren't given any easy way to update them
* add code to upgrade-nonroot that also updates flatpaks
* Aaron: Implemented: https://github.com/ArrayBolt3/usability-misc/tree/arraybolt3/flatpak-update
* Patrick: should be deferred until update torification has been improved
== investigate Debian Rolling ==
* investigate why Debian Rolling initiative failed
** From initial research:
*** Lots of disagreement about how exactly to implement it, although https://lists.debian.org/debian-devel/2011/05/msg00275.html had a very large amount of positive feedback compared to other proposals
**** See also DEP-10 (https://dep-team.pages.debian.net/deps/dep10/) which is somewhat orthogonal but related
*** Limited manpower, no one appears to have tried to actually do it
*** Need to cope with the activity occurring in Debian's unstable and testing repositories, which have some turbulence and can cause issues if one isn't careful
*** Likely worth trying to resurrect
* contact people involved previously, if that makes sense
* suggest prospective developers
* Started to write tooling for this: https://github.com/ArrayBolt3/drk Very incomplete, nowhere near usable. Will keep developing this.
== repository-dist-wizard - improvements ==
* {{Github_link|repo=repository-dist}}
* GUI: detect stable, stable-proposed-updates, testers, developers setting in GUI. I.e. if re-running the tool, keep the former setting. Should this depend on previous choice in the GUI (status files, probably easier) or actual status on the disk (might be manually modified by the user)
* add support for switching back and forth between clearnet and onion
== Tool to onionize all APT sources ==
* https://forums.whonix.org/t/tool-to-onionize-all-apt-sources/13367
* Should it be part of repository-dist or a standalone tool?
== immutable - mount as read-only when possible ==
* persistent mode, user session should mount root filesystem as read-only (with persistent overlay)
== verified boot implementation ==
* assume firmware can extend trust to kernel via Sovereign Boot
* create a system for extending trust from kernel to initramfs and userland
* possibly investigate immutable images?
* Implementation idea notes:
** A system running with Verified Boot enabled must have the root partition in live mode (read only with tmpfs overlay). Therefore something similar to live mode will be needed when running in "verified mode"
** dm-verify is what Google uses, there seems to be no compelling reason for us to avoid it.
** Kernel modifications are not permitted, Kicksecure will be signing Debian's shim meaning only vanilla Debian kernels will be bootable. Rely on alternative ways of storing the dm-verify root hash in a secure immutable fashion, such as:
*** TPM / Measured Boot? Highly desirable if security issues don't result, as this avoids the need for user interaction unless something goes wrong.
**** Would require some way of authenticating that the TPM has not been reset (similar to Heads TOTP/HOTP codes)
*** User providing the hash on an external drive?
*** Verification passphrase similar to LUKS passphrase?
** Patrick: TPM is unavailable inside VMs? In this case, verified boot support is still desirable.
* Patrick
** Whonix-Gateway: either no verified boot initially or install user-sysmaint-split by default
** persistent mode, verified boot should still allow for logs persistent
** [[Verified_Boot#When_the_verification_is_over.3F|When the verification is over?]]:
*** "verification is a continuous process happening as data is loaded into memory"
*** "This means if malware manages to modify the /usr/bin/mv program despite immutability, then dm-verity would notice this the next time the user or system is attempting to execute that command."
*** This security gained from this feature is somewhat reduced if the attacker can use ephermal overlays.
** consider [[Sysmaint#enable_sudo_access_in_USER_session|enable sudo access in USER session]] (developer debug mode): disable verified boot + write to disk + regenerate verified boot hash tree (this is to ease debugging issues only happening in user session but not in sysmaint session)
* prefer Debian on true read-only filesystem without ephemeral overlay to benefit from kernel verified continuous verification after boot feature
** [[Verified_Boot#Challenges_with_Immutable_Filesystems|Challenges with Immutable Filesystems]]
*** As-needed ephemeral overlays
*** Use alternate software that doesn't require root to be writable
*** as feasible, up for discussion
== calamares - add module to select or unselect firmware-nonfreedom ==
* default selection: none - require explicit user choice. If possible, otherwise default to "yes, install firmware-nonfreedom".
== permission-hardener - live bug ==
* got a bug report by e-mail
sudo apt install network-manager-openvpn-gnome
security-misc (3:44.4-1) ...
INFO: triggered security-misc: 'security-misc' security-misc DPKG_MAINTSCRIPT_
NAME: 'postinst' $\*: 'triggered /usr' 2: '/usr'
/usr/libexec/security-misc/mmap-rnd-bits: INFO: Successfully written ASLR map
config file:
/etc/sysctl.d/30_security-misc_aslr-mmap.conf
Running SUID Disabler and Permission Hardener... See also:
https://www.kicksecure.com/wiki/SUID_Disabler_and_Permission_Hardener
/var/lib/dpkg/info/security-misc.postinst: INFO: running: permission-hardener
enable
permission-hardener: [NOTICE]: Executing: dpkg-statoverride --add --update root shadow 744 /usr/lib/live/mount/rootfs/filesystem/usr/sbin/unix_chkpwd
dpkg-statoverride: : `/usr/lib/live/mount/rootfs/filesystem/usr/sbin/unix_chkpwd'
permission-hardener: [ERROR]: Command 'dpkg-statoverride --add --update root shadow 744 /usr/lib/live/mount/rootfs/filesystem/usr/sbin/unix_chkpwd' failed with exit code '2'! calling functio
n name: 'commit_policy'
permission-hardener: [NOTICE]: Executing: dpkg-statoverride --admindir /var/lib/permission-hardener-v2/new_mode --add root shadow 744 /usr/lib/live/mount/rootfs/filesystem/usr/sbin/unix_chkp
wd
permission-hardener: [NOTICE]: Executing: dpkg-statoverride --add --update root root 744 /usr/lib/live/mount/rootfs/filesystem/usr/bin/pkexec
dpkg-statoverride: : `/usr/lib/live/mount/rootfs/filesystem/usr/bin/pkexec'
permission-hardener: [ERROR]: Command 'dpkg-statoverride --add --update root root 744 /usr/lib/live/mount/rootfs/filesystem/usr/bin/pkexec' failed with exit code '2'! calling function name:
'commit_policy'
permission-hardener: [NOTICE]: Executing: dpkg-statoverride --admindir /var/lib/permission-hardener-v2/new_mode --add root root 744 /usr/lib/live/mount/rootfs/filesystem/usr/bin/pkexec
permission-hardener: [NOTICE]: Executing: dpkg-statoverride --add --update root root 744 /usr/lib/live/mount/rootfs/filesystem/usr/bin/sudo
dpkg-statoverride: : `/usr/lib/live/mount/rootfs/filesystem/usr/bin/sudo'
permission-hardener: [ERROR]: Command 'dpkg-statoverride --add --update root root 744 /usr/lib/live/mount/rootfs/filesystem/usr/bin/sudo' failed with exit code '2'! calling function name: 'c
ommit_policy'
permission-hardener: [NOTICE]: Executing: dpkg-statoverride --admindir /var/lib/permission-hardener-v2/new_mode --add root root 744 /usr/lib/live/mount/rootfs/filesystem/usr/bin/sudo
permission-hardener: [NOTICE]: Executing: dpkg-statoverride --add --update root shadow 744 /usr/lib/live/mount/medium/usr/sbin/unix_chkpwd
dpkg-statoverride: : `/usr/lib/live/mount/medium/usr/sbin/unix_chkpwd'
permission-hardener: [ERROR]: Command 'dpkg-statoverride --add --update root shadow 744 /usr/lib/live/mount/medium/usr/sbin/unix_chkpwd' failed with exit code '2'! calling function name: 'co
mmit_policy'
permission-hardener: [NOTICE]: Executing: dpkg-statoverride --admindir /var/lib/permission-hardener-v2/new_mode --add root shadow 744 /usr/lib/live/mount/medium/usr/sbin/unix_chkpwd
permission-hardener: [NOTICE]: Executing: dpkg-statoverride --add --update root root 744 /usr/lib/live/mount/medium/usr/bin/pkexec
dpkg-statoverride: : `/usr/lib/live/mount/medium/usr/bin/pkexec'
permission-hardener: [ERROR]: Command 'dpkg-statoverride --add --update root root 744 /usr/lib/live/mount/medium/usr/bin/pkexec' failed with exit code '2'! calling function name: 'commit_pol
icy'
permission-hardener: [NOTICE]: Executing: dpkg-statoverride --admindir /var/lib/permission-hardener-v2/new_mode --add root root 744 /usr/lib/live/mount/medium/usr/bin/pkexec
permission-hardener: [NOTICE]: Executing: dpkg-statoverride --add --update root root 744 /usr/lib/live/mount/medium/usr/bin/sudo
dpkg-statoverride: : `/usr/lib/live/mount/medium/usr/bin/sudo'
permission-hardener: [ERROR]: Command 'dpkg-statoverride --add --update root root 744 /usr/lib/live/mount/medium/usr/bin/sudo' failed with exit code '2'! calling function name: 'commit_polic
y'
permission-hardener: [NOTICE]: Executing: dpkg-statoverride --admindir /var/lib/permission-hardener-v2/new_mode --add root root 744 /usr/lib/live/mount/medium/usr/bin/sudo
permission-hardener: [NOTICE]: To compare the current and previous permission modes, install 'meld' (or preferred diff tool) for comparison of file mode changes:
sudo apt install --no-install-recommends meld
meld /var/lib/permission-hardener-v2/existing_mode/statoverride /var/lib/permission-hardener-v2/new_mode/statoverride
permission-hardener: [ERROR]: Exiting with non-zero exit code: '203'
/var/lib/dpkg/info/security-misc.postinst: ERROR: Permission hardening failed.
* random guess: Could there be issues with non-latin language settings?
* Why is it /usr/lib/live/mount/rootfs/filesystem?
* Could it be that the user booted into live mode?
* Maybe a case of low RAM where no further writes to RAM were possible?
* Booting into live mode and using APT should be supported as much as feasible.
* In case of insufficient information, could you please add debug code to provide more information in the future?
* Unsure if further information can be requested form the reporter, but I could try.
* Useful to add:
test -w "${file_name_from_stat}"
* permission hardener might not be the cause of this issue. However, ideally it would show a better error message pointing out the issue.
* Aaron: Cannot reproduce on ISO or in LIVE mode USER.
** The /usr/lib/live/mount path suggests that the issue is the result of attempting to distribution-morph a vanilla Debian Live session. This, IMO, is not something we should support, because:
*** All changes will be lost on reboot, meaning someone who uses this in production will be downloading a lot of Kicksecure packages from our infra every time they start the system.
*** We already offer a live Kicksecure ISO.
*** None of the kernel hardening options will be enabled, and they can't be enabled, because that would require a reboot which will discard everything.
*** And of course, permission-hardener doesn't expect anything under /usr to be read-only.
** Would suggest adding a warning to the distribution morphing documentation that a live Debian ISO session can't be morphed, and that one should download a live Kicksecure ISO if they need a Kicksecure-enhanced live system.
* Patrick: Done. Documented.
* Could you please add better error handling in this case?
== audio ==
=== audio generally ===
* https://forums.whonix.org/t/port-from-pulseaudio-to-pipewire-for-audio-support/16879/40
* please read, comment if something useful to share
=== VirtualBox Intel HD Audio and PipeWire Incompatibility / Audio broken after increasing ram to 5 GB / No sound after latest updates - PipeWire Bug? ===
* https://forums.whonix.org/t/virtualbox-intel-hd-audio-and-pipewire-incompatibility-audio-broken-after-increasing-ram-to-5-gb-no-sound-after-latest-updates-pipewire-bug/18211
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081965
* please investigate if doable with reasonable effort
* Tried switching between Pulseaudio and Pipewire on a booted VM, discovered I could "initialize" the speakers with Pulseaudio and then Pipewire would work thereafter
* Virtually certain this is an upstream bug, was able to reproduce with both Ubuntu 24.04 and Arch Linux.
* Suggest switching to AC97 audio (even Arch Linux defaults to this under Virtualbox).
* Need to investigate upstream code
* Could not get any meaningful hints from pipewire, wireplumber, and pipewire-pulse logs. Pulseaudio shows an "alsa woke us up to write new data to the device but there was actually nothing to write" error in its logs. At this point this is likely to be a bug in VirtualBox or the snd-hda-intel kernel driver.
== live-build - test lb config --dm-verity ==
* Does the ISO still function if build with lb config --dm-verity?
* Does it break apt-get install pkg-name? It might not break it due to overlayfs.
* Lacks live-build support when used with dracut:
** lb config won't even run if you try to enable verity and dracut at the same time, unless you override live-build by commenting that sanity check out
** The ISO won't build initially because the dm-verity building code is trying to find the live filesystem in the wrong location
** dracut isn't configured to include systemd-veritysetup-generator, needed for verifying the root FS in the first place
** No kernel command line options are added to the ISO for verity setup
== Kicksecure Firewall ==
https://forums.kicksecure.com/t/kicksecure-firewall/378/10
== Meta Packages, Kicksecure, Whonix - Desktop versus Server ==
https://forums.kicksecure.com/t/meta-packages-kicksecure-desktop-versus-kicksecure-server/415
== wipe video RAM ==
* add wipe video RAM support to [[ram-wipe]]
* maybe based on https://wiki.archlinux.org/title/Swap_on_video_RAM
* maybe also based on https://github.com/divestedcg/Brace/blob/master/brace/etc/profile.d/brace-env-overrides.sh
# zero video RAM to prevent leakage
# see (CC BY-SA 4.0): https://www.adlerweb.info/blog/2012/06/20/nvidia-x-org-video-ram-information-leak
export R600_DEBUG=zerovram;
export AMD_DEBUG=zerovram;
export RADV_DEBUG=zerovram;
* if doable with reasonable effort
== Tor 0.4.8.9 broken in combination with vanguards ==
* https://gitlab.torproject.org/tpo/core/tor/-/issues/40892
* write a script to use git bisect to auto test which commit introduced this issue maybe based on https://forums.whonix.org/t/vanguards-additional-protections-for-tor-onion-services/8064/64
* if not done by upstream yet
* if doable with reasonable effort
* Aaron: vanguards has been removed from Debian Trixie, still worth doing?
== VirtualBox serial console ==
* {{CodeSelect|inline=true|code=
sudo apt install serial-console-enable
}}
* [[Recovery#Serial_Console|Serial Console]]
* causes bug (spam of journal)
* https://forums.whonix.org/t/serial-console-in-virtualbox/8021/13
* fixable? upstream bug report?
* would installation by default be sane or a security issue?
Nov 24 10:13:35 localhost agetty[1346]: -: failed to get terminal attributes: Input/output error
== KVM related ==
=== KVM - 3D Graphics Acceleration - SPICE - Testing - drm ===
* please test: https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_drm
* please mention your configuration (still using SPICE), quote Patrick and report here: https://forums.whonix.org/t/how-to-enable-3d-acceleration-in-kvm/16501/22
* test if DRM (direct rendering manager) is enabled as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_Direct_Rendering_Manager
* test performance as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_Performance
=== KVM - 3D Graphics Acceleration - Performance Test - Display SDL ===
* https://forums.whonix.org/t/how-to-enable-3d-acceleration-in-kvm/16501/22
* test SDL
* test if DRM (direct rendering manager) is enabled as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_drm
* test performance as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_Performance
=== KVM - 3D Graphics Acceleration - Performance Test - Display GDK ===
* https://forums.whonix.org/t/how-to-enable-3d-acceleration-in-kvm/16501/22
* test GTK
* test if DRM (direct rendering manager) is enabled as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_drm
* test performance as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_Performance
=== KVM - verify AppArmor sVirt confinement operation ===
* https://forums.whonix.org/t/help-welcome-kvm-development-staying-the-course/166/593
=== KVM - use rootless ===
* https://forums.whonix.org/t/rootless-virtual-machines-with-kvm-and-qemu/20952
* port documentation (and XML files, if needed) to qemu:///session, if sane
* search Kicksecure; and Whonix wiki - using [[Special:ReplaceText]]
* re-check if sVirt is still functional
=== KVM - port to unix domain socket based internal networking for Whonix-Gateway to Whonix-Workstation connections ===
* https://forums.whonix.org/t/help-welcome-kvm-development-staying-the-course/166/594
* update documentation
** https://www.whonix.org/wiki/Multiple_Whonix-Workstation#How-to:_Use_more_than_One_Whonix-Workstation_-_Easy
** https://www.whonix.org/wiki/KVM#Creating_Multiple_Internal_Networks
** https://www.whonix.org/wiki/Multiple_Whonix-Gateway#KVM
=== KVM - IPv6 router advertisement issues ===
* when 634-stackable-wrappers.md}}
* Debian feature request: [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822693 Feature Request: Automatically starting programs under firejail]
* review, comment, pull request where applicable
* draft and/or open a discussion on debian-devel
* use cases:
** automatically sandbox applications (such as when typing "browser-name")
** warn user against starting certain applications inside sysmaint session such as browsers
** apply system resources restraint: https://forums.whonix.org/t/constrained-system-resources-program-starter-wrapper/10914
== check out bubblejail ==
* https://github.com/igo95862/bubblejail
* in preparation for next task
== sandbox-app-launcher ==
* [[sandbox-app-launcher]]
* review
* promising? worth bringing back to life, polishing?
* at odds with apparmor.d?
* better using bubblejail?
== automated test suite - cli version ==
* todo: discuss
== apparmor.d review ==
* https://github.com/roddhjav/apparmor.d
* https://forums.whonix.org/t/apparmor-d-full-set-of-apparmor-profiles-1500-profiles/17389
** review
* https://github.com/roddhjav/apparmor.d/issues?q=is%3Aissue+author%3Aadrelanos
** check ticket status
* lightweight security review
** conceivable or too much effort?
== improved server support ==
* documentation
** rebrand wiki CLI for server
* Linux account passwords?
* cloudinit?
* vm-config-dist versus autologin CLI vs GUI vs server
== hidepid ==
* general information: https://www.kicksecure.com/wiki/Security-misc#hidepid
* enable by default for users of user-sysmaint-split?
* hidepid seems to make most sense if using user-sysmaint-split, because then account "user" cannot use sudo/pkexec anyhow
* test and implement https://github.com/systemd/systemd/issues/29893#issuecomment-2757436101 if sane
== research shred ==
* research if shred is still useful nowadays
* if not, should be replaced by safe-rm
== port to Debian forky ==
* compositior
** review, update [[Dev/Strong_Linux_User_Account_Isolation#Wayland_application_isolation|Wayland application isolation]]
** are we staying on labwc or move to a more secure Wayland compositior, if any is available?
** https://forums.kicksecure.com/t/wayland-only-or-noland/1170
* migrate to security-misc
** https://github.com/Whonix/anon-apps-config/blob/master/etc/skel/.config/vlc/vlcrc
= WAITING ON =
== fonts issues ==
* https://forums.whonix.org/t/font-issues-in-various-applications/22838
** Aaron: Cannot reproduce, likely hardware-specific. Waiting for further input from user.
== GRUB - Debian packages grub-pc and grub-efi co-install-ability ==
* please submit a patch to Debian to make grub-pc and grub-efi co-installable
* [https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=904062 Allow concurrent installation of grub-pc and grub-efi-amd64]
* Submitted and awaiting review: [https://salsa.debian.org/grub-team/grub/-/merge_requests/76#note_590495 Remove ucf conffile conflict between grub-pc and grub-efi-{amd64,ia32}]
* Unfortunately this is not going to be able to make it into Trixie, it will have to wait for Forky before it makes it into Debian Stable.
** Trixie is now out, rebased this work onto git master and requested review again.
*** piuparts CI is failing. Need to investigate.
**** piuparts CI is fixed, waiting for review.
== RPi GRUB - contribute to Debian ==
* Start a discussion and contribute to https://raspi.debian.net/ if accepted by upstream.
* This and the above ticket might result in implementation feedback, such as for options in config.txt.
* Combined this and the debian-arm notification ticket into a single email.
* https://lists.debian.org/debian-arm/2025/04/msg00012.html
* Found:
** https://salsa.debian.org/raspi-team
** https://salsa.debian.org/raspi-team
** Seems active as per: https://salsa.debian.org/raspi-team/image-specs/-/issues/74
** https://salsa.debian.org/raspi-team/image-specs/-/issues
*** Please consider posting a feature request there for RPi GRUB support, if that is sensible. Draft:
add support for GRUB as bootloader for RPi
I've recently succeeded in converting an existing Debian Trixie RPi image to boot using GRUB on the RPi 4B and extensively documented how to do that. [1] I also posted about this on the debian-arm mailing list. [2]
Booting in this way has several substantial advantages over the current Raspberry Pi boot process:
* The kernel command line can be modified via /etc/default/grub and files under /etc/default/grub.d. Some software requires or benefits from such modifications and leverages this mechanism in GRUB to make non-invasive changes to the command line. With direct kernel boot, these changes are silently ignored, while with U-Boot + GRUB, they are correctly applied.
* In the event of a bad kernel update, users can easily boot into older kernels as they would on a typical desktop system.
* Recovering from a broken boot without a secondary system becomes much easier, as users can use the GRUB and U-Boot consoles to debug and manually boot the system.
* Multiboot installations on the Pi become possible.
Is this a feature for which you would welcome a merge request here, either as an option or even as the default?
Obviously, at this point, RPi GRUB support could only be added to Forky and later.
(I've also recently submitted a pull request to `grml-debootstrap` (a Debian bootable image builder tool) [3] [4] implementing "basic" RPi support.)
* [1] https://www.kicksecure.com/wiki/Dev/boot#Booting_Debian_Trixie_with_GRUB_+_u-boot_on_Raspberry_Pi_4
* [2] https://lists.debian.org/debian-arm/2025/04/msg00012.html
* [3] http://packages.debian.org/grml-debootstrap
* [4] https://github.com/grml/grml-debootstrap/pull/335
* Aaron: Filed issue upstream using template: [https://salsa.debian.org/raspi-team/image-specs/-/issues/78 Support U-Boot + grub-efi boot flow]
** Also filed a bug report against raspi-firmware: [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102607 Add support for U-Boot + grub-arm64-efi boot flow]
** Other plans are still in the works for the Debian RPi images: https://outreach-team.pages.debian.net/gsoc/debian/raspberrypi/2025/06/03/gsoc-2025-introduction-make-debian-for-raspberrypi-again.html We should probably wait for all this to be merged before attempting to continue any further.
== virtualbox clipboard contribution review ==
* https://forums.whonix.org/t/i-made-a-fix-for-the-shared-clipboard-issue/22705
* Aaron: Posted initial review. Waiting for reply.
** Reply received, waiting for a second iteration. If the original developer goes missing, we may polish their work and integrate it into the codebase ourselves.
== live-build - deb822 support PR ==
* Aaron:
** review received, changes requested: https://salsa.debian.org/live-team/live-build/-/merge_requests/436#note_711296
** finish working with upstream to get this merged
** Made some changes, still discussing details with upstream.
== trixie port - calamares - use gpt by default ==
{{anchor|show=true|calamares - use gpt by default}}
* https://forums.kicksecure.com/t/use-guid-partition-table-gpt-by-default/1465
* Patrick: bug: unencrypted installations are mbr by default
* Patrick: todo: port from [https://en.wikipedia.org/wiki/Master_boot_record master boot record (MBR)] to [https://en.wikipedia.org/wiki/GUID_Partition_Table GUID Partition Table (GPT)], if sane
* Aaron: Likely not a good idea until a Calamares release with https://github.com/calamares/calamares/pull/2422 in it is made (the version in Trixie doesn't have this yet). We'd have to introduce a bios-grub partition unconditionally on both EFI and BIOS, and only one bootloader would be installed. This would mean that BIOS systems would end up with a bios_boot partition and no ESP, while EFI systems would get both bios_boot and ESP partitions but only an EFI bootloader installed. Once the linked PR is present in a release, we will be able to always have both partitions and both bootloaders.
** Aaron: Technically GRUB can be installed on BIOS systems without a bios_boot partition, but grub-install must be run with --force to do this, and the bootloader may break at any time if this is done. See https://savannah.gnu.org/bugs/index.php?32391#comment1:
The blocklists are unreliable because the filesystems can move the files around at will and so the exact sectors are subject to change. Any such change creates both a reliability and security problem. Previously the blocks were only rarely moved around. However, now, with features like tail repacking and online defragmenter it will become increasingly of a problem.
* Patrick: Rename to trixie-port - calamares - use GUID Partition Table (GPT) by default and move to waiting on?
** Aaron: Done.
== RPi grml-debootstrap ==
* https://github.com/grml/grml-debootstrap/issues/114
* Draft PR at https://github.com/grml/grml-debootstrap/pull/335, needs more testing and work
* Tested and polished PR and marked it as ready for review.
* Added question about future support for U-Boot + grub-efi-arm64.
* Merged in master, requested another review. Hopefully this will be mergeable now.
== trixie-port - misc qubes test failures ==
* From Marek:
** General performance issues, may be solved by making things more efficient in general
*** https://openqa.qubes-os.org/tests/159131
*** https://openqa.qubes-os.org/tests/159129#step/TC_00_Dom0Upgrade_whonix-gateway-18/2
**** Applied some optimizations to sdwdate and sdwdate-gui. systemd reports a relatively fast boot time now (around 7 seconds), however the time from a qvm-run call to application startup is still pretty long.
** https://openqa.qubes-os.org/tests/159123 (this one is due to sudo blocked)
*** Add a privleap rule for inserting v4l2loopback kernel module
**** Done: https://github.com/QubesOS/qubes-video-companion/pull/33
** https://openqa.qubes-os.org/tests/159089
*** Random timesanitycheck failure, likely will not reoccur.
** https://github.com/Whonix/updates-status/issues/290#issuecomment-3524509617
*** /tmp/user/1000 owned by root again, try to make an automated reproducer for this
**** Automated reproducer couldn't trigger the issue. Audited all mkdir calls, pushed a commit to helper-scripts with a fix to lockfile.sh. Unlikely to fix the issue, but worthwhile.
***** Patrick: Merged. Yes, worthwhile to fix. Also yes, unlikely to fix the issue since the issue started before lockfile.sh got introduced.
** https://github.com/Whonix/updates-status/issues/289#issuecomment-3524513760
*** Can't reproduce here, probably already fixed?
**** Found that the fix was indeed already applied.
* From Ben:
** https://openqa.qubes-os.org/tests/159100#step/TC_00_DispVMPerf_whonix-workstation-18/21
*** Might have been the msgprogressbar issue, hopefully won't reoccur
* Results of benchmarking a cloned debian-13-xfce qube while adding bits from Kicksecure into it gradually, giving the qube only 400 MB of RAM with no ability to balloon:
Using packages from trixie Kicksecure repo, not trixie-developers
Before any morph: (8.388 + 8.015 + 8.112) / 3 = 8.171
After adding helper-scripts: (8.005 + 8.179 + 7.999) / 3 = 8.061
After adding security-misc: (8.222 + 8.346 + 8.404) / 3 = 8.324 (with outlier 18.132) (Marked drop in performance here, and the outlier did take an awfully long time, does the first boot after security-misc installation do something weird?)
After adding usability-misc: (8.381 + 8.395 + 8.326) / 3 = 8.367
After adding dist-base-files: (8.516 + 8.399 + 8.431) / 3 = 8.448
After adding kicksecure-base-files: (8.253 + 8.461 + 8.430) / 3 = 8.381
After adding desktop-config-dist: (8.714 + 8.580 + 8.598) / 3 = 8.630 (Another marked drop in performance here)
After adding sdwdate: (8.867 + 8.751 + 8.946) / 3 = 8.854 (another marked drop in performance here, not really a surprise since this pulled in Tor)
After adding sdwdate-gui: (9.167 + 9.075 + 9.165) / 3 = 9.135 (another marked drop in performance)
After adding systemcheck: (9.057 + 9.125 + 9.103) / 3 = 9.095
After adding msgcollector-gui: (9.171 + 9.190 + 9.224) / 3 = 9.195 (noticeable performance drop)
After adding vm-config-dist: (9.245 + 9.378 + 9.112) / 3 = 9.245 (doesn't seem to be a truly reliable drop in performance)
After adding bootclockrandomization: (9.312 + 9.152 + 9.081) / 3 = 9.181
After adding dist-general-gui-lxqt: (9.264 + 9.112 + 9.187) / 3 = 9.187
... should have done more incremental benchmarks here ...
After installing the rest of everything with kicksecure-qubes-gui-lxqt: (9.974 + 9.976 + 9.921) / 3 = 9.957
* Takeaways from benchamrking:
** It might be worth trying to avoid forking in our startup scripts; maybe having less forks and less units would allow for faster operation. Unfortunately Python multithreading isn't very fast, and Bash doesn't have multithreading, so we can't get parallelism and absence of forks at the same time.
** We might see if we can avoid blocking startup on units that aren't startup-critical. sdwdate-gui, for instance, takes some time to come up, but also apparently blocks the UI showing up for a quarter of a second on my test machine, which could possibly be avoided.
** None of the performance issues here seem particularly egregious to me, certainly not enough to cause slews of timeouts like we're seeing in Whonix's tests on OpenQA.
** I used a very low-RAM system for this, and it worked quite well; no memory exhaustion issues were encountered.
** Further research needs to be done on the specific tests that are timing out to determine what they're trying to do that is timing out.
* Investigation of logs from a DispVM test where Whonix-Workstation timed out:
** Qubes' test infra seems to have a periodic hardware lag issue that affects all VMs.
** Whonix is probably just the first thing to trim timeouts because we have too many services doing too many resource-intensive tasks during early boot.
guest-disp2246.log (Fedora Linux 42, 7 second kernel load time, 1 second from "Qubes: done" to disk mount, login prompt, 35 second runtime)
guest-disp3748.log (Fedora Linux 42, 6 second kernel load time, 2 seconds from "Qubes: done" to disk mount, login prompt, 66 second runtime)
guest-disp5735.log (Fedora Linux 42, 7 second kernel load time, 2 seconds from "Qubes: done" to disk mount, login prompt, 29 second runtime)
guest-disp5839.log (Debian 13, 6 second kernel load time, 9 seconds from "Qubes: done" to disk mount, login prompt (barely), 60 second runtime)
guest-disp5955.log (Whonix-Gateway 18, 9 second kernel load time, 12 seconds from "Qubes: done" to disk mount, no login prompt, 81 second runtime)
guest-disp6231.log (Whonix-Gateway 17, 7 second kernel load time, 3 seconds from "Qubes: done" to disk mount, login prompt, 62 second runtime)
guest-disp6497.log (Debian 13, 6 second kernel load time, 8 seconds from "Qubes: done" to disk mount, login prompt (barely), 39 second runtime)
guest-disp678.log (Fedora Linux 42, 8 second kernel load time, 4 seconds from "Qubes: done" to disk mount, login prompt (barely), 39 second runtime)
guest-disp7152.log (Whonix-Workstation 18, 7 second kernel load time, 6 seconds from "Qubes: done" to disk mount, no login prompt, 70 second runtime)
guest-disp9514.log (Debian 13, 5 second kernel load time, 6 seconds from "Qubes: done" to disk mount, login prompt (barely), 43 second runtime)
guest-sys-net.log (Fedora Linux 42, 6 second kernel load time, 0 seconds from "Qubes: done" to disk mount, login prompt, hours long runtime for obvious reasons)
* https://github.com/QubesOS/qubes-issues/issues/10420#issuecomment-3576719255
* Ben mentioned in the Qubes OS Matrix room that Whonix's performance seemed substantially improved, possibly because of our optimizations but also possibly because of optimizations in Qubes OS itself.
* Workstation disposable template hanging on shutdown: https://openqa.qubes-os.org/tests/161078/file/system_tests-qubes.tests.integ.dispvm_perf.TC_00_DispVMPerf_whonix-workstation-18.test_001.guest-test-inst-dvm.log
* timesanitycheck occasionally fails: https://openqa.qubes-os.org/tests/161707
** Made a fix, but then reverted, turns out machine running that test has a dead RTC battery.
* Issues may be resolved, waiting for Ben Grande to report how the next full test goes.
== Qubes R4.3 bypass review ==
* https://github.com/QubesOS/qubes-issues/issues/10328
* are there more ways in which that can go wrong?
* realistic to fundamentally re-design this to avoid such kinds of issues?
** Aaron: NetVM authentication, to ensure the NetVM used by a particular qube provides the features and security/anonymity guarantees needed by that qube? May be vaguely related to the "qrexec to NetVM" task.
* https://github.com/QubesOS/qubes-issues/issues/6948
* https://github.com/QubesOS/qubes-issues/issues/3994
* Aaron: Looked at the relevant issues, I'm not entirely sure how the Salt issue is directly relevant, but I did look at it and will keep it in mind.
* Aaron: Sent an email with some ideas to the qubes-devel mailing list: https://www.mail-archive.com/qubes-devel@googlegroups.com/msg05660.html
* Aaron: Feature request: https://github.com/QubesOS/qubes-issues/issues/10334
** Major feature request, will most likely need to wait until after the release of R4.3.
** Unblocked, R4.3 has been released.
** Aaron: Made a spec for the feature and shared it on the bug report. Waiting for feedback.
== Tor Browser not launching in Qubes-Whonix-Workstation 18 StandaloneVM ==
* https://github.com/QubesOS/qubes-issues/issues/10514#issuecomment-3700693542
** Aaron: Diagnosed issue, waiting for feedback on suggested solution from Marek.
== grml-debootstrap - finish deb822 PR ==
* https://github.com/grml/grml-debootstrap/pull/351#pullrequestreview-3614443958
* Aaron: Updated, implemented requested changes. Looks like we're just waiting for upstream now.
== trixie-port - usability-misc versus policyrcd-script-zg2 ==
* [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1119964 Add a drop directory fallback if /etc/zg-policy-rc.d.conf does not exist]
* usability-misc Depends: on policyrcd-script-zg2
* todo: think through if this dependency should be removed, moved elsewhere and can interact badly with user-sysmaint-split policyrcd
* Aaron:
** Very unlikely to interact badly. policyrcd-script-zg2 uses the alternatives system, as does user-sysmaint-split, and user-sysmaint-split installs its policy-rc.d with a higher priority than policyrcd-script-zg2, therefore it will take priority. However, this also means that the functionality offered by policyrcd-script-zg2 is broken, likely including the pointer to helper-scripts' policy-rc.d in the POLICYRCD environment variable used by apt-get-noninteractive.
** The use of POLICYRCD in apt-get-noninteractive seems superfluous and possibly even bad. During package builds, disabling daemon restart makes sense, but this is done by installing helper-scripts' policy-rc.d with a higher priority than even user-sysmaint-split's version, so POLICYRCD is unnecessary to prevent things like unintentional connections to Tor. Done in help-steps/prevent-daemons-from-starting. Users who use apt-get-noninteractive would probably reasonably expect daemons to be restarted during installation of new packages.
** Suggestion: Remove dependency, strip all instances of POLICYRCD from codebase where the variable is set to a path. (Currently the variable is only set in apt-get-noninteractive and dpkg-noninteractive. There is also a use in grml-debootstrap but it appears to be used as a flag, not a path, thus this should not be removed.)
* Patrick:
** Because daemon restarts can cause APT upgrade failures and `apt-get-noninteractive` is designed as a tool to easily fix broken APT. Documented in its man page just now. Therefore, please keep that as is.
** todo: move dependency of policyrcd-script-zg2 from usability-misc to helper-scripts?
** todo: review policyrcd-script-zg2. seems to be a stable, not changing much, simple package with only 1 essential file: /usr/sbin/zg-policy-rc.d
** todo: please port user-sysmaint-split to policyrcd-script-zg2, if sensible
*** Aaron: Upstream code change submitted to make this possible, at https://salsa.debian.org/ArrayBolt3/policyrcd-script-zg2. We should wait to upload this to our own repository until upstream accepts it, in case they have changes they want to make.
== review tor-control-panel anon-connection-wizard merge ==
* https://forums.whonix.org/t/tor-controller-gui-tor-control-panel/5444/112
** Aaron: Needs more work. Commented, shared a diff of WIP changes, awaiting reply.
== trixie-port - Qubes - salt - template-whonix-workstation-18 ==
* https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/main/qvm/anon-whonix.sls
* "template-" observation turned out to be a red herring. Still debugging the actual problem, but not sure what it is yet.
* Aaron: This is probably a Qubes bug, filed a report: https://github.com/QubesOS/qubes-issues/issues/10445
== security-misc - review pull requests ==
* https://github.com/Kicksecure/security-misc/pulls
** Aaron: All PRs reviewed and commented on except for the mitigations=auto,nosmt one, which is still being discussed. Many PRs merged, some need further discussion.
== trixie-port - Qubes journal log messages ==
* Qubes. Should be fixed but is not fixed. Happening after boot.
Oct 27 13:40:36 host qrexec-agent[12402]: 2025-10-27 13:40:36.085 qrexec-agent[12402]: exec.c:902:find_qrexec_service: Warning: ignoring skip-service-descriptor=true for execute executable service /etc/qubes-rpc/qubes.UpdatesProxy
* Qubes. Happening after boot.
Oct 27 13:50:13 host systemctl[14620]: Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=@.host --user to connect to bus of other user)
* Qubes. Happening when using sdwdate-gui log viewer from systray to open a terminal emulator.
host xdg-desktop-por[1655]: Failed to load RealtimeKit property: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.RealtimeKit1 was not provided by any .service files
* Same as above.
xdg-desktop-por[1655]: Failed connect to PipeWire: Couldn't create PipeWire context
* https://forums.whonix.org/t/systemcheck-messages-in-qubes-whonix-18/22339
* Aaron: Fixed for most in place, still outstanding issues:
** DBUS_SESSION_BUS_ADDRESS issue is a Qubes bug: https://github.com/QubesOS/qubes-issues/issues/10384
** Still unsure what's causing the /tmp/user/1000 issue, see https://forums.whonix.org/t/systemcheck-messages-in-qubes-whonix-18/22339/5
== trixie-port - screen briefly unlocked after wake from suspend ==
* LXQt unfortunately puts the system into suspend before locking the screen. However, this does not occur on Arch Linux. Debug and determine whether Debian needs a patch or our configuration needs to change.
** Aaron: Debugged, discovered how to reproduce the bug on Arch, created a bug report with some analysis: https://github.com/lxqt/liblxqt/issues/371
== calamares - keyboard layout setting broken in Wayland ==
* todo
* please set up for
** CLI user
** CLI sysmaint
** GUI user
** GUI sysmaint
* Aaron: Moving the systemd-localed keyboard layout set disable file out of the way does not result in labwc picking up the keyboard layout settings from Calamares. Will need to create a shellprocess module or similar to hack this into working right.
* Aaron: Implemented, changes pushed to helper-scripts, user-sysmaint-split, lxqt-wayland-session, and live-config-dist. All four scenarios now work as expected.
** Patrick: Merged.
* Patrick: Is this reported upstream, so one day Debian, calamares will be fixed and can be used without XWayland?
** Aaron: Looked at Debian's systemd bug reports, did not find anything. Filed a report of my own against the systemd package (as that's the package that ships /usr/share/dbus-1/system.d/systemd-localed-read-only.conf). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1118702
== Qubes misc review #2 ==
* https://github.com/QubesOS/qubes-core-agent-linux/pull/613
** Awaiting further feedback from HW42.
== kloak - handle dynamic keyboard layout changes ==
* when the user changes the keyboard layout in labwc, kloak's keyboard layout configuration does not change to match
* Aaron: Discovered this is a bug in labwc, reported: https://github.com/labwc/labwc/issues/3113
** Waiting on upstream's response. For now, we should document that one must restart kloak with Right Shift + Escape to make a keyboard layout change take effect.
== apt solver bug - pulling in incorrect alternative dependencies ==
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113744
* Obtain requested debugging information and attach to ticket
* Aaron: Added new information to ticket, waiting on response.
== trixie port - update derivative signing key derivative.asc ==
* plan how to use a new signing key
** Aaron: Where all do we use the signing key? It's used to sign:
*** apt packages
*** git commits
*** git tags
*** OS images
*** Warrant canaries?
**** These are signed by OpenBSD's signify tool, not GPG, thus their key migration does not necessarily have to be bound to derivative.gpg's rotation.
*** anything else?
** apt package migration:
*** Due to how apt packages work, it is probably best to do this during release upgrade. Ship a new version of the key in legacy-dist in Bookworm only, install it during the release upgrade procedure and ensure all packages that are ever a part of the trixie repositories are signed with the new key.
** git commit/tag migration:
*** The key expires, so there isn't a risk of it being used to sign newer packages after expiration. Just start signing commits with the new key and let expiration handle everything else.
*** Add the new key to the list of trusted keys in derivative-maker so that people can still build older tags/commits if they need to.
** OS image migration:
*** Just start using the new key to sign OS images. Announce the key change publicly (i.e. on the forums) so users expect to need to update their key. Sign the new key with the old key so that users with high security requirements can transition from one key to the next without having to re-establish trust in the key.
** Canary migration, if needed:
*** Can we just start signing canaries with the new key? Or do we need to put the canaries in a different location and stop updating the old ones?
* Patrick:
** The plan might be good enough.
** I might just extend the validity of the signing key and postpone this plan.
* Patrick:
** Key has been extended.
* Aaron:
** Moved to WAITING ON for now, we should move this back to TODO once we're ready to do the actual key rotation.
== investigate Tor Browser metadata signing and expiration ==
* in context of: https://github.com/QubesOS/qubes-issues/issues/9983#issuecomment-3028994433
* Tor Browser does not appear to sign metadata. Even metadata used by Tor Browser's internal updater might be relying on unsigned metadata.
* Important to explain: Not only signed metadata is required, also fresh metadata is required. Therefore periodic re-signing is required.
* Compare with Firefox: Does Firefox's internal updater even have this feature? If Firefox has it, making the argument for Tor Browser to enable it might be much easier. If not, it might be better to request this feature from Mozilla as well.
* goal of this ticket: The only goal of this ticket is to post feature requests / bug reports on Tor Project (and Mozilla issue tracker if applicable) and to properly communicate this.
* non-goal: implementation
* info:
** Tor Browser uses json files: https://aus1.torproject.org/torbrowser/update_3/release/download-linux-x86_64.json
** Firefox uses xml as per https://firefox-source-docs.mozilla.org/toolkit/mozapps/update/docs/InAppUpdateProcess.html
* draft:
'''Rollback Attacks Definition:'''
The Update Framework (TUF) defines `rollback attacks` [x]
> An attacker presents files to a software update system that are older than those the client has already seen. With no way to tell it is an obsolete version that may contain vulnerabilities, the user installs the software. Later on, the vulnerabilities can be exploited by attackers.
'''Rollback Attack Protection and Valid-Until Field'''
Rollback attacks attempt to trick the updater into applying an outdated (and potentially vulnerable) version of the software. One widely recommended mitigation against rollback attacks is using a "Valid-Until" field or equivalent freshness period in the signed metadata, after which a given update should no longer be accepted.
Firefox's internal updater does not publicly mention using a "Valid-Until" field (or explicit expiration on update metadata) to guarantee update freshness or safeguard against replay/rollback attacks in the same way as systems like The Update Framework (TUF) or Debian's APT
'''Non-solutions:'''
TLS might mitigate this attack but higher security than what TLS can offer should be provided in case TLS or server compromise.
'''Solution:'''
Server side:
Sign, automatically periodically re-sign update metadata.
Client side:
Accept only metadata signed up to a certain age.
'''Resources:'''
Mozilla has blogged about rollback attacks in the past. [x]
[x] https://theupdateframework.io/docs/security/
[x] https://blog.mozilla.org/attack-and-defense/2020/10/12/guest-blog-post-rollback-attack/
* Aaron: Filed issue against Tor Browser: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44039 Also requested a Tor Project Gitlab account, which I now have.
** I did not file a report against Mozilla Firefox, because their update mechanism involves automatically generated XML created by a backend server, whereas The Tor Project's update metadata seems to be static and not nearly as complicated.
== grml-debootstrap bootloader installation failure in Docker ==
* https://github.com/grml/grml-debootstrap/issues/348#issuecomment-3017083278
* please use discretion on how worthwhile it is to spend time on this. as in, if you think it's doable without huge effort and you like docker, please implement. Otherwise, please only provide instructions for reproduction and leave it to upstream or tableseeker to fix.
** Aaron: Ran into complications trying to fix this myself, handed off to tabletseeker for further investigation.
== grml-debootstrap - EFI partition size ==
* https://github.com/grml/grml-debootstrap/issues/221
* zeha currently does not want to implement this until systemd-boot "happens" (I'm guessing this means until it is supported by grml-debootstrap).
== ISO - GRUB - silence cosmetic errors in live ISO GRUB ==
* Earlier attempts to fix cosmetic errors in GRUB failed, since they introduced bugs into the live-build-provided boot screen.
* Investigate how to fix this, potentially make an upstream feature request or patch if needed
* Errors include loadfont issues, Secure Boot loading issues
* Sent email to grub-devel mailing list to investigate this
== ISO - memtest86+ ==
error: bad shim signature
* Fixable?
* Apparently requires a security review: [https://github.com/rhboot/shim-review/issues/314 Meta: Signing memtest86+ v6.10]
* [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032375 memtest86+: fails to work with Secure Boot enabled]
* Asked about what contributions would allow this to move forward on the debian-efi mailing list: [https://lists.debian.org/debian-efi/2024/12/msg00021.html Memtest86+ Secure Boot signing]
== test SysRq keys under LXQt Wayland ==
* ensure SysRq+unraw, SysRq+k behave as expected in context of [[Login spoofing]]
* Has issues, wlroots bug reported at https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3930
== ISO - changed files issues ==
(annoted)
+ debsums --silent
debsums: changed file /usr/sbin/sources-media (from calamares-settings-debian package) - issue for future verified boot
debsums: missing file /var/lib/dbus/machine-id (from dist-base-files package) - issue for Whonix-Host, non-ideal for Kicksecure but not a blocker
+ debsums --config --silent
debsums: changed file /etc/calamares/modules/unpackfs.conf (from calamares-settings-debian package) - issue for future verified boot
debsums: changed file /etc/cryptsetup-initramfs/conf-hook (from cryptsetup-initramfs package) - issue for future verified boot
debsums: changed file /etc/machine-id (from dist-base-files package) - issue for Whonix-Host, non-ideal for Kicksecure but not a blocker
* All of these are modified by live-build itself:
** /usr/sbin/sources-media is modified by live-build/share/hooks/normal/5050-dracut.hook.chroot so that it points to the proper location of the on-ISO apt repo when dracut is in use (the location is different when initramfs-tools is used). The need for this could potentially be removed by modifying the sources-media script to autodetect the correct location, though this requires upstream to be receptive to the idea.
*** Please discuss upstream. Since there is already some sort of dm-verity support in upstream live-build (scripts/build/binary_dm-verity), upstream might be receiptive.
**** Feature request filed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089618
** /var/lib/dbus/machine-id is deleted by live-build/share/hooks/normal/8020-remove-dbus-machine-id.hook.chroot, which has a note in it as follows: "This removes dbus machine id that cache that makes each system unique." This seems important and I can't think of an obvious way to avoid needing to do this. My Kicksecure VMs appear to have machine IDs, but it's unclear how they're being generated originally, so it may be worth enabling the machineid module in our Calamares configuration to ensure that the machine ID is properly generated.
*** See also: https://www.whonix.org/wiki/Protocol-Leak-Protection_and_Fingerprinting-Protection#Identifiers_Design_Goals
*** TODO: Discuss.
**** Proposal for fixing this made.
** /etc/calamares/modules/unpackfs.conf is modified by live-build/share/hooks/normal/5050-dracut.hook.chroot so that it points to the proper location of the on-ISO squashfs containing the operating system. Again, the location is different when initramfs-tools is used. This is a "hardcoded" configuration file, there isn't a way to add autodetection logic here. It might be possible to make a pull request to Calamares that would allow it to skip squashfses that didn't exist?
*** Yes, please discuss upstream.
**** Feature request filed: https://github.com/calamares/calamares/issues/2409
** /etc/cryptsetup-initramfs/conf-hook is modified by live-build/share/hooks/normal/1010-enable-cryptsetup.hook.chroot, where it is used to enable cryptsetup in initramfs-tools. Assuming this isn't legacy configuration, this seems important and I can't think of an obvious way to avoid needing to do this. Might be worth testing to see if this is still necessary though.
*** Yes, please.
**** Bug report made: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089624
** /etc/machine-id is deleted by live-build/share/hooks/normal/8020-remove-dbus-machine-id.hook.chroot. Has a very similar note to the other machine ID deletion hook. Same concerns apply.
*** Proposal for fixing this made.
== ISO - Finish Module Action Follow-Up ==
* https://github.com/calamares/calamares/issues/2321
* please follow-up
* Followed up on Matrix, will follow up again soon on Github if I don't get a response.
* Was informed by Adriaan de Groot that the code is still unfinished, and also on his radar.
== live-build - add mmdebstrap support ==
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031932
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031929
* Merge request: https://salsa.debian.org/live-team/live-build/-/merge_requests/370
== live-build - use APT with error-on-any ==
* use option apt --error-on=any for all invocations of apt-get (update)
* only needed for apt-get update, otherwise superfluous but non-issue
* this is a security feature
* this is to prevent inconsistent images that succeeded connecting to the "normal" repository but failed to connect to the security repository
* can be implemented using already existing live-build option --apt-options OPTION|"OPTIONS"?
* Requires a patch to live-build. Using --apt-options results in a build failure with E: Command line option --error-on=any is not understood in combination with the other options
* Patch written, submitted upstream as https://salsa.debian.org/live-team/live-build/-/merge_requests/371. New configuration option now used in my branch of live-build.
== security-misc - investigate PAM ==
* there is /etc/pam.d/sudo-i for interactive and /etc/pam.d/sudo
* pam has concepts of common-session-noninteractive vs common-session (non-interactive)
* how could we on the PAM level notice if faillock is used interactively or non-interactively?
* if non-interactive, skip faillock
* if interactive, do not skip faillock
* Bug reports:
** https://github.com/linux-pam/linux-pam/issues/842
** https://github.com/sudo-project/sudo/issues/415
* Once we go sudoless, this will no longer be a concern except for VMs that aren't sudoless.
== live-build - lb-binary should not run apt-get update ==
* todo
* Bug filed at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087470
* Note that the use of apt-get in the binary stage appears to be very baked into live-build's logic. It's pretty unlikely this will change.
= REVIEW PLEASE =
== forward port Debian trixie /etc/grub.d changes to Kicksecure ==
* our /etc/grub.d scripts are still based on bookworm
* merge useful changes introduce since Debian trixie
* keep the diff small (prefer out-commented over deleted)
* compare generated /boot/grub/grub.cfg with old versus new /etc/grub.d generator version
* Aaron: I believe we already did this; the native Trixie versions of these files are nearly identical to those in Kicksecure, and all of the differences shown by Meld look like we intentionally made them.
* Patrick: For code lines that we don't want to use, please copy them over but comment these out and comment why these aren't used.
** Aaron: Done. Commit pushed to dist-base-files.
== screen resolution documentation ==
* https://forums.kicksecure.com/t/configure-displays-doesnt-keep-modified-settings/1580
* please document
* Aaron: Wrote documentation, also created some helpers for making kanshi easier to use. Commits pushed to desktop-config-dist and sysmaint-panel.
* [[Desktop#Display_Configuration|Display Configuration]]
== systemcheck check journal of previous boot ==
* currently only checks current boot
* refactoring to also check previous boot to catch instant reboot issues
* make sure it also catches segfaults
* purpose: make systemcheck point out issues such as https://forums.kicksecure.com/t/black-login-screen-crash-after-inserting-external-hard-drive/1556 more easy for developers to debug. No more need to request journal log from user.
* Aaron: Implemented, many commits pushed to systemcheck. I found a bug in the journal checker that completely disabled it by accident, and after fixing it, a lot of research had to be done into all the new messages that were displayed as a result.
== tirdad versus kernel live patching ==
* https://github.com/0xsirus/tirdad/issues/30#issuecomment-3829513093
* please discuss plans of Debian regarding kernel live patching
** Aaron: Discussed a bit, looks like this is a non-issue. Livepatching was likely never enabled by default upstream, Debian explicitly enables it at the moment and there are likely incentives for them to leave it enabled.
== disable num lock by default ==
* Aaron:
** Some laptops make the right hand side of the keyboard into a virtual keypad. When num lock is enabled on that hardware, keys such as J, K, and L will behave as 1, 2, 3.
** We currently (unintentionally) enable num lock by default.
** This makes typing difficult until the user intentionally turns num lock off.
** Fixed, commit pushed to desktop-config-dist.
== user-sysmaint-split removal without purge improvement ==
* https://forums.whonix.org/t/unrestricted-admin-mode-on-new-whonix-18-is-not-bootable/22814
* Possible to have the postrm script do the cleanup to avoid the issue even if users are not using --purge?
** Aaron: Yes, by making the boot mode file no longer a conffile. Implemented, commit pushed to user-sysmaint-split.
*** Removing the file during uninstallation can probably be made to work, but apt doesn't re-create the file if the package is reinstalled, which causes bugs later. https://stackoverflow.com/q/27733709 suggests the "make it not a conffile" technique.
*** It may be possible to "purge" just this one file on uninstallation, and if we expect the user to modify it, that might be worthwhile. I have not attempted to do this yet though.
*** I did verify that using rm_conffile ... on the old conffile and replacing it with a link works in a whonix-workstation-18 TemplateVM. I also verified that rm_conffile doesn't delete symlinks. dpkg-maintscript-helper appears to move the conffile out of the way before the package is unpacked, in its prepare_rm_conffile function which is called during the preinst script run. This is most likely why this kind of migration does not result in an upgrade failure.
== document libvirt root escalation concerns ==
* membership in group libvirt is equivalent to passwordless root access, because users can leverage libvirt to create arbitrary SUID-root executables on the host.
* document this as a warning
** Aaron: Documented here: https://www.kicksecure.com/wiki/Dev/Strong_Linux_User_Account_Isolation#libvirt/KVM
== Qubes Tor Browser - lockfile and postinst bug ==
* bug: better way to exit in case of update-torbrowser is already running is needed
source /usr/libexec/helper-scripts/lockfile.sh
if ! source /usr/libexec/helper-scripts/lockfile.sh; then
log ...?
fi
* bug: if failing in postinst mode (in Template) because update-torbrowser is already running, should show an error but still exit 0 to avoid breaking DPKG
** The most robust solution might be to ignore non-zero exit codes in postinst unless its running inside chroot where nom-zero exit codes are needed depending on derivative-maker make --tb open versus --tb closed.
*** Aaron: Implemented this solution. Commits pushed to tb-updater.
== implement sudo wrappers - gsudo-wl gsudo-x ==
* add to helper-scripts (probably) or usability-misc?
* based on https://www.kicksecure.com/wiki/Root#Miscellaneous_Applications_with_Root_Rights
* just to simplify users do not have to write by hand the following:
sudo --set-home XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR application-name
sudo --set-home XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR QT_QPA_PLATFORM=wayland application-name
* usability-misc already comes with /usr/bin/gsudoedit. Probably ok and probably can stay there.
* Aaron: Implemented (though both scripts ended up being substantially more complicated than the one-liners above). Commit pushed to helper-scripts.
* Patrick:
** made minor changes
** mkdir --parents -- "${root_wayland_lock_dir}" - umask dependent, useful to use install instead?
* Aaron:
** Reviewed, adjusted the cleanup routine to check that all variables it uses are set.
** Switched to install after verifying that it worked as intended. Commits pushed to helper-scripts.
* Patrick: Merged.
* Patrick
** 1) bug: gsudo-x non-functional in non-Qubes (Wayland)
*** Aaron: Fixed.
** 2) bug: bash -x gsudo-x/gsudo-wl should be possible
*** Aaron: Fixed.
** 3) question/bug: Does it work with applications that are symlinks?
*** Aaron: It appears to, yes.
** 4) See this [https://www.kicksecure.com/w/index.php?title=Root&oldid=98397#Wayland old wiki revision of yours]. relevant quote
The following command should work to run Wayland applications as root in most instances. Replace application-name as appropriate:
sudo --set-home XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR application-name
Qt applications may try to use X11 by default, in which case this technique will fail. To override this and make Qt attempt to use Wayland instead, use:
sudo --set-home XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR QT_QPA_PLATFORM=wayland application-name
Which application needs QT_QPA_PLATFORM=wayland?
The purpose of gsudo-x or a similar gsudo wrapper is to cover applications that need QT_QPA_PLATFORM=wayland.
* Aaron: All Qt applications (to my awareness) require this variable. Similarly, most GTK applications require GDK_BACKEND=wayland. Both of these are being set in desktop-config-dist, which is why they don't usually have to be set manually.
** 5) If there are 3 wrappers, is it worth to have a shared library?
*** Aaron: Possibly, but we should only need one wrapper per display server we need to support. We only have X11 and Wayland display servers so far.
** 6) Do we need the ability to have X11 native applications to start as root? For example - inside non-Qubes - under Wayland: gsudo-x xeyes
*** xeyes is illustrative for testing. But do we need a wrapper that supports actual X11 only applications as root?
*** Aaron: This capability is provided by gsudo-x, and not providing it would be difficult or maybe impossible. xeyes works.
* 7) bug: Missing stderr output and non-zero exit code.
** For comparison only: Command sudo --set-home pcmanfm-qt fails, shows stderr(?) output and exits non-zero.
** bug: Command gsudo-wl pcmanfm-qt also fails but shows no output and exits 0 without doing anything.
*** Aaron: Likely not a bug. pcmanfm-qt refuses to run as root, outputs nothing to stdout or stderr about this, and exits 0 in this scenario. Other applications that do print output or exit non-zero have this information communicated correctly to the caller.
* 8) Can we reasonably support gsudo-wl|x|... ENV_VAR=content application-name? sudo supports that too. Minor. Telling users to use env in these cases would be okay too. Only good to implement if possible with a simple wrapper instead of lots of custom complex parsing code.
** Aaron: Was able to be implemented trivially by just running env in the gsudo scripts themselves.
* 9) Test cases:
** gsudo-[...] application-name that requires XDG_RUNTIME_DIR only
*** Aaron: foot terminal works here. sudo XDG_RUNTIME_DIR=/run/user/1001 foot works, and so does gsudo-wl foot. gsudo-x foot fails as expected.
** gsudo-[...] application-name that requires XDG_RUNTIME_DIR and QT_QPA_PLATFORM=wayland application
*** Aaron: Featherpad works here.
** gsudo-[...] xeyes (maybe)
*** Aaron: xeyes works with gsudo-x.
** gsudo-[...] pcmanfm-qt (maybe)
*** Aaron: Refuses to run as root even when run using sudo and manual environment variable manipulation.
* non-goal: gsudo-x doesn't necessarily need to support Qubes/X11. Qubes users can stay with lxsudo. No need to reinvent lxsudo.
* Aaron: Lots of commits pushed to a bunch of repos because of refactoring to simplify our "was script sourced or executed" detection routines. All of the above points should be dealt with now, commits not yet merged have been made to tb-updater and helper-scripts.
== tb-updater Kicksecure bugs ==
* Qubes App Qube -> boot into sysmaint session -> update-torbrowser
** tb-updater installs to sysmaint home folder
** tb-starter refuses to start
** Not sure what should happen. Should reject running? Or should set download folder to system-wide folder? tb-updater should avoid asking to start Tor Browser?
*** Aaron: Discussed, decided to allow starting Tor Browser in sysmaint sessions, but only if the user sets a configuration option to enable it.
* update-torbrowser --onion broken
** https://github.com/curl/curl/discussions/11125
** if using --onion, fix by setting CURL_PROXY similar to how it's done inside Whonix?
*** Aaron: Good idea, implemented.
* Aaron: Did some refactoring of helper-scripts while I was working on this. Commits pushed to browser-choice, helper-scripts, tb-starter, tb-updater, and user-sysmaint-split.
* Patrick: Merged.
== grub dpkg-new ==
* Could /etc/grub.d/10_linux.dpkg-new cause an issue?
dpkg -S /etc/grub.d/*
grub-common: /etc/grub.d/00_header
grub-common: /etc/grub.d/05_debian_theme
dist-base-files: /etc/grub.d/10_00_linux_dist
dist-base-files: /etc/grub.d/10_05_linux_main
dist-base-files: /etc/grub.d/10_50_linux_dist_advanced
dist-base-files: /etc/grub.d/10_55_linux_main_advanced
dpkg-query: no path found matching pattern /etc/grub.d/10_linux.dpkg-new
grub-common: /etc/grub.d/20_linux_xen
grub-common: /etc/grub.d/25_bli
grub-common: /etc/grub.d/30_os-prober
grub-common: /etc/grub.d/30_uefi-firmware
grub-common: /etc/grub.d/40_custom
grub-common: /etc/grub.d/41_custom
usability-misc: /etc/grub.d/44_kb_layout
grub-common: /etc/grub.d/README
zsh: exit 1 dpkg -S /etc/grub.d/*
* Aaron: Possibly. grub-mkconfig does not filter out .dpkg-new files under /etc/grub.d/* when generating the GRUB configuration file. However, the file must also be executable for grub-mkconfig to run it as part of the config file generation process, so if the .dpkg-new file is not executable, it will be benign.
** How did this file get generated? Was it a consequence of an OS update or upgrade? Is it executable?
== trixie-port - suspend bug ==
* user reported
* Bug: suspend results in black screen with no recovery (unless hard reboot)
* lock-screen reports it cannot lock the screen and system then frozen. Might not be related to lock-screen.
* Aaron: Cannot reproduce on my main development machine. On a testing machine, an instant reboot was observed after waking from sleep, but installing debug-misc made the reboots stop. Checking dmesg after wake revealed a kernel warning occurring while waking a device from suspend during a filesystem write. Issue is therefore likely hardware-specific, and may be resolved by disabling panic-on-warn.
= ARCHIVED =
= Footnotes =
{{Footer}}