On Wed, Mar 03, 2021 at 11:58:41AM +, '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 < > 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.
