[GSoc] Template Manager Draft Design & Questions

[WillyPillow]

Hi.

The following is a draft design of the proposed template manager tool.

Supported Operations
===

- list available/installed templates (~= `dnf {info,list}`)
- install template from repo/existing RPM (~= `dnf install`)
- download template from repo (~= `--downloadonly`)
- force upgrade/downgrade/reinstall template (~= `dnf
{upgrade,downgrade,reinstall}`)
- remove template (~= `dnf remove`)
- search for templates in repo (~= `dnf search`)

Other Possibly Relevant DNF Operations
---

It might be useful to have analogies of the following DNF operations:

- `clean`: clean downloaded RPMs, repo metadata, ...etc
- `repolist`: manage repos, e.g., `qubes-templates-community`

Other Possible Features
---

- use kernel in template (i.e., set to PVGrub by default)
- ability to output information in machine-readable format (JSON?), as mentioned
in <https://github.com/QubesOS/qubes-issues/issues/2534>
- ability to install templates in alternative pools, again mentioned in #2534
- when removing templates, possibly remove associated AppVMs or have their templates
set to `dummy`[^1])
- set template of AppVMs (merge with current `qubes-template-manager`?) (low
priority)

[^1]: Similar to `qtm purge` mentioned
[here](https://github.com/QubesOS/qubes-issues/issues/2064).

Design Discussions
===

### Package Format ###

As previously discussed, it should be possible to directly use RPMs, extracting
root images from there.

For the file structure, it should suffice to place the images at the same
locations as they are now, with the benefit of backward compatibility.

(As a side note, is splitting the image files still needed?
<https://github.com/QubesOS/qubes-issues/issues/1326> seemed to indicate that it
is okay to not do it on newer versions of Fedora?)
(I'll probably experiment with this later.)

There may be use cases in which custom metadata is required, e.g., whether to
set PVGrub as the kernel. Unfortunately, AFAIK it is not possible to have custom
attributes in the RPM header. As such, it may be desirable to have a separate
file in the RPM containing the information, either in JSON or simply `KEY=VALUE`
format.

Interacting with repos and dealing with RPMs should be doable with
`python-{dnf,rpm}`. That being said, a preliminary search seems to show that
they do not provide a straightforward way of verifying the signature of or
extracting files from RPMs, so calling the CLI tools may still be needed.

### Metadata Storage ###

The template manager needs to store metadata of installed templates such as
version information. The current solution I have in mind is to store them as
per-VM properties, basically similar to the current `installed_by_rpm` so that
it is easier to keep things consistent when, e.g., `qvm-remove` is used.
Besides, backups are also more easily handled this way.

To keep things tidy, perhaps it is better to have the properties start with a
common prefix, say `qtm_XXX`.

(Care may still be needed when a template is renamed though. Would it be more
intuitive for the user if a template is treated as non-RPM-installed once
renamed?)

### Permissions ###

To achieve features such as `qtm purge`, the template manager needs to have
corresponding AdminAPI access to change the templates of other AppVMs. However,
one might wish for the management VM not to be able to see/control all VMs.
Maybe more fine-grained rules can be created? (For instance, making the mgmtVM
only able to change the templates of AppVMs that are based on templates managed
by itself.)

(Alternatively, one can simply disable the functionality in such cases.)

### Naming ###

> "There are two hard things in computer science: cache invalidation, naming
> things, and off-by-one errors."

Jokes aside, I think `qtm`, as proposed in #1326, is a reasonable name for the
CLI tool.

- - -

By the way, should I place this on, say, a Gist so that it's easier to see
the latest revision?

Thanks,
WillyPillow

> https://blog.nerde.pw/
>
> PGP fingerprint = 6CCF 3FC7 32AC 9D83 D154 217F 1C16 C70E E7C3 1C84
>
> Protonmail PGP = D02D CEFF ACE5 5A7B FF5D 871E 4004 1CB1 F52B 127E

[WillyPillow]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Thursday, June 4, 2020 3:02 AM, WillyPillow <w...@nerde.pw> wrote:

> (As a side note, is splitting the image files still needed?
> https://github.com/QubesOS/qubes-issues/issues/1326 seemed to indicate that it
> is okay to not do it on newer versions of Fedora?)
> (I'll probably experiment with this later.)

It seems that it works on R4.0 with fc25 dom0. (Tested by adding an additional
large sparse file to the RPM.)

While the sparse-ness is not preserved, my understanding is that i) the increase
in size of the package is not a problem, as per the issue, and ii) the image is
read in full and imported to a pool in `qvm-template-postprocess`, so whether
the extracted image is sparse does not matter much.

[Marek Marczykowski-Górecki]

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

On Wed, Jun 03, 2020 at 07:02:01PM +0000, WillyPillow wrote:
> Hi.

Hi!

> The following is a draft design of the proposed template manager tool.
>
> Supported Operations
> ===
>
> - list available/installed templates (~= `dnf {info,list}`)
> - install template from repo/existing RPM (~= `dnf install`)
> - download template from repo (~= `--downloadonly`)
> - force upgrade/downgrade/reinstall template (~= `dnf
> {upgrade,downgrade,reinstall}`)
> - remove template (~= `dnf remove`)

Yes, the tool should have such option. But also, one of the goals of
this project is to un-break removing templates as any other VM (i.e.
normal qvm-remove should also work on template).

> - search for templates in repo (~= `dnf search`)
>
> Other Possibly Relevant DNF Operations
> ---
>
> It might be useful to have analogies of the following DNF operations:
>
> - `clean`: clean downloaded RPMs, repo metadata, ...etc
> - `repolist`: manage repos, e.g., `qubes-templates-community`
>
> Other Possible Features
> ---
>
> - use kernel in template (i.e., set to PVGrub by default)
> - ability to output information in machine-readable format (JSON?), as mentioned
> in <https://github.com/QubesOS/qubes-issues/issues/2534>
> - ability to install templates in alternative pools, again mentioned in #2534
> - when removing templates, possibly remove associated AppVMs or have their templates
> set to `dummy`[^1])
> - set template of AppVMs (merge with current `qubes-template-manager`?) (low
> priority)

