On Monday, August 10, 2020 6:30 PM, Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> wrote:
> On Sun, Aug 09, 2020 at 12:37:36PM +0000, WillyPillow wrote: > > For the past few days, I've been mostly improving the previous qvm-template > > operations and adding small features like `repolist` and machine-readable > > listings. The design doc [^1] has also been updated to reflect these > > changes. > > > > Right now, the remaining major features that needs to be implemented seem to > > be the following: > > > > - `qvm-template purge` (i.e., remove or modify AppVMs linked to the > > template to > > be removed) > > - (Currently this is what I'm mainly looking into.) > > - Is it better to store the source mgmtVM as a property or a feature? > > Where exactly do you need that information? To maintain mgmtVM access to > VMs based on that template? This sounds risky, I'd say such permissions > should be granted explicitly. In practice, I think this will be a rare > problem. Risk-wise, perhaps we can have an AdminAPI call that is only able to unlink a VM from its template (i.e., change the property to a placeholder)? (Rarity-wise, see below.) > > - To mark the source mgmtVM, I'd need to obtain the VM that > > installed/created > > the template. Is storing this information when `admin.vm.Create` is > > called > > a good idea? (To my knowledge, there doesn't seem to be a way of > > obtaining > > the VM name from within the VM itself.) > > This is already stored as a 'created-by-...' tag. Not very effective to > get the actual value (you need to enumerate tags), but core-admin > ensures that no one is able to spoof this value. > > > - I'm unsure if it's possible to handle with the current set of events the > > cases where > > > > 1. A template VM is created by VM A > > 2. An AppVM is created based on the template > > 3. VM B overrides the template > > > > Or is it sufficient to keep the source set to VM A? > > What do you mean "overrides the template"? Overrides its root (and > private) volume, or changes an AppVM's template property? > In the former case, I'd say yes - keep the source set to VM A. Yes, this is indeed what I meant :) > > - Something like [^2] is probably needed to create the static policies. > > If desirable, then probably yes. But as said earlier, IMO a case where > you want both a) manage all AppVMs based on a template (change their > 'template' property or possibly remove them) from some MgmtVM and b) > that MgmtVM doesn't have permission to those AppVMs otherwise is rare. This seems to make a lot of sense. (Unfortunately, I don't seem to be able to recall the exact motivation for proposing this in previous discussions.) One (perhaps) plausible scenario I can think of right now is someone using a separate MgmtVM to sandbox the handling of somewhat untrusted templates [^4], while creating VMs based on that from a GuiVM. [^4]: I would assume that most of the complexity of RPMs is in the header, which we need to parse anyway for signature verification; hence merely offloading the image extraction to DispVMs might not be able to replace this. > > - GUI > > - A layout similar to Synaptic's [^3] should work. > > Generally sounds good. I think in our case (low number of templates) the > filters on the left don't make much sense. And also, to be consistent > with our GUI tools, the toolbar on the top should use smaller icons. > Logically, it should be part of qubes-manager repository, where other > similar tools live already. > I'm copying Marta, who is in charge of our GUI tools. I see. Speaking of icons, is there a preferred source for icons, in case the ones in qubes-manager are not enough? (Or can I simply fetch them dynamically from the GTK theme?) > > - Tests/documentation > > - Manpage > > - Should I clean up the design doc and put a description of the > > architecture > > in qubes-doc? > > Yes, this sounds like a very good idea. Then we'll link to it from a > news about finished GSoC project :) > > > - I also need to document `admin.vm.volume.Clear` at > > <https://www.qubes-os.org/doc/admin-api/>. > > Yes. (just approved the PR) > > > - Key Management > > - What are your thoughts on the idea of signing the templates with a > > different key (credits to woju :) )? > > That sounds like a good idea indeed. But I think it's quite independent > of qvm-template work - the repository definition includes signing key > anyway and it doesn't make much difference if that's the same as for > dom0 packages or different. > In fact, for community templates we already use different key. I see. > > - I'm thinking that perhaps it's better to install the templates keys > > separate from the system repo keys, as it's plausible that the former > > are > > less trusted than the latter. > > Yes. Perhaps a good place for such package is meta-packages repo? > (separate sub-package) Realized that my wording was pretty bad. By "install separately" I meant to a location different from `/etc/pki/rpm-gpg/`. (Otherwise, currently the keys are placed with the repo config in qubes-repo-templates, already separate from the other keys.) Anyway, I'll look into how to do this. The Python API for RPM does seem to expose an option to set the keyring for verification. > > Is there anything else I'm missing? Also, are there a preferred priorities > > for > > these tasks? > > First focus on finishing those two things about qvm-template tool and then > mark the PRs as ready to merge (remove "WIP" tag). I think some of them > are already in this state, just adjust the title. Understood. 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 -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/PaMKiSxO19jx2p4CpLO8K14PX4NQapr8FQlUMlPvHQEZFQugIfDaFJFDrrtsVRMNmmA3PUU-rvGbEpvkRCqvWCPJrVCggw3uqBWgkyR7MV4%3D%40nerde.pw.
publickey - wp@nerde.pw - 0xD02DCEFF.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
