qusal/CONTRIBUTING.md

Contributing

Table of Contents

• Respect
• Environment
  • Requirements
  • RPM Spec
  • Lint
• Format
  • File naming
  • State ID
  • Readme
  • Qube preferences
    • Qube naming
    • Qube label
  • Qrexec
• Where to start

Respect

Be respectful towards peers.

Environment

You will need to setup you development environment before you start contributing. You will need Qubes OS R4 or higher.

Requirements

The following are the packages you need to install:

General:

• git

For writing:

• editorconfig
• editorconfig plugin for your editor
• vim, vim-jinja, vim-salt (recommended)

For linting:

• pre-commit
• gitlint
• salt-lint
• shellcheck
• reuse

For building RPMs:

• sed (GNU sed)
• dnf
• dnf-plugins-core (dnf builddep)
• rpm
• rpmlint
• rpmautospec (only available in Fedora)

RPM Spec

Reference material:

• docs.fedoraproject.org/en-US/packaging-guidelines/
• rpm-software-management.github.io
• rpm-packaging-guide.github.io
• rpm-guide.readthedocs.io
• ftp.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html

Lint

Lint before you commit, please... else you will have to fix after the PR has already been sent.

Install the local hooks:

pre-commit install
gitlint install-hook

To run pre-commit linters:

pre-commit run

Format

File naming

1. Every State file .sls must have a Top file .top. This ensures that every state can be applied with top.
2. Every project must have a init.top, it facilitates applying every state by enabling a single top file.
3. State file naming must be common between the projects, it helps understand the project as if it was any other.
4. File name must use - as separator, not _.

State ID

1. State IDs must use - as separator, not _. The underline is allowed in case the features it is changing has underline, such as default_netvm.
2. State IDs must always have the project ID, thus allowing to target multiple states to the same minion from different projects without having conflicting IDs.

Readme

1. Every project should have a README.md with at least the following sections: Table of Contents, Description, Installation, Access Control (if changed Qrexec policy), Usage.

Qube preferences

Qube naming

We differ from upstream especially by placing the dvm part as the prefix of DispVM Templates. This is to easy parsing when the qube type is the first part of its name and no exceptions.

• TemplateVM: tpl-NAME
• StandaloneVM: NAME
• AppVM: NAME
• DispVM: disp-NAME
• DispVM Template (AppVM): dvm-NAME
• Service qubes (not a class): sys-NAME

We recommend that for user created qubes, use the domain in the prefix of the qube. An AppVM for personal banking will be named personal-banking, an AppVM for personal e-mail will be named personal-email.

Qube label

We differ from upstream in many senses. We are not labeling qubes based on them sharing a common security domain, this is very limited if you have many security domains in use and they do not share the same level of trust. You don't (or shouldn't) trust your networked browsing qube for personal usage the same as you trust your vault. The following method tries to fix this problem, domain name is in the prefix of the qube, the label is solely related to trustworthiness of the data it is dealing with.

• Black:
  • Trust: Ultimate.
  • Description: You must trust Dom0, Templates, Vaults, Management qubes, these qubes control your system and hold valuable information.
  • Examples: dom0, tpl-ssh, vault, dvm-mgmt.
• Gray:
  • Trust: Fully.
  • Description: Trusted storage with extra RPC services that allow certain operations to be made by the client and executed on the server or may build components for other qubes.
  • Examples: sys-cacher, sys-git, sys-pgp, sys-ssh-agent, qubes-builder.
• Purple:
  • Trust: Very much.
  • Description: Has the ability to manager remote servers via encrypted connections and depend on authorization provided by another qube. Examples: ansible, dev, ssh, terraform.
• Blue:
  • Trust: Much.
  • Description: TODO
  • Examples: TODO
• Green:
  • Trust: Trusted.
  • Description: TODO
  • Examples: TODO
• Yellow:
  • Trust: Relatively trusted.
  • Description: TODO
  • Examples: TODO
• Orange:
  • Trust: Slight.
  • Description: Controls the network flow of data to the client, normally a firewall.
  • Examples: sys-firewall, sys-vpn, sys-pihole.
• Red:
  • Trust: Untrusted.
  • Description: Holds untrusted data (PCI devices, untrusted programs, disposables for opening untrusted files or web pages).
  • Examples: sys-net, sys-usb, dvm-browser.

Qrexec

1. Don't use * for source and destination, use @anyvm instead
2. Target qube for policies must be @default. It allows for the real target to be set by Dom0 via the target= redirection parameter, instead of having to modify the client to target a different server via qrexec-client-vm.
3. Target qube for client script must default to @default, but other targets must be allowed via parameters.

Where to start

See open issues and search for the word TODO in the repository files.