Make the download() function save the package into a temporary space and
move to the target location only after checking the signature. This is
safer option than requiring all callers to explicitly verify the
signature. Also, make the download() function verify if the template
name inside the package matches what was requested.
Especially, make `qvm-template download` action verify the signature
too.
On `qvm-template install` avoid checking the signature again for
downloaded packages, by passing extra argument to the verify_rpm()
function. But still verify signature of packages loaded from disk.
Skip initial generate, as it's done before actual menu entries are
extracted from the template. But do call it if we aren't going to
extract menu entries initially - it will create just "settings" menu
entry.
This makes the package verified against _only_ the key specified in the
repo config, not all the trusted keys.
If repo does not specify a key, use the default one (change this to a
single file, instead of the whole directory). Existing 'gpgkey' entry
pointing at non-existing file will result in an error.
Use fcntl.flock() instead of just file existence check, so it won't fail
on a stale lock file. While at it, move locking to a function decorator,
to de-clutter the install function a bit. This will allow reducing
indentation level, but don't do it yet, to make the patch readable.
Move lock testing into a separate test, and remove it from install
tests.
QubesOS/qubes-issues#2534
Avoid risk of conflicting downloads to the same directory, reusing
partial downloads, leaving broken files etc. Move template package out
of temporary directory only after its verified.
QubesOS/qubes-issues#2534
RPM API is confusing and it's easy to get it wrong when verifying
package signatures.
Call 'rpmkeys --checksig' which is more rebust here - RPM authors should
know how to use their API.
QubesOS/qubes-issues#2534
Having Admin API, it is possible to do this properly now:
- create DisposableVM
- assign it proper permissions to create VMs and control those created
VMs
- run restore process inside
- cleanup DisposableVM afterwards
Since the RestoreInDisposableVM class contains de facto reverse parser
for qvm-backup-restore command line, add a test that will spot when it
gets out of sync.
This feature depends on modifications in various other components,
including:
- linux-utils and core-agent-linux for update qfile-unpacker
- core-admin for qrexec policy modification
QubesOS/qubes-issues#5310
Allow setting alternative qrexec service to retrieve backup content. The
service API is slightly different than the default one: it will get only
list of files/directories to extract on its stdin, but not backup
location. The latter could be provided as a service argument, or using
other out-of-band mechanism.
This will be useful for paranoid backup restore mode, to take away
control over location/command from sandboxed qvm-backup-restore process.
QubesOS/qubes-issues#5310
Allow configuring options per VM or globally per GuiVM. The
qvm-start-daemon program reads the options from VM features, and
generates a configuration file for qubes-guid.
Requires QubesOS/qubes-gui-daemon#47 (customizing the configuration
file).
Both tools issue a large number of Admin API calls and greatly benefit
from a cache filled with a single per-vm Admin API call
(admin.vm.property.GetAll). In case of qvm-ls, this also saves multiple
admin.vm.CurrentState calls (power state is given in the admin.vm.List
response too).
QubesOS/qubes-issues#3293
* origin/pr/118:
qvm-start-daemon: adjust pacat pid file path
qvm-start-daemon: check if layout is parsed
qvm-start-daemon: allow multiple options in keyboard layout
qvm-start-daemon: improve parsing args for setting keyboard layout
qvm-start-daemon: set keyboard-layout only for the first set layout
gui: set keyboard layout when starting daemon
daemon: start it for dom0 unconditionnaly
qvm-start-daemon: ensure separate task between GUI/AUDIO
qvm-start-daemon: allow starting only if service enabled
Fix and improvements from Marek's comments
Change qvm-start-gui to qvm-start-daemon for handling audio too
Support for AudioVM
Rules will be reset to a single 'accept' line, which is something
that the GUI tools like. It's an easy way to get out of CLI firewall
modifications if someone wants to go back to using GUI for them.
fixesQubesOS/qubes-issues#4710
