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
Allow running unattended, with qvm-backup-restore --passphrase-file.
This require few modifications:
- copy the passphrase file into the DisposableVM (that VM knows the
passphrase anyway, so there is no extra data leak)
- close the terminal when operation finishes
Closing the terminal would eliminate almost all the feedback (operation
log, errors, warnings etc), so write it into a file in DisposableVM and
later extract it and show on the stdout. Similar to qvm-run, color it
red as a content coming from a VM.
QubesOS/qubes-issues#5310
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