Yes, all good to have, but lets focus on core functionality first.

> [^1]: Similar to `qtm purge` mentioned
> [here](https://github.com/QubesOS/qubes-issues/issues/2064).
>
> Design Discussions
> ===
>
> ### Package Format ###
>
> As previously discussed, it should be possible to directly use RPMs, extracting
> root images from there.
>
> For the file structure, it should suffice to place the images at the same
> locations as they are now, with the benefit of backward compatibility.
>
> (As a side note, is splitting the image files still needed?
> <https://github.com/QubesOS/qubes-issues/issues/1326> seemed to indicate that it
> is okay to not do it on newer versions of Fedora?)
> (I'll probably experiment with this later.)

I think splitting is not needed, but internal I'd keep internal tar
archive, to preserve sparseness (should result in faster installation
and less temporary space needed if that would be used).

> There may be use cases in which custom metadata is required, e.g., whether to
> set PVGrub as the kernel. Unfortunately, AFAIK it is not possible to have custom
> attributes in the RPM header. As such, it may be desirable to have a separate
> file in the RPM containing the information, either in JSON or simply `KEY=VALUE`
> format.

Yes, I think separate file should be ok. The format should be easy to
parse without too complex tools - while it would be loaded after
signature verification, at some point we want to support more relaxed
approach for community templates, so the template parser should be
resilient against malicious metadata file.
`KEY=VALUE` sounds good.

Here is some attempt:
https://github.com/QubesOS/qubes-linux-template-builder/pull/15
As you can see in comments there, I don't like some parts, but maybe
it will give you some inspiration.

> Interacting with repos and dealing with RPMs should be doable with
> `python-{dnf,rpm}`. That being said, a preliminary search seems to show that
> they do not provide a straightforward way of verifying the signature of or
> extracting files from RPMs, so calling the CLI tools may still be needed.

Yes, that sounds correct. Most likely you'll need rpm2cpio and rpmkeys
tools.

> ### Metadata Storage ###
>
> The template manager needs to store metadata of installed templates such as
> version information. The current solution I have in mind is to store them as
> per-VM properties, basically similar to the current `installed_by_rpm` so that
> it is easier to keep things consistent when, e.g., `qvm-remove` is used.
> Besides, backups are also more easily handled this way.
>
> To keep things tidy, perhaps it is better to have the properties start with a
> common prefix, say `qtm_XXX`.

In fact, those don't need to be full properties, you can use "features"
(qvm-features), which is basically key-value store for each VM.

> (Care may still be needed when a template is renamed though. Would it be more
> intuitive for the user if a template is treated as non-RPM-installed once
> renamed?)

That's a tricky question, but I think we can indeed start with
this approach. But it may be good to save some information about
template origin in the vm features, even if only as a hint for the user.

> ### Permissions ###
>
> To achieve features such as `qtm purge`, the template manager needs to have
> corresponding AdminAPI access to change the templates of other AppVMs. However,
> one might wish for the management VM not to be able to see/control all VMs.
> Maybe more fine-grained rules can be created? (For instance, making the mgmtVM
> only able to change the templates of AppVMs that are based on templates managed
> by itself.)

We have very similar issue with GUI VM - basically GUI VM needs some
access to VMs connected to it. We do that by automatically adjusting
tags based on "guivm" property:
https://github.com/QubesOS/qubes-core-admin/blob/master/qubes/ext/gui.py#L55-L77

And then have a static policy that is based on those tags.
We can probably use similar approach here.

> (Alternatively, one can simply disable the functionality in such cases.)
>
> ### Naming ###
>
> > "There are two hard things in computer science: cache invalidation, naming
> > things, and off-by-one errors."
>
> Jokes aside, I think `qtm`, as proposed in #1326, is a reasonable name for the
> CLI tool.

What about qvm-template?

> - - -
>
> By the way, should I place this on, say, a Gist so that it's easier to see
> the latest revision?

Yes, that sounds like a good idea. But for discussion it would still be
useful to do that via email here.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7ZX2EACgkQ24/THMrX
1yzDIgf9H4AS56i6FYTCtqlFtafVlpF1WH/MKGN6S880juvy0DeL62oXj7iGGkr3
c2FW9/GYVvwWX6fOsSha+IFJI+Stb5oKLWZghnfJle67sHYco2J59ev2I7v/iqIX
oU58k+cx8ji3uItE8lyPnG7Z14bhpEhnK5yeUApSBjeqVc6n6n61Lg5+WYxSmj41
n42AHbfAwAMxdh+w4YAs3kURGTwAm6WFe68SZfzJiyE4VJWRTmUevyQx6NBQrIzu
qHQHlPLcv/Y+vxiSadOpecm86Nxfk6wHb6wriJO3Yi5eXdYptnzkCkvf6PDi9Hzc
k/yxzL+KQ4GE2OuVJI4gttfUvMzqmw==
=bd6f
-----END PGP SIGNATURE-----

[WillyPillow]

On Friday, June 5, 2020 4:53 AM, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:

> On Wed, Jun 03, 2020 at 07:02:01PM +0000, WillyPillow wrote:

> > (snip)

> > - remove template (~= `dnf remove`)
>

> Yes, the tool should have such option. But also, one of the goals of
> this project is to un-break removing templates as any other VM (i.e.
> normal qvm-remove should also work on template).

True, hence the mention in the metadata section below.

> > - search for templates in repo (~= `dnf search`)
> >

> > Other Possibly Relevant DNF Operations
> >

> > ---------------------------------------

> >

> > It might be useful to have analogies of the following DNF operations:
> >

> > - `clean`: clean downloaded RPMs, repo metadata, ...etc
> > - `repolist`: manage repos, e.g., `qubes-templates-community`
> >

> > Other Possible Features
> >

> > ------------------------
> > (snip)

>
> Yes, all good to have, but lets focus on core functionality first.
>

> > [^1]: Similar to `qtm purge` mentioned

> > here.
> >

> > Design Discussions
> >

> > ===================
> >

> > ### Package Format

Should something like `vcpus` and `memory` be placed in the file? After all,
allowing a VM to set its own resource limits would probably create a lot of
issues.

> > Interacting with repos and dealing with RPMs should be doable with
> > `python-{dnf,rpm}`. That being said, a preliminary search seems to show that
> > they do not provide a straightforward way of verifying the signature of or
> > extracting files from RPMs, so calling the CLI tools may still be needed.
>

> Yes, that sounds correct. Most likely you'll need rpm2cpio and rpmkeys
> tools.
>

> > ### Metadata Storage
> >

> > The template manager needs to store metadata of installed templates such as
> > version information. The current solution I have in mind is to store them as
> > per-VM properties, basically similar to the current `installed_by_rpm` so that
> > it is easier to keep things consistent when, e.g., `qvm-remove` is used.
> > Besides, backups are also more easily handled this way.
> > To keep things tidy, perhaps it is better to have the properties start with a
> > common prefix, say `qtm_XXX`.
>

> In fact, those don't need to be full properties, you can use "features"
> (qvm-features), which is basically key-value store for each VM.
>

> > (Care may still be needed when a template is renamed though. Would it be more
> > intuitive for the user if a template is treated as non-RPM-installed once
> > renamed?)
>

> That's a tricky question, but I think we can indeed start with
> this approach. But it may be good to save some information about
> template origin in the vm features, even if only as a hint for the user.

Probably a minor detail, but is there a way to make cloned VMs behave
differently than renamed VMs?

> > ### Permissions

> >

> > To achieve features such as `qtm purge`, the template manager needs to have
> > corresponding AdminAPI access to change the templates of other AppVMs. However,
> > one might wish for the management VM not to be able to see/control all VMs.
> > Maybe more fine-grained rules can be created? (For instance, making the mgmtVM
> > only able to change the templates of AppVMs that are based on templates managed
> > by itself.)
>

> We have very similar issue with GUI VM - basically GUI VM needs some
> access to VMs connected to it. We do that by automatically adjusting
> tags based on "guivm" property:
> https://github.com/QubesOS/qubes-core-admin/blob/master/qubes/ext/gui.py#L55-L77
>

> And then have a static policy that is based on those tags.
> We can probably use similar approach here.
>

> > (Alternatively, one can simply disable the functionality in such cases.)
> >

> > ### Naming
> >

> > > "There are two hard things in computer science: cache invalidation, naming
> > > things, and off-by-one errors."
> >

> > Jokes aside, I think `qtm`, as proposed in #1326, is a reasonable name for the
> > CLI tool.
>

> What about qvm-template?

That makes a lot of sense (and fits in with the existing tools) :)

> > By the way, should I place this on, say, a Gist so that it's easier to see
> > the latest revision?
>

> Yes, that sounds like a good idea. But for discussion it would still be
> useful to do that via email here.

I re-formated the original text and amended it according to your suggestions.
The Gist can be accessed
[here](https://gist.github.com/WillyPillow/b8a643ddbd9235a97bc187e6e44b16e4).

Also, I noticed that in `qvm_template_postprocess.py`
(<https://github.com/QubesOS/qubes-core-admin-client/blob/e700af9eb2c1b39b065c476b2502a1f6a94d054e/qubesadmin/tools/qvm_template_postprocess.py#L145>),
it is mentioned that the call to `qvm-appmenus` (which, from what I've gathered,
only works in dom0) will be switched to qrexec calls in the future. Is there
currently a qrexec call for this?

[Marek Marczykowski-Górecki]

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

On Sun, Jun 07, 2020 at 01:39:59PM +0000, WillyPillow wrote:
> On Friday, June 5, 2020 4:53 AM, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:
>
> > On Wed, Jun 03, 2020 at 07:02:01PM +0000, WillyPillow wrote:
> > > There may be use cases in which custom metadata is required, e.g., whether to
> > > set PVGrub as the kernel. Unfortunately, AFAIK it is not possible to have custom
> > > attributes in the RPM header. As such, it may be desirable to have a separate
> > > file in the RPM containing the information, either in JSON or simply `KEY=VALUE`
> > > format.
> >
>
> > Yes, I think separate file should be ok. The format should be easy to
> > parse without too complex tools - while it would be loaded after
> > signature verification, at some point we want to support more relaxed
> > approach for community templates, so the template parser should be
> > resilient against malicious metadata file.
> > `KEY=VALUE` sounds good.
> >
>
> > Here is some attempt:
> > https://github.com/QubesOS/qubes-linux-template-builder/pull/15
> > As you can see in comments there, I don't like some parts, but maybe
> > it will give you some inspiration.
>
> Should something like `vcpus` and `memory` be placed in the file? After all,
> allowing a VM to set its own resource limits would probably create a lot of
> issues.

No, I think only very few properties should be allowed, those really
about what's inside the template. I think this includes:
- virt_mode (but limit possibility of setting "pv", as it's risky
security-wise - maybe some extra confirmation?)
- kernel (not necessary specific version, but some choice like
dom0-provided vs vm-provided)
- kernelopts (not sure if relevant, given option for in-vm kernel)
- custom qrexec_timeout / shutdown_timeout?
- some set of features (qvm-features) - we do have discovery mechanism
for it[1], but some templates (MirageOS) may be too simplistic to
implement it; here[2] is a list of most of them

[1] https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-features.html#qvm-features-request-qubes-postinstall-service
[2] https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/qvm-features.html

> > > (Care may still be needed when a template is renamed though. Would it be more
> > > intuitive for the user if a template is treated as non-RPM-installed once
> > > renamed?)
> >
>
> > That's a tricky question, but I think we can indeed start with
> > this approach. But it may be good to save some information about
> > template origin in the vm features, even if only as a hint for the user.
>
> Probably a minor detail, but is there a way to make cloned VMs behave
> differently than renamed VMs?

That's a very good question. Technically, rename currently is
"clone+remove original", so not really. We could make a GUI tool for
renaming add some info about that.

> > > By the way, should I place this on, say, a Gist so that it's easier to see
> > > the latest revision?
> >
>
> > Yes, that sounds like a good idea. But for discussion it would still be
> > useful to do that via email here.
>
> I re-formated the original text and amended it according to your suggestions.
> The Gist can be accessed
> [here](https://gist.github.com/WillyPillow/b8a643ddbd9235a97bc187e6e44b16e4).
>
> Also, I noticed that in `qvm_template_postprocess.py`
> (<https://github.com/QubesOS/qubes-core-admin-client/blob/e700af9eb2c1b39b065c476b2502a1f6a94d054e/qubesadmin/tools/qvm_template_postprocess.py#L145>),
> it is mentioned that the call to `qvm-appmenus` (which, from what I've gathered,
> only works in dom0) will be switched to qrexec calls in the future. Is there
> currently a qrexec call for this?

It does work in non-dom0 too (if installed). This is what's happening in
GUI domain. But still it operates on local files, so running it outside
of GUI domain (whether it's dom0 or something else), doesn't really
makes sense.
Yes, we'll need to come up with some qrexec calls for that.

BTW, I'd store default appmenus list into qvm-features or similar place
- - to have access to those files outside of dom0 too.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7dCiQACgkQ24/THMrX
1yx+jwf+L7pkt/bH0pXWNa6HmeyRWl0V0Gu/3MjgE2gNZWbj1p5dPJCy4eoooMCe
aI+9yghhM1bHYoJLCo6jU8Bo8Xji9zZIQ/ubj107psnz2w/dVa2q+gWErn4Qrd4H
+DP1zQghzNtQ9smzBPSC83p03Zj22ScVFAIvFwhsi7jL03pegGrzDTlJ5sqaibHQ
BOs8k9BGiU8FRy1LXXlYEi7N4He4SWbrlNdvvHw5dwaveuUlpGUe5gJAG8uLgSfK
1KlsZ88ySx5e5T1qCKuUq33KE4uFmOTZSjBLRkuDMzU/vZVYBkMkZ1WttWg37zbR
x4N01JRspOvEyWa49NUrkJe9Y9syvA==
=M0qF
-----END PGP SIGNATURE-----

[WillyPillow]

Yeah, the security aspect of "pv" was also something that came to mind after
sending the previous email.

>

> - kernel (not necessary specific version, but some choice like
> dom0-provided vs vm-provided)
>

> - kernelopts (not sure if relevant, given option for in-vm kernel)
> - custom qrexec_timeout / shutdown_timeout?
> - some set of features (qvm-features) - we do have discovery mechanism
> for it[1], but some templates (MirageOS) may be too simplistic to
> implement it; here[2] is a list of most of them
>

> [1] https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-features.html#qvm-features-request-qubes-postinstall-service
> [2] https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/qvm-features.html

Having looked through them, the following features seem useful.

- `no-monitor-layout`
- `net.fake-ip`
- `net.fake-gateway`
- `net.fake-netmask`
- Hide info from the template

- `video-model`
- `pci-e820-host`
- `linux-stubdom`
- Compatibility-related?

- - -

Other features:

- `gui`
- `gui-emulated`
- `qrexec`
- These seem to be set in `CoreFeatures`, and the defaults also seem to make
sense for VMs *not* supporting the discovery mechanism.
- `appmenus-legacy`
- Not sure if this is useful, especially when qubes.StartApp seems to be
around for a pretty long time.

> > > > (Care may still be needed when a template is renamed though. Would it be more
> > > > intuitive for the user if a template is treated as non-RPM-installed once
> > > > renamed?)
> >

> > > That's a tricky question, but I think we can indeed start with
> > > this approach. But it may be good to save some information about
> > > template origin in the vm features, even if only as a hint for the user.
> >

> > Probably a minor detail, but is there a way to make cloned VMs behave
> > differently than renamed VMs?
>

> That's a very good question. Technically, rename currently is
> "clone+remove original", so not really. We could make a GUI tool for
> renaming add some info about that.

I see.

> > > > By the way, should I place this on, say, a Gist so that it's easier to see
> > > > the latest revision?
> >

> > > Yes, that sounds like a good idea. But for discussion it would still be
> > > useful to do that via email here.
> >

> > I re-formated the original text and amended it according to your suggestions.
> > The Gist can be accessed

> > here.

> > Also, I noticed that in `qvm_template_postprocess.py`
> > (https://github.com/QubesOS/qubes-core-admin-client/blob/e700af9eb2c1b39b065c476b2502a1f6a94d054e/qubesadmin/tools/qvm_template_postprocess.py#L145),
> > it is mentioned that the call to `qvm-appmenus` (which, from what I've gathered,
> > only works in dom0) will be switched to qrexec calls in the future. Is there
> > currently a qrexec call for this?
>

> It does work in non-dom0 too (if installed). This is what's happening in
> GUI domain. But still it operates on local files, so running it outside
> of GUI domain (whether it's dom0 or something else), doesn't really
> makes sense.
> Yes, we'll need to come up with some qrexec calls for that.
>

> BTW, I'd store default appmenus list into qvm-features or similar place
>

> - to have access to those files outside of dom0 too.

Perhaps this also makes the qrexec call more simple, since the information does
not need to be explicitly passed?

Anyhow, if the package format has been established to a certain extent, maybe I
can start building a PoC that, say, imports a image from an existing RPM?

[Marek Marczykowski-Górecki]

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

On Tue, Jun 09, 2020 at 12:35:48PM +0000, WillyPillow wrote:
> On Sunday, June 7, 2020 11:39 PM, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:
> > [1] https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-features.html#qvm-features-request-qubes-postinstall-service
> > [2] https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/qvm-features.html
>
> Having looked through them, the following features seem useful.
>
> - `no-monitor-layout`
> - `net.fake-ip`
> - `net.fake-gateway`
> - `net.fake-netmask`
> - Hide info from the template
>
> - `video-model`
> - `pci-e820-host`
> - `linux-stubdom`
> - Compatibility-related?

Yes, especially video-model. I don't see any specific situation where
other two would be useful, but they exists specifically for cases I
can't think of ;)

> - - -
>
> Other features:
>
> - `gui`
> - `gui-emulated`
> - `qrexec`
> - These seem to be set in `CoreFeatures`, and the defaults also seem to make
> sense for VMs *not* supporting the discovery mechanism.

Almost. MirageOS-based unikernel VMs do support qrexec (and in some
cases even gui!), but currently do not support discovery mechanism.

> - `appmenus-legacy`
> - Not sure if this is useful, especially when qubes.StartApp seems to be
> around for a pretty long time.

I agree. This exists mostly for compatibility with VMs imported from
Qubes 3.2 (using backup&restore). Definitely not needed for new templates.

> > > > > By the way, should I place this on, say, a Gist so that it's easier to see
> > > > > the latest revision?
> > >
>
> > > > Yes, that sounds like a good idea. But for discussion it would still be
> > > > useful to do that via email here.
> > >
>
> > > I re-formated the original text and amended it according to your suggestions.
> > > The Gist can be accessed
> > > here.
> > > Also, I noticed that in `qvm_template_postprocess.py`
> > > (https://github.com/QubesOS/qubes-core-admin-client/blob/e700af9eb2c1b39b065c476b2502a1f6a94d054e/qubesadmin/tools/qvm_template_postprocess.py#L145),
> > > it is mentioned that the call to `qvm-appmenus` (which, from what I've gathered,
> > > only works in dom0) will be switched to qrexec calls in the future. Is there
> > > currently a qrexec call for this?
> >
>
> > It does work in non-dom0 too (if installed). This is what's happening in
> > GUI domain. But still it operates on local files, so running it outside
> > of GUI domain (whether it's dom0 or something else), doesn't really
> > makes sense.
> > Yes, we'll need to come up with some qrexec calls for that.
> >
>
> > BTW, I'd store default appmenus list into qvm-features or similar place
> > - to have access to those files outside of dom0 too.
>
> Perhaps this also makes the qrexec call more simple, since the information does
> not need to be explicitly passed?

Are you referring to not-yet-existing qrexec calls for handling menu
entires? Yes, that's why I'm proposing qvm-features for this. But you
need to extract it from the rpm package anyway.

> Anyhow, if the package format has been established to a certain extent, maybe I
> can start building a PoC that, say, imports a image from an existing RPM?

Yes :)

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7m4k4ACgkQ24/THMrX
1yyhlggAgRT6sDVfdeQcXj1XK6q6xOMxX4SVELQ7h+rKm3XkfSdnnE3H7UitKOIF
IDpJQ2mgBr5Q5QvEDs8WjMAoDnVBv+iHhd6omSFlfYmEr4pzfJHV5ljWzhamgIIh
2AheECqb/wdrYU5ggzJyXN6uevvPdqfRRHHvDS2PrgEugzbFD6Lt+i11KA4Qkdwi
IGYqIqsho0YiVMhOkLDfGpHrah2CvHbxWZ4WX9tRxTzwJwMq18A0YSrRgJ7jYLzm
uQpz48evOQSvBvsJhdeCte/eDiv+GSg4TV6+3yTsHokWJA27Ui9wq0qJpJuaZQAz
z2CaclNZv4pLOXxRD7WhRr2iE/EYFA==
=BZ1I
-----END PGP SIGNATURE-----