QubesOS contrib package

[maltfield]

This ticket will track the effort to create a user-contributed package ("contrib package") for BusKill in QubesOS.

History

In 2017, I originally developed BusKill for QubesOS

In 2020, I opened a feature request with QubesOS to implement a LockScreen qrexec service into the main QubesOS directly -- hoping that would help with the install process of BusKill (preventing users from having to edit files on dom0 directly)

In 2022, I wrote an article describing how to install BusKill in QubesOS, but it requires the user to manually edit a bunch of files on dom0 and sys-usb

In 2023, Tom Hocker wrote a guide describing how to use YubiKey with Qubes, which included setting-up a keyboard shortcut for a temp disarm of BusKill (eg for bathroom breaks). I modified and re-posted a subset of his work in an article here

In Jan 2026, one of our users asked for BusKill to be integrated into Qubes, in a feature request with QubesOS

In Mar 2026, NovaCustom offered to fund implementation of a better install package for BusKill on QubesOS

[maltfield]

Back in 2020, I submitted a PR for the LockScreen qrexec service feature request

• Lock Screen qrexec service QubesOS/qubes-issues#5893
• adding new qubes.LockScreen and cooresponding policy file for issue: QubesOS/qubes-core-admin#349

It sat unnoticed for 6 years, until last week I got some comments from the QubesOS devs.

They didn't like that I was granting sys-usb the allow permission to be able execute the script (which locks the screen). I argued it's kinda-sorta a risk to let USB devices execute something on dom0, but that the action it would execute (locking the screen) would leave the device in a more secure state. And that it would pretty much defeat the purpose of feature if sys-usb didn't have that ability.

After some back-and-forth, I was told that I could leave it as deny (default closed) and then just tell our users (eg in our documentation) to change deny to allow. That would be slightly better than our current install method, but still kinda sucks

The devs also suggested another solution: that we could set it to allow in a "separate package" -- as then it would require some user action to install it, so allow would probably be fine since it's not shipped ootb with Qubes that way.

Separately, Andrew David Wong (Community manager at Qubes) told me in a few places that we might want to consider making a contrib package for BusKill. I asked for some examples that I could browse, and I got this:

• https://github.com/QubesOS-contrib/qubes-skeleton
• https://github.com/orgs/QubesOS-contrib/repositories

The former is a "skeleton" package for a QubesOS contrib package. It's useful as a fork-ready base for creating a new contrib package, but not really useful as an example of how contrib packages work.

The latter is a collection of 17 different contrib packages. I spent some time digging through them to find something that "places file A in dom0 at X location AND places file B in sys-usb AppVM at Y location", but I couldn't find anything after a brief search.

TODO: find a more complex example of a contrib package that installs a file in dom0 and another file in some other AppVM

[maltfield]

The 17 qubes-contrib repos are pretty chaotic. Many of them have a README that says the way to install it is to git clone and then copy stuff around, which really doesn't improve our situation at all..

I cloned them all, and searched for anything that says sys-usb (hoping to find something that installs files on dom0 and sys-usb). The one result wasn't very helpful

$ ls
build-issues				    qubes-qmenu
build-logs				    qubes-qvm-screenshot-tool
qubes-app-split-browser			    qubes-remote-desktop
qubes-app-split-git			    qubes-rofi
qubes-contrib-configs			    qubes-skeleton
qubes-core-admin-addon-bridge-device	    qubes-tunnel
qubes-core-agent-linux-addon-bridge-device  repos.txt
qubes-desktop-linux-i3-gaps		    securedrop-workstation-keyring
qubes-polybar				    updates-status
$ 

$ grep -irC4 'sys-usb' *
qubes-qmenu/qmenu-dm-  exit 2
qubes-qmenu/qmenu-dm-fi
qubes-qmenu/qmenu-dm-
qubes-qmenu/qmenu-dm-qube_list=$(qvm-ls --no-spinner --running -O NAME,LABEL |\
qubes-qmenu/qmenu-dm:  grep -vw 'dom0\|sys-usb')
qubes-qmenu/qmenu-dm-
qubes-qmenu/qmenu-dm-rearrange_qube_list
qubes-qmenu/qmenu-dm-
qubes-qmenu/qmenu-dm-devices_list=$(qvm-$device_type)
$ 

One repo has a sane install method

• https://github.com/QubesOS-contrib/qubes-remote-desktop

qubes-dom0-update qubes-remote-desktop

If we could just do a qubes-dom0-update qubes-buskill install, that would meet our needs.

I looked through that whole repo, and I didn't see anything that clearly said "put file A in the VM named X"

Many of these other repos are empty. Or forked from 404'd repos. With 0 contributors.

Before the devs pointed me in the direction of this 'contrib package', I thought things in Qubes were installed using salt. I'm going to look into how that works.

[maltfield]

The salt packaging that I was originally thinking about was from this thread (by user = unman):

• https://forum.qubes-os.org/t/tool-simple-set-up-of-new-qubes-and-software/13064/21

Described here:

• https://qubes.3isec.org/tasks.html
• Design and create salt formulas distribution method QubesOS/qubes-issues#1939
• https://doc.qubes-os.org/en/latest/user/advanced-topics/salt.html

TODO: read these and see if this meets our needs better

[maltfield]

I'm totally lost. I asked the QubesOS forums here:

• https://forum.qubes-os.org/t/novacustom-buskill-partnership/30425/8

[maltfield]

I created a separate, dedicated thread asking more questions here:

• https://forum.qubes-os.org/t/devs-time-estimates-for-officially-accepted-user-contributed-qubesos-packages/40008

[maltfield]

The Qubes team added better documentation to their skeleton repo, which now describes how to modify the skeleton example contrib package into something, copy it to dom0, and run it.

• https://github.com/QubesOS-contrib/qubes-skeleton/blob/master/README.md

[maltfield]

I cloned the QubesOS-provided skeleton repo into our own namespace here:

• https://github.com/BusKill/buskill-qubes-contrib

I'm currently working with @wessel-novacustom to draft some deliverables, acceptance criteria, etc for a publicly-available bounty for resolving this ticket.

I also created a specific project for this on our Open Collective, which is where we'll upload the acceptance criteria (and other description of the bounty) when it's ready

• https://opencollective.com/buskill/projects/qubes-package

[maltfield]

This ticket now has a bounty, currently valued at $2,340.00 USD

For more info, see this article

• https://www.buskill.in/qubes-package-bounty/

[aronowski]

I'd like to work on this bounty.
Some of my experience is that the official qubes-zfs-dkms package has been initially prepared by me and forked from my own repository. Regarding qubes-builderv2, I also did the work to make it run on GitHub workers with Docker executors, rather than only on Fedora.

I'd like to ask about the acceptance criteria: there is mentioned a default trigger to lock the screen - should the implementation account for a configuration, where xflock4 has been removed, perhaps as part of switching the desktop environment to KDE or a different one?

[maltfield]

Hi @aronowski,

Thanks :)

From my previous interactions with the qubes devs, I do think that they will require better testing around the screensaver -- though I've never heard any reports from users that the one from our guide does not lock the screen.

Nowaways, I believe we are using xfce4-screensaver-command -l. People on i3 are using i3lock .... Is there a solution not tool dependent?

@ben-grande might be able to provide better input on what the Qubes devs would expect in terms of cross-platform lockscreen support.

Our GUI app has much broader support, and just tries to execute all the things to lock all the screens. You might find it useful for this implementation:

• buskill-app/src/packages/buskill/__init__.py

  Line 1111 in a585f03

  def trigger_lockscreen_lin(self):

Do you have any other questions about the acceptance criteria?