Contributing a SaltStack module for qvm-appmenus

[Gregor Michels]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello everybody,

this is my first post (ever) to a mailing list so I am a bit nervous.

I would like to contribute a SaltStack state/execution module into
`qubes-mgmt-salt-dom0-qvm` to reproducible set the appmenu
whitelist and default-whitelist entries on qubes/templates.

This is the interface draft:
```yaml
example-template:
qvm.appmenus:
- update: yes|no # def: yes | call qvm-appmenus with --update
- synchronize: yes|no # def: no | call qvm-sync-appmenus beforehand
- applications: # qvm-appmenus --set-whitelist
- debian-xterm.desktop
- default_applications: # qvm-appmenus --set-default-whitelist
- debian-xterm.desktop
- firefox-est.desktop
- pavucontrol.desktop
```

After some code poking it seems to me that most of the
salt execution modules call `qvm-*` internally.
And because `qvm-appmenus` is unable to output the current
default-whitelist I am hesitant to plan for partial updates like adding or
removing entries.
I could check whether or not the given applications are actually
available (via the `--get-available` flag). But the format of the output
is unstable :/.
Finally I do not know if `qvm-sync-appmenus` only aggregates the
available applications into `~/.local/share/qubes-appmenus` or also
modifies the appmenus of dom0.


I've been causually coding python for some years now and also played a
bit with writing custom ansible modules. Hopefully that is enough to get
me started.

What do you think ?


Thanks you so much ! :)
-----BEGIN PGP SIGNATURE-----

iLUEARMKAB0WIQSmUrcBl0vlNHW3XbEWFX6sV4adiQUCYE6B2QAKCRAWFX6sV4ad
icRZAf9MVgGG7BuCZMsJ9BLjnq3w36nb8AHs2AAbwlgLSwTI0Qxw4fA+V1zEwAFy
Cfbe0lZy/7bU667n6RZS2/SOuw9sAfwPJ4clVDLWoHge7pBC1Vl0StWCsU44o6eu
oNbGT1DuTz9Go+7HL7gq//MAvPtpRaEmcsRvw3kkIrhV/Q9CuICw
=1fF5
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Mar 14, 2021 at 10:36:37PM +0100, Gregor Michels wrote:
> Hello everybody,
>
> this is my first post (ever) to a mailing list so I am a bit nervous.

Hello!

> I would like to contribute a SaltStack state/execution module into
> `qubes-mgmt-salt-dom0-qvm` to reproducible set the appmenu
> whitelist and default-whitelist entries on qubes/templates.

Yay!

> This is the interface draft:
> ```yaml
> example-template:
> qvm.appmenus:
> - update: yes|no # def: yes | call qvm-appmenus with --update
> - synchronize: yes|no # def: no | call qvm-sync-appmenus beforehand
> - applications: # qvm-appmenus --set-whitelist
> - debian-xterm.desktop
> - default_applications: # qvm-appmenus --set-default-whitelist
> - debian-xterm.desktop
> - firefox-est.desktop
> - pavucontrol.desktop
> ```

I would recommend a syntax that allows to express "menu must contain app
X" and "menu must not contain app Y". At the very least for
"applications". Otherwise it will be hard to have more than one state
about menus.

> After some code poking it seems to me that most of the
> salt execution modules call `qvm-*` internally.
> And because `qvm-appmenus` is unable to output the current
> default-whitelist I am hesitant to plan for partial updates like adding or
> removing entries.

Actually, in Qubes 4.1 (alpha), those lists are stored in "features" and
can be retrieved via `qvm-features <vmname> menu-items`, `qvm-features
<vmname> default-menu-items` etc. And it seems this change is yet
another thing that wasn't updated in the documentation...

> I could check whether or not the given applications are actually
> available (via the `--get-available` flag). But the format of the output
> is unstable :/.

It is true. But on the other hand, in some cases it is actually useful
to add an application that isn't there yet - but for example will be
installed in another stage. Salt in qubes first applies changes to dom0
and only then to templates and other VMs, so it definitely can happen
that the application isn't installed _yet_.

> Finally I do not know if `qvm-sync-appmenus` only aggregates the
> available applications into `~/.local/share/qubes-appmenus` or also
> modifies the appmenus of dom0.

qvm-sync-appmenus retrieves list of installed applications (and their
icons) from VM, and then refreshes the actual menu based on whitelists
set before. But also, the list of applications should be automatically
updated whenever the template is updated (including installing new apps
etc).

> I've been causually coding python for some years now and also played a
> bit with writing custom ansible modules. Hopefully that is enough to get
> me started.

Most of the menus handling code is here:
https://github.com/QubesOS/qubes-desktop-linux-common/tree/master/qubesappmenus

I don't think you'll need to modify it or import directly, but it may be
helpful to clarify some details.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmBOx9wACgkQ24/THMrX
1yxwZAf+KdQGfcNppcebS8IcztLvsbHrCtavV40Hyym3Y9+nYjDwqWQlj9wyjN2p
SpVb0u+IsCy3+VeyZiWUzcj/2JomwdZRzE+/Pe129UYGTaIt3cOBzSjtXJ1nlJ1X
ldq5GxYB91z3ot6qha8pCTY+AsSAbqmlD2+0rAUVKC2WgJq3v9t/OyWBNGOi6vl3
gXfz/s3EdlLcKoULqtU9hVNlmNdsRqTzo7CMReNmCxISZZ3KlyFW0JBQALZ2v6XF
Q3mBGHDZD3uOB88DiOEmtRzzjeTPzs5Xo/MnGdY6tvsODt0vVA0YD9Lm4vRo0JMK
ixBlByJodj6XjWgLOYEMJR9MhkMBqA==
=1Hu1
-----END PGP SIGNATURE-----

[Manuel Amador (Rudd-O)]

Good point.  Syntax may actually be a dict instead of a list of enabled ones, with the values of the dict being booleans for configuring yes/no to the menu entry.