Open sourcing my salt configs

[keyandthegate]

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

[unman]

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