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.

Reply via email to