Kicksecure Qubes Template Development - Qubes Integration

qubes-template-kicksecure-17 4.2.0-202504261018 (r4.2)

opened 10:18AM - 26 Apr 25 UTC

fepitre-bot

r4.2-building

Template kicksecure-17 4.2.0-202504261018 for Qubes OS r4.2, see comments below …for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.2 kicksecure-17 4.2.0-202504261018 templates-itl` (available 5 days from now) * `Upload-template r4.2 kicksecure-17 4.2.0-202504261018 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Patrick · May 7, 2025, 4:22am

always built Templates for Qubes stable and development version?

opened 04:21AM - 07 May 25 UTC

adrelanos

P: default

### Qubes OS release R4.2 R4.3 ### Brief summary Kicksecure; and Qubes-Whonix… Templates are built for Qubes stable version (R4.2 at time of writing) only by me. ### Steps to reproduce n/a ### Expected behavior Some people may expect the Templates to also be available for Qubes development version (R4.3 at time of writing). In response to my [announcement of availability of Qubes Kicksecure Template for testers](https://forum.qubes-os.org/t/kicksecure-17-template/31893/11), @alimirjamali said: > Would it be possible to trigger a template build for r4.3 as well? For testing users who are on R4.3 alpha. ### Actual behavior Templates are built for Qubes stable version only. ### Additional information Why not simply always build for stable and development version of Qubes? I don't know if there are computational and/or storage restraints by Qubes build servers. related: * https://github.com/QubesOS/qubes-issues/issues/9573 ### Desired outcome of this ticket A Qubes core team member expressing the policy. Potential replies: * > No problem, it is OK and wanted to always build Templates for Qubes stable and Qubes development version. * > Qubes development Templates should be built on demand or when deemed necessary, but some sort of restraint would be desirable to save disk space. ### Potential outcome I'd modify [dm-qubes-templates-official-build-commands](https://github.com/Kicksecure/developer-meta-files/blob/master/usr/bin/dm-qubes-templates-official-build-commands) to add either a reminder or automation to build Templates also for Qubes development version.

Patrick · May 18, 2025, 11:25am

qubes-template-kicksecure-17 4.2.0-202505131900 (r4.2)

opened 07:00PM - 13 May 25 UTC

fepitre-bot

r4.2-testing

Template kicksecure-17 4.2.0-202505131900 for Qubes OS r4.2, see comments below …for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.2 kicksecure-17 4.2.0-202505131900 templates-itl` (available 5 days from now) * `Upload-template r4.2 kicksecure-17 4.2.0-202505131900 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Patrick · May 24, 2025, 5:03pm

Template kicksecure-17-4.2.0-202505131900 was uploaded to templates-community repository.

Patrick · August 19, 2025, 8:51am

qubes-template-kicksecure-17 4.2.0-202508121120 (r4.2)

opened 11:20AM - 12 Aug 25 UTC

fepitre-bot

r4.2-testing

Template kicksecure-17 4.2.0-202508121120 for Qubes OS r4.2, see comments below …for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.2 kicksecure-17 4.2.0-202508121120 templates-itl` (available 5 days from now) * `Upload-template r4.2 kicksecure-17 4.2.0-202508121120 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Patrick · September 12, 2025, 11:25am

Template kicksecure-17-4.2.0-202508121120 was uploaded to templates-community repository.

Patrick · September 13, 2025, 8:41am

decide availability of Kicksecure, and Whonix 18 (Debian trixie based) on Qubes R4.2 versus R4.3

opened 08:40AM - 13 Sep 25 UTC

adrelanos

P: default

Kicksecure, and Whonix 18 (Debian trixie based) are in development. As a develop…er, I guesstimate that hopefully a release can be made within the next approximately 2 weeks. (Please don't quote me on it.) Would it be sufficient if Kicksecure, and Whonix 18 are made available for Qubes R4.3 only? I.e. would be it be OK if Kicksecure, and Whonix 18 would not be made available for Qubes R4.2? That would simplify development, maintenance, testing. Primarily, pull request https://github.com/QubesOS/qubes-core-admin-addon-whonix/pull/21 has been merged for Qubes R4.3 but we didn't backport it to Qubes R4.2 yet. This would cause [qrexec `sdwdate.ConnectCheck` denied messages](https://forum.qubes-os.org/t/whonix-18-denied-sdwdate-connectcheck/36098) on Qubes R4.2. What's the guestimate for the Qubes R4.3 release date? Related tickets: * https://github.com/QubesOS/qubes-issues/issues/10020 * https://github.com/QubesOS/qubes-issues/issues/7447 Related: * [Kicksecure Support Schedule](https://www.kicksecure.com/wiki/About#Support_Schedule) * [Whonix Support Schedule](https://www.whonix.org/wiki/About#Support_Schedule)

Patrick · October 3, 2025, 2:03pm

github.com/QubesOS/qubes-core-agent-linux

Add qubes-core-agent-pcmanfm-qt integration package

main ← ArrayBolt3:arraybolt3/pcmanfm-qt

opened 10:29PM - 26 Sep 25 UTC

+104 -2

This will be used by Whonix 18, since our default file manager will be PCManFM-Q…t. Some rough spots that may need ironed out: * This reuses the `qvm-actions.sh` script from qubes-core-agent-thunar. At the moment this is done by simply copying `qubes-rpc/thunar/qvm-actions.sh` into the `qubes-core-agent-pcmanfm-qt` package, which is horrible. Duplication isn't a workable solution though because the package build procedure installs all of the files from all of the agent packages at once and then splits them into binary packages, and both `qubes-core-agent-thunar` and `qubes-core-agent-pcmanfm-qt` place `qvm-actions.sh` at the same location on the filesystem. This shared location also means that `qubes-core-agent-thunar` and `qubes-core-agent-pcmanfm-qt` have to conflict with each other. Ideally this script would be located in some shared package, but I'm not sure there's an appropriate one already existing, and I'm not sure making a new package shared only between `qubes-core-agent-thunar` and `qubes-core-agent-pcmanfm-qt` is warranted when this is just one script file. * The .desktop files used to define the actions that can be performed on each file have to use mime types to specify what files those actions are intended to match. As it turns out, there is no good way to express "match all files regardless of type, but do not match directories" as a mime type or combination thereof, so instead we currently just use "match everything" globs even on actions that don't work on directories, then display a popup warning if a directory is detected. I do not know of any good alternative to this. * Because file types are specified by mime type rather than file name extension, there is likely some introspection done on the files to determine what actions to display. I have no idea how secure Qt's mime type detection routines are, or if pcmanfm-qt even uses those routines for mime type detection as opposed to using something like `file`. I also don't know if there's a way to turn that detection logic off, and even if there was, that would break the ability to do things like only showing "Convert PDF in disposable qube" for PDF files.

github.com/QubesOS/qubes-app-linux-pdf-converter

Add pcmanfm-qt integration

main ← ArrayBolt3:arraybolt3/pcmanfm-qt

opened 03:53AM - 01 Oct 25 UTC

+18 -2

Adds a context menu item for PCManFM-Qt, which will be the default file manager …in Whonix 18. Whonix won't have any use for the this shortcut being available in pcmanfm-qt on RPM-based distros, but I did add the file to the RPM since every other file manager was supported by the RPM and I felt it would be sloppy to omit that. Related: https://github.com/QubesOS/qubes-core-agent-linux/pull/608

Patrick · October 5, 2025, 3:49pm

`XDG_DATA_DIRS` is reset to a minimal list of directories in applications opened from the Qubes app menu, breaking default application resolution

opened 03:43PM - 05 Oct 25 UTC

P: default

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) ###… Qubes OS release R4.3 ### Brief summary Whonix modifies the `XDG_DATA_DIRS` environment variable via scripts in `/etc/profile.d` (and `/etc/zprofile.d`). These modifications allow Whonix to customize things such as default application associations. These changes are picked up by Qubes OS and do appear in login shells, but somehow `XDG_DATA_DIRS` (and to my awareness, *only* `XDG_DATA_DIRS`) is reset to a "minimal" set of directories in applications that are opened from the Qubes app menu. This results in all of Whonix's file association settings usually being ignored. ### Steps to reproduce * Install a Whonix-Workstation 18 template. * Create an AppVM based off this template, and launch QTerminal in it. * Run `echo $XDG_DATA_DIRS`. * Open Qube Manager, select the Whonix-Workstation 18 AppVM, and click "Open console in qube". * Log in as "user" (no password required), then run `echo $XDG_DATA_DIRS`. ### Expected behavior In both instances, `echo $XDG_DATA_DIRS` should output `/usr/share/usability-misc/xdg-override/:/usr/share/anon-apps-config/share/:/usr/share/open-link-confirmation/xdg-override:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/` or similar. ### Actual behavior In the DispVM console, `echo $XDG_DATA_DIRS` outputs the expected value, but in QTerminal, the returned string is `/home/user/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/`. ### Additional information This is contributing to an issue, where clicking on the Qubes Domains widget in the system tray, hovering over a Whonix-Workstation 18 qube, and clicking "Open File Manager" opens Catfish File Search rather than PCManFM-Qt. Whonix ships a file at `/usr/share/usability-misc/xdg-override/applications/defaults.list` that is supposed to set the default application for `inode/directory` to `pcmanfm-qt.desktop`. Right now that file is out-of-date and is pointing to `thunar.desktop` instead, but even when it is changed to point to `pcmanfm-qt.desktop`, Catfish still opens when clicking this button in the widget. Running `xdg-open $HOME` in QTerminal also opens Catfish. However, running `DISPLAY=:0 xdg-open $HOME` in the DispVM console opens PCManFM-Qt as expected. (Granted, it looks awful because `QT_QPA_PLATFORMTHEME='lxqt'` is strangely not being set properly, but that's an unrelated issue.) The only thing I see in Qubes' code that looks like it modifies `XDG_DATA_DIRS` is https://github.com/QubesOS/qubes-core-agent-linux/blob/bffc6e0d0df3874781c0feda8297be5063fabba1/qubes-rpc/qubes.StartApp. Could this be part of the issue?

Patrick · October 5, 2025, 3:59pm

On first use, DispVM console has strange control character sequences preloaded into the `login:` prompt, causing the first authentication attempt to fail

opened 03:56PM - 05 Oct 25 UTC

P: default

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) ###… Qubes OS release R4.3 ### Brief summary When using the "Open console in qube" feature of Qube Manager to open a DispVM console for a qube, the character sequence `^[[24;1R^[[24;80R^[[24;1R^[[24;80R` is pre-populated in the `login:` prompt. If I ignore this weird sequence of characters, enter the username `user`, and press Enter, I immediately get the message `Authentication failure`. A new login prompt then appears that doesn't have this weird sequence preloaded into it. Typing `user` into that prompt and pressing Enter results in a successful login. I can also use Backspace to erase most of the character sequence, then type `user` and press Enter to log in successfully the first time. ### Steps to reproduce * In Qube Manager, click any qube (doesn't seem to matter which, I can reproduce this on a Fedora 42 AppVM, a Whonix-Workstation 18 AppVM, and the debian-13-xfce template), click "Start/Resume", then click "Open console in qube". * Look at the `login:` prompt before attempting to log in. * Type `user` and press Enter. * After the authentication failure, type `user` again and press Enter. * Shut down the qube. * In Qube Manager, click any qube, then click "Start/Resume", then click "Open console in qube". * When the `login:` prompt occurs, press and hold Backspace until as many characters as you can erase are erased. * Type `user` and press Enter. ### Expected behavior No character sequence should be preloaded into the `login:` prompt. Typing `user` and pressing Enter should work to log in the first time. ### Actual behavior The character sequence mentioned previously is preloaded into the `login:` prompt. Typing `user` and pressing Enter fails the first time but works the second time. When trying to erase the character sequence, it is possible to erase *most* of it, but not the entirety of it. Despite this, typing `user` and pressing Enter after erasing as much of the sequence as possible still works to log in. ### Additional information n/a

Patrick · October 5, 2025, 4:04pm