On Wed, Mar 03, 2021 at 11:58:41AM +0000, 'keyandthegate' via qubes-users wrote: > I've been developing a lot of salt config for myself and I want to start open > sourcing it so that I can: > > - Ask for public security review > - Accept patches > - Help people use Qubes a little better, when I think Qubes supports > anarchistic praxis and is a force of good in the world > > I'm worried about the following things: > > - I lose my security through obscurity, which I don't want to do without the > help of at least one non-amateur code reviewer for anything I publish > > - (and I'm not sure if the economics/incentives work out here such that I > should be paying someone to help me with this or not) > - I don't want to publish anything security sensitive without code review > because I don't want to harm people > > Additionally, I'm not sure how to package salt config via a .deb package. Are > there any existing examples of this? > > As an example of what I want to publish, I've written some config to create a > private debian package repo vm powered by a YAML file that lets you specify > sources to download packages (e.g. that are hosted as github releases) and > verify them via gpg, then provide them to vms. My motivation is towards the > goal of being able to destroy and recreate my templates from salt at any > time, because salt is not stateless (unlike e.g. nix or bazel), e.g. if you > decide to no longer add a package repo, you have to manually remove it from > the domain in addition to updating the salt config, and you may forget; being > able to recreate templates solves the otherwise almost intractable problem of > knowing your templates aren't out of sync; it also means you can exclude > templates from backups if you're brave, which can save a lot of space. > > Another example of some code I may want to publish: > (WARNING: I think this may have a critical security issue of exposing config > files to domains they don't belong to, but I'm not sure. Would need to > investigate before publishing) > This fixes TemplateNotFound errors when you try to jinja-include another file > within a `file.managed` `template.jinja` file. > > > # MAINTAIN: Removed when fixed: > > https://github.com/saltstack/salt/issues/31531 > > 'patch salt issue 31531': > > cmd.run: > > - name: | > > if [[ ! -f "$XDG_DATA_HOME"/patched-salt-31531 ]]; then > > cat <<CMD | xargs -0 -- qvm-run --pass-io template-sys || exit 1 > > sudo sed -i'' "s#if fn_.strip() and fn_.startswith(path):#if fn_.strip() > > and (fn_.startswith(path) or path == '/'):#" > > /usr/lib/python3/dist-packages/salt/fileclient.py && \ > > if ! grep extra-filerefs /etc/qubes-rpc/qubes.SaltLinuxVM >/dev/null; then > > sudo sed -i'' "s#salt-ssh#salt-ssh --extra-filerefs salt:///#" > > /etc/qubes-rpc/qubes.SaltLinuxVM; fi > > CMD > > fi > > sudo mkdir -p "$XDG_DATA_HOME" || exit 1 > > sudo touch "$XDG_DATA_HOME"/patched-salt-31531 || exit 1 >
Great - I love salting Qubes. There *is* a problem in posting configs unless you are careful, but generally this can be mitigated by making them as general as possible. I'd be happy to take a look over what you have: you can get my email and PGP key from the team page at Qubes. Packaging - you need to package in an rpm because it will be handled in dom0 (generally). I generally just package the files, and *not* automatic execution. This is because I want people to review the files, and possibly edit them, before executing in dom0. If you want automatic execution, then it's simply a matter of using a "post install" execution in the rpm. I don't like this, as stated, but it's straightforward. As to publishing, I have some salt on GitHub (https://www.github.com/unman/shaker) Most of the states I publish are simple, in execution if not effect, because they are teaching aids. I have been thinking of publishing packages at https://qubes.3isec.org, alongside the templates and Ubuntu packages that I already offer. This could be done as an unofficial Qubes salt archive, possibly as a step toward inclusion of packages in the official Qubes repositories. If you'd like to take this further, drop me a line. For general issues, reply to the list. unman -- 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/20210304163301.GI17442%40thirdeyesecurity.org.
