qvm-template fails silently with repo_gpgcheck=1

[3hhh]

How to file a helpful issue

Qubes OS release

4.1

Brief summary

Enforcing signed metadata for the template repo causes `qvm-template' to not find any templates anymore.

Steps to reproduce

1. Set repo_gpgcheck=1 in /etc/qubes/repo-templates/qubes-templates.repo.
2. Run qvm-template list --available.

Expected behavior

Error on the signature check failing or ideally list of templates available to install.

Actual behavior

Error: "No templates available".

[DemiMarie]

Thanks for the report. This is certainly wrong.

I believe what is happening is that the check for signed repository metadata in dom0 fails. This is expected behavior, since dom0 metadata is generated within dom0 and so cannot be signed. That said, the error message is unacceptably poor. Will fix.

[marmarek]

I believe what is happening is that the check for signed repository metadata in dom0 fails.

I don't think so. qvm-template does nothing related to repository metadata in dom0 - at dom0 side dnf is not involved at all.

@3hhh what template your updatevm uses? Is it maybe some older Debian?

[3hhh]

@3hhh what template your updatevm uses? Is it maybe some older Debian?

I use a debian-11 template. It works for `qubes-dom0-update` though (incl. repo_gpgcheck=1).

[Nurmagoz]

I can confirm this (using fedora-34 for updateVM)

[user@dom0 ~]$ sudo nano /etc/qubes/repo-templates/qubes-templates.repo 
[user@dom0 ~]$ sudo qubes-dom0-update --show-output --console
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
warning: Converting database from bdb_ro to sqlite backend
Fedora 32 - x86_64                               13 kB/s | 6.0 kB     00:00    
Fedora 32 - x86_64 - Updates                    7.7 kB/s | 5.9 kB     00:00    
Qubes Dom0 Repository (updates)                 6.9 kB/s | 2.7 kB     00:00    
Qubes Dom0 Repository (security-testing)        6.9 kB/s | 2.9 kB     00:00    
Dependencies resolved.
Nothing to do.
Complete!
No packages downloaded
Qubes OS Repository for Dom0                                                         2.9 MB/s | 3.0 kB     00:00    
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-34
Redirecting to 'qvm-template install  fedora-34'
usage: qvm-template [--verbose] [--quiet] [--help] [--repo-files REPO_FILES] [--keyring KEYRING]
                    [--updatevm UPDATEVM] [--enablerepo REPOID] [--disablerepo REPOID] [--repoid REPOS]
                    [--releasever RELEASEVER] [--refresh] [--cachedir CACHEDIR] [--keep-cache] [--yes]
                    {install,reinstall,downgrade,upgrade,download,list,info,search,remove,purge,clean,repolist} ...
qvm-template: error: Template 'fedora-34' not found.
[user@dom0 ~]$ sudo nano /etc/qubes/repo-templates/qubes-templates.repo 
[user@dom0 ~]$ sudo qubes-dom0-update --show-output --console
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
warning: Converting database from bdb_ro to sqlite backend
Fedora 32 - x86_64                               14 kB/s | 6.0 kB     00:00    
Fedora 32 - x86_64 - Updates                    7.8 kB/s | 5.9 kB     00:00    
Qubes Dom0 Repository (updates)                 7.0 kB/s | 2.7 kB     00:00    
Qubes Dom0 Repository (security-testing)        6.8 kB/s | 2.9 kB     00:00    
Dependencies resolved.
Nothing to do.
Complete!
No packages downloaded
Qubes OS Repository for Dom0                                                         2.9 MB/s | 3.0 kB     00:00    
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-34
Redirecting to 'qvm-template install  fedora-34'
Template 'fedora-34' already installed, skipping... (You may want to use the {reinstall,upgrade,downgrade} operations.)
[user@dom0 ~]$ 

Different is:

With

[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-34
Redirecting to 'qvm-template install  fedora-34'
usage: qvm-template [--verbose] [--quiet] [--help] [--repo-files REPO_FILES] [--keyring KEYRING]
                    [--updatevm UPDATEVM] [--enablerepo REPOID] [--disablerepo REPOID] [--repoid REPOS]
                    [--releasever RELEASEVER] [--refresh] [--cachedir CACHEDIR] [--keep-cache] [--yes]
                    {install,reinstall,downgrade,upgrade,download,list,info,search,remove,purge,clean,repolist} ...
qvm-template: error: Template 'fedora-34' not found.

Without

[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-34
Redirecting to 'qvm-template install  fedora-34'
Template 'fedora-34' already installed, skipping... (You may want to use the {reinstall,upgrade,downgrade} operations.)

[marmarek]

Is it still the case? We don't have repo_gpgcheck in template repositories, so the problem doesn't apply by default. If it can be made working, great. Otherwise, maybe we should add a clear failure like "repo_gpgcheck=1 is not supported for template repositories" (if such setting is detected).

[DemiMarie]

@marmarek what would it take to sign the template metadata?

[marmarek]

@marmarek what would it take to sign the template metadata?

The metadata is signed. The issue is IIUC about its verification in the updatevm, if you opt in for it.

[3hhh]

Is it still the case?

Yes.

We don't have repo_gpgcheck in template repositories, so the problem doesn't apply by default. If it can be made working, great. Otherwise, maybe we should add a clear failure like "repo_gpgcheck=1 is not supported for template repositories" (if such setting is detected).

I think I had looked into this setting as part of QSB 67, which it might have prevented.

It's also weird that qubes-dom0-update works with that setting, but qvm-template doesn't. IMO that's a regression from times where qubes-dom0-update was also used to install templates.

[DemiMarie]

Culprit is a missing package dependency: the needed to verify the metadata are provided by the qubes-repo-templates package, but qubes-core-agent-dom0-updates doesn’t depend on that package, so neither whonix-workstation-17 nor debian-12 has it installed. The qubes-repo-templates package is tiny (less than 20KiB) so having qubes-core-agent-dom0-updates depend on it is the simplest fix.

[marmarek]

Isn't that layering violation? qvm-template tool sends repository definitions to the updatevm, so having it also requiring repo definitions being installed in updatevm sounds weird. I guess the missing part are keys, right? Can they be inlined into repo definition file?

[DemiMarie]

I don’t think so @marmarek.

[marmarek]

Can we then invent some (like, put the key in a specially marked comment, that updatevm-side script will extract)?
Installing them in a VM is not a big deal for official repos, but it's going to be problematic when using 3rd-party repos.

[DemiMarie]

Can we then invent some (like, put the key in a specially marked comment, that updatevm-side script will extract)? Installing them in a VM is not a big deal for official repos, but it's going to be problematic when using 3rd-party repos.

Let’s get the official repos fixed first. That’s a much simpler fix and so less likely to cause any regressions. A general fix will be more complex, so it will take longer and be more likely to cause regressions.

[Nurmagoz]

Let’s get the official repos fixed first. That’s a much simpler fix and so less likely to cause any regressions. A general fix will be more complex, so it will take longer and be more likely to cause regressions.

Fixed or not yet?

[DemiMarie]

Currently only fixed for the official repos.