Hi qubes-users, I have a bunch of VMs based on one Fedora TemplateVM. In most cases, I'm willing to install any Fedora package needed by any of the VMs in the TemplateVM. However, due to security concerns, I have one VM that runs Zoom, one that runs Skype, one that runs Google Chrome, and one that runs Visual Studio Code... you get the idea. Each of those applications offers its own dnf repository, but I don't want to add those repositories to the TemplateVM. And I don't want to use StandaloneVMs because that will multiply my management work; even if there are management tools that could handle most of my needs, I'd still have to learn and configure them.
So far, I've been manually downloading the RPMs and extracting them into the user home directory. (Fortunately, none of them have had dependencies on absolute paths that would break this approach.) This is enough of a pain that I rarely update the applications, which may be bad for security. Does anyone know of a better but still convenient solution? I was considering writing a tool to automatically update specified packages in a TemplateBasedVM every time it boots. There are various ways this could be implemented. My latest idea is to actually add the repository files to /etc/yum.repos.d in the volatile layer of the root filesystem and do a normal "dnf install" but find a way to cache the RPMs under /rw to avoid re-downloading them when they haven't changed. Compared to installing under /rw in some fashion, this approach does extra installation work on every boot but produces a true systemwide installation, avoiding any problems with absolute paths and the like (though granted, I haven't experienced any such problems under my current approach with the particular applications I use). Proposed detailed design (untested): The TemplateBasedVM keeps a directory of repository files, a list of package names to install, and a cache directory of RPMs. On boot: 1. "dnf clean packages" 2. "createrepo" on the VM's cache directory. 3. Copy the repository files to /etc/yum.repos.d and generate one for the VM's cache directory too. 4. "dnf --setopt=keepcache=1 install" the requested package names. This may pull in additional dependencies, and all packages that were installed will be left in the system dnf cache, including any from repositories that were already in the TemplateVM. (I don't have any packages of the latter type, but other users with scenarios different than mine might. For that matter, other users could use the tool purely to install extra packages from repositories already in the TemplateVM (so the directory of repository files to add would be empty) and/or for reasons unrelated to security.) 5. Sync the packages from the system dnf cache to the VM's cache directory, deleting any obsolete packages from the VM's cache directory. 6. "dnf clean packages" again. I would welcome feedback of any kind. After working out the design, I realized that though I've suffered from the problem for years, it happens that starting tomorrow I will rarely have a need to use any of the proprietary applications, so actually developing the tool may fall down my priority list unless others express significant interest. As an aside, I'm aware that some people in this community might be inclined to tell me off for adopting an approach to security that they believe is poor in some way. I haven't researched whether this is actually a common problem; if it isn't, please do not take my statement as an insult to the community. FWIW, I think it's great that the Qubes OS technology allows users to achieve a range of security levels higher than that of mainstream OS distributions depending on how much trouble users are willing to go to, and I'd like to see the community accommodate all of them. So I'll ignore any derision but consider any reasonable suggestions to improve my own security or make my tools suitable for users who want higher security. Thanks for your attention! Matt -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/144929a2d3398657afbce8bbc10224a91e0dc07a.camel%40mattmccutchen.net.
