# packages

pkgId: 46573a0e318468c6f990c02bce51aea596c63a5892f512bbadfbc42bfa396930
name: 3isec-qubes-cacher
arch: x86_64
version: 1.10
epoch: 0
release: 1.fc32
summary: A caching proxy in Qubes
rpm_license: GPLv3+
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: 3isec-qubes-cacher-1.10-1.fc32.src.rpm
location_href: 3isec-qubes-cacher-1.10-1.fc32.x86_64.rpm
checksum_type: sha256
description:
  This package provides a caching proxy, named cacher.
  A caching proxy stores downloaded packages, so that you need only download
  a package once for it to be used when updating many templates.
  The proxy is preconfigured to work out of the box for Debian, Ubuntu,
  Arch, and Fedora templates.

  When you install this package your Qubes system will be altered to use
  the proxy by default.
  This is done with an entry in /etc/qubes/policy.d/30-user.policy
  If you want to change the proxy setting for some/all templates, edit
  that file.

  So that you can use https:// in your repository definitions, the entries
  will be changed in the templates.
   https:// becomes http://HTTPS///
  This is so that the request to the proxy is plain text, and the proxy
  will then make the request via https
  This change will be done automatically for every template that exists
  when you install this package.

  If you install a new template, you must make this configuration change.
  In dom0 run:
   qubesctl --skip-dom0 --targets=TEMPLATE state.apply cacher.change_templates
  replacing TEMPLATE with the name of the new template.

  If you want to use the standard proxy, you have to revert this change,
  as well as editing the policy file.
  In dom0 run:
   qubesctl --skip-dom0 --targets=TEMPLATE state.apply cacher.restore_templates
  replacing TEMPLATE with the name of the new template.

  When this package is installed it will attempt to rewrite repository
  definitions in all templates.
  This includes templates that are not under salt control, like Windows
  templates.
  You must manually shutdown those templates.

  No changes are made to Whonix templates, and updates to those templates
  will not be cached.

  If you want updates to run via Tor, set the netvm for the cacher qube
  to be a Tor proxy, like sys-whonix.

  Because the cacher qube is listening on port 8082, you can use it from
  non-template qubes and qubes that do not have a working qrexec. Use
  the native configuration to set the update proxy using the IP address
  of cacher.

  A pillar is created to hold the caching qube.
  This can be referenced from other salt states as needed.


pkgId: cda7ae8ad400fb4580da57f439eba751495ecb112dc706241b1474d8223d224f
name: 3isec-qubes-git
arch: x86_64
version: 0.2
epoch: 0
release: 1.fc32
summary: Create sys-git in Qubes
rpm_license: GPLv3+
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: 3isec-qubes-git-0.2-1.fc32.src.rpm
location_href: 3isec-qubes-git-0.2-1.fc32.x86_64.rpm
checksum_type: sha256
description:
  This package provides a central git qube, named sys-git.
  By default the qube has no netvm, but you can set one if you wish.

  Some configuration is needed.
  Repositories must be created under /home/user/repos in sys-git, and
  repository names must be common between sys-git and client qubes.




  In sys-git, repositories are stored bare under /home/user/repos
  First, prepare a repository:
  ```
  mkdir repos/X
  cd repos/X
  git init --bare
  ```


  Then prepare a qube by running in dom0:
  `sudo qubesctl --skip0-dom0 --targets=QUBE state.apply git.install_client`


  Configure git, as necessary.
  Open a terminal in the qube:
  ```
  mkdir X
  cd X
  git init
  add-remote sg
  ```
  You can then use that repository as usual, making commits.
  To push to sys-git you must first:
  `git push --set-upstream sg master`

  After making more commits:
  `git push `




  Prepare a qube by running:
  `sudo qubesctl --skip0-dom0 --targets=QUBE state.apply git.install_client`


  Configure git, as necessary.
  Open a terminal in the qube:
  ```
  mkdir X
  cd X
  git init
  add-remote sg
  git pull sg master
  ```


  You can then use that repository as usual.
  To push to sys-git you must first-
  `git push --set-upstream sg master`

  After making more commits,
  `git push `



  Access to sys-git is governed by policy rules in `/etc/qubes/policy/30-user.policy`
  The default rule allows access from any qube to sys-git, after a confirmation dialog.
  `qubes.Git  *  @anyvm  @anyvm ask default_target=sys-git`

  You can control access to sys-git by qube, and restrict qubes to specific named repositories:
  ```
  qubes.Git  +REPO  QUBE   @anyvm  ask default_target=sys-git
  qubes.Git  *      QUBE2  @anyvm  ask default_target=sys-git
  qubes.Git  *      *     sys-git deny
  ```
  These rules will allow QUBE to access the REPO repository on sys-git, but no other.
  QUBE2 is allowed to access any repository on sys-git.
  No other qube is allowed access at all.


pkgId: a6c492a91ad4479553f559765fc43bfbdecf76606a04d7e316e12e65ae8820c8
name: 3isec-qubes-mirage-firewall
arch: x86_64
version: 0.8.4
epoch: 0
release: 1.fc32
summary: Create an Mirage firewall in Qubes
rpm_license: GPLv3+
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: 3isec-qubes-mirage-firewall-0.8.4-1.fc32.src.rpm
location_href: 3isec-qubes-mirage-firewall-0.8.4-1.fc32.x86_64.rpm
checksum_type: sha256
description:
  This package creates a mirage firewall for use in Qubes.
  It's a Unikernel qube to replace sys-firewall, which uses minimal system resources.
  For full details:
  https://github.com/mirage/qubes-mirage-firewall

  The package creates a qube called mirage-firewall.
  If you want to use this as a firewall, simply change net qube from sys-firewall to mirage-firewall.
  There's a batch file in /srv/salt/mirage to make this change in bulk.

  Removing this package will remove the mirage-firewall.
  Qubes that use it will have their net qube unset.
  You will have to change netqube to get those qubes back online.
  There's a batch file in /srv/salt/mirage to help make this change in bulk.


pkgId: fc7e696affbe3430d5c8699712d8e9aaf6dc0169da6eee94983ce293574b3343
name: 3isec-qubes-mullvad-vpn
arch: x86_64
version: 1.2
epoch: 0
release: 1.fc32
summary: Set up a Mullvad wireguard proxy in Qubes
rpm_license: GPLv3+
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: 3isec-qubes-mullvad-vpn-1.2-1.fc32.src.rpm
location_href: 3isec-qubes-mullvad-vpn-1.2-1.fc32.x86_64.rpm
checksum_type: sha256
description:
  This package sets up a VPN gateway, named MullvadVPN
  It follows the method detailed in the Mullvad docs,
  https://mullvad.net/en/help/qubes-os-4-and-mullvad-vpn/

  This package is for use with wireguard.
  If you use openvpn, install the 3isec-qubes-openvpn package.

  The package creates a qube called MullvadVPN based on the debian-11-minimal
  template.  If the debian-11-minimal template is not present, it will
  be downloaded and installed - this may take some time depending on your
  net connection.

  There are changes to the firewall rules on MullvadVPN to ensure
  blocking of outbound connections.
  Only traffic to the Mullvad gateway is allowed.

  After installing the package, copy your Mullvad configuration file or
  zip file to MullvadVPN.
  A menu item for "Setup Mullvad VPN" will be created on the main Qubes Menu.
  Run this to set up the VPN.
  When finished, restart MullvadVPN.

  To use the VPN, set MullvadVPN as the netvm for your qubes(s).
  All traffic will go through the VPN.
  The VPN will fail closed if the connection drops.
  No traffic will go through clear.

  If you remove the package, the salt files will be removed.
  **The MullvadVPN gateway will also be removed.**
  To do this ALL qubes will be checked to see if they use MullvadVPN.
  If they do, their netvm will be set to `none`.

  You can, of course, use template-mullvad to create other VPN gateways.


pkgId: 46f70424b51c3bf320bac1e0eb291540174fe050fc8d0c7eae8c1e0047254b52
name: 3isec-qubes-pihole
arch: x86_64
version: 1.3
epoch: 0
release: 1.fc32
summary: Creates Pi-hole server for Qubes
rpm_license: GPLv3+
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: 3isec-qubes-pihole-1.3-1.fc32.src.rpm
location_href: 3isec-qubes-pihole-1.3-1.fc32.x86_64.rpm
checksum_type: sha256
description:
  This is Pi-hole.
  It blocks advertisements and internet trackers by providing a DNS sinkhole.

  The package will create a new standalone qube, sys-pihole.
  It is a drop in replacement for sys-firewall.
  Sys-pihole is attached to sys-net.
  If you have sys-firewall as the default netvm, this will be changed to sys-pihole.
  The installation will try to move all qubes with netvm of sys-firewall to sys-iphole.
  sys-firewall will *not* be removed, so you can still use it for some qubes if you want.

   If you want to use Tor, then you should reconfigure your system like this:
   qubes -> sys-pihole ->Tor-gateway -> sys-firewall -> sys-net

  You can clone sys-pihole.
  If you do you must manually change the IP address of the clone.

  Pi-hole will be installed with these default settings:
   The DNS provider is Quad9 (filtered, DNSSEC)
   StevenBlack's Unified Hosts List is included
   The web interface is availble at http://localhost
   Query logging is enabled to show everything.

  You can change these settings by logging in to the admin interface at http://localhost.
  The default Admin Webpage login password is UpSNQsy4
  You should change this on first use, by running:
  `pihole -a -p`

  Removing this package will only remove the salt files from /srv/salt.
  It will NOT remove the sys-pihole qube.
  It will NOT change Qubes networking.
  You will have to make any changes as you wish.


pkgId: 21b3c68449f5543b357b800b2218a0e5e6ef510944132c8fe4fcd1c52134a74b
name: 3isec-qubes-reader
arch: x86_64
version: 1.0
epoch: 0
release: 1.fc32
summary: Prepares useful software in Qubes
rpm_license: GPLv3+
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: 3isec-qubes-reader-1.0-1.fc32.src.rpm
location_href: 3isec-qubes-reader-1.0-1.fc32.x86_64.rpm
checksum_type: sha256
description:
  This package creates a minimal template configured with a range of useful software, of particular use to terminal users.
  The template is set as the default template and as template for the Debian disposable template.

  Removing this package does NOT revert these changes.
  It only removes the salt files.
  You must manually create another template and set it as the default using qubes-global-settings, and qubes-template-manager


pkgId: d6477875cf70a328d88e99a88b8d3e048e0c7fe06d472eb03ae3e8214d05d813
name: 3isec-qubes-split-gpg
arch: x86_64
version: 2.05
epoch: 0
release: 1.fc32
summary: split-gpg in Qubes
rpm_license: GPLv3+
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: 3isec-qubes-split-gpg-2.05-1.fc32.src.rpm
location_href: 3isec-qubes-split-gpg-2.05-1.fc32.x86_64.rpm
checksum_type: sha256
description:
   This package set up split-gpg in Qubes.
   split-gpg allows you to store your pgp keys in one qube, and access them from another.
   Full details are at https://www.qubes-os.org/doc/split-gpg/

  When you install this package a template will be created, and a qube
  named sys-gpg to hold the keys.
  You can create more than one qube to hold keys if you want.
  The system will be configured to use the sys-gpg qube by default.
  This is done with an entry in /etc/qubes/policy.d/30-user.policy
  If you want to change the setting for some/all qubes, edit
  that file.


pkgId: 5fdb1495bee45c94cace9b53108e8d1e49c0a05e1680462e2400e8741f925ed1
name: 3isec-qubes-split-monero
arch: x86_64
version: 0.2
epoch: 0
release: 1.fc32
summary: Create a split monero wallet in Qubes
rpm_license: GPLv3+
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: 3isec-qubes-split-monero-0.2-1.fc32.src.rpm
location_href: 3isec-qubes-split-monero-0.2-1.fc32.x86_64.rpm
checksum_type: sha256
description:
  This package creates an offline Monero wallet, which connects to a
  Monero daemon over qrexec. All traffic from the daemon is forced to run
  over Tor.
  It follows the method detailed in the Monero docs:
   https://www.getmonero.org/resources/user-guides/cli_wallet_daemon_isolation_qubes_whonix.html

  The package creates a qube called monero-wallet-ws to hold the wallet,
  and monerod-ws for the monerod daemon. The netvm for this qube is set
  to sys-whonix, so traffic should pass over Tor. (monero-wallet-ws has no netvm.)

  Traffic between the daemon and the wallet runs over qrexec, controlled
  by an entry in the policy file at /etc/qubes/policy/30-user.policy

  You can create multiple wallets by cloning the wallet, and adding policy entries.
  You can also clone the daemon and connect them to different Tor gateways.

  If you remove the package, the salt files will be removed.
  The Wallet qube will NOT be removed.


pkgId: 09caa52d5b596af036404d213914c7f3929618df5d748712ffdf25561af8f87c
name: 3isec-qubes-syncthing
arch: x86_64
version: 1.1
epoch: 0
release: 1.fc32
summary: Syncthing in Qubes
rpm_license: GPLv3+
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: 3isec-qubes-syncthing-1.1-1.fc32.src.rpm
location_href: 3isec-qubes-syncthing-1.1-1.fc32.x86_64.rpm
checksum_type: sha256
description:
  Creates a syncthing template and active syncthing qube.
  By default the syncthing qube will be attached to sys-firewall, or sys-pihole if that qube exists.
  It makes no sense to run this with syncthing attached to a VPN or Tor proxy.
  This package opens up the qubes-firewall, so that the syncthing qube is accessible externally.
  If sys-net has more than one network card the FIRST external interface will be used by default.
  (If this is incorrect, you must change it manually. In dom0:
    /srv/salt/syncthing/in.sh delete syncthing tcp 22000 -a -p
    /srv/salt/syncthing/in.sh delete syncthing udp 22000 -a -p
    /srv/salt/syncthing/in.sh add syncthing tcp 22000 -p
    /srv/salt/syncthing/in.sh add syncthing udp 22000 -p
  This will let you choose the NIC.)

  A qubes.Syncthing service is created, to allow use of syncthing over qrexec.
  A default policy is set in /etc/qubes/policy.d/30-user.policy to deny all.
  If you want to allow syncthing between qubes, insert a line at the top of the policy file to allow. E.g:
    qubes.Syncthing  *  FROM  TO  allow


  The package can be uninstalled using:
    sudo dnf remove 3isec-qubes-syncthing
  The syncthing qube will NOT be removed, but the Syncthing service on that qube will be stopped.
  The firewall rules will be reverted so the qube will not be accessible externally.
  N.B. If you have manually set rules you must manually revert them.
  The qrexec policy will be reverted to stop Syncthing between qubes.

  The package includes qubes-rsyncthing.service.
  This enables use of syncthing between qubes over qrexec - the service must be enabled to be used:
    qubes-features QUBE service.qubes-syncthing 1
  By default the service will connect to the syncthing qube.
  To use the service, add a Remote Device, and copy the DeviceID from the target qube.
  On the Advanced tab, under Addresses, change "dynamic" to "tcp://127.0.0.1:22001"

  If the sender qube has no netvm set, under "Settings", disable "Enable NAT traversal", "Local Discovery",
  "Global Discovery", and "Enable Relaying"


pkgId: 147f55ecdab6358938f1c8daf233651af133cfbb134b9c774cfda2fce46d3867
name: 3isec-qubes-sys-multimedia
arch: x86_64
version: 2.2
epoch: 0
release: 1.fc32
summary: creates multimedia template and qubes
rpm_license: GPLv3+
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: 3isec-qubes-sys-multimedia-2.2-1.fc32.src.rpm
location_href: 3isec-qubes-sys-multimedia-2.2-1.fc32.x86_64.rpm
checksum_type: sha256
description:
   This package sets up qubes to work mith multimedia files in Qubes.
   By default a qube named "media" is created, and configured so that any
   multimedia files are opened in a named disposable called "multimedia".
   This provides some measure of protection when working with untrusted files.

  The media qube is offline by default.
  The multimedia disposable is offline by default.
  You can change this if you wish, but be aware that this may result in
  data leakage.

  The idea is that you organise and store media files in the media qube.
  Opening a file in that qube will open the multimedia disposable and play
  the file there.
  You can also use the multimedia disposable from any other qube, or use the
  disposable template to create more disposables with different settings -
  perhaps online, or restricted to certain IP addresses.
  Access to the multimedia file is controlled from the policy file in
  /etc/qubes/policy.d/30-user.policy


pkgId: a95e988a5c6c58eb9c23f3ed35244111ce728c1bea957de393093546537b0569
name: 3isec-qubes-sys-ssh-agent
arch: x86_64
version: 1.2
epoch: 0
release: 1.fc32
summary: Create a service qube to hold ssh-agents
rpm_license: GPLv3+
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: 3isec-qubes-sys-ssh-agent-1.2-1.fc32.src.rpm
location_href: 3isec-qubes-sys-ssh-agent-1.2-1.fc32.x86_64.rpm
checksum_type: sha256
description:
  This package sets up a qube called sys-ssh-agent, to hold ssh keys.
  It is ideal for use cases where you have a number of key pairs, which
  are used by different qubes.

  The keypairs are stored in the offline sys-ssh-agent server, and requests
  are passed from clients to the server via qrexec.
  Clients may access the same ssh-agent, or access different agents.
  Access is controlled via dom0 policy file, /etc/qubes/policy.d/30-user.policy

  The client does not know the identity of the ssh-agent server, nor are
  keys kept in memory in the client.
  All configuration of keys, and unlocking of keys, where they are password
  protected, is done in the ssh-agent server, using standard ssh-agent
  controls.
  Keys can be selectively allocated to different ssh-agents.
  You can create multiple ssh-agents holding different combination of ssh keys.
  This allow you to access different key sets from different qubes.
  By default an ssh-agent called "work" is provided in sys-ssh-agent.
  Helper scripts are provided to create new ssh-agents.

  You can create other qubes to hold other ssh-agents if you  want, for
  maximum compartmentalisation.
  Simply clone sys-ssh-agent and edit the ssh-agents.

  Removing this package will NOT delete the qubes, but will remove the
  entry in /etc/qubes/policy.d/30-user.policy.


pkgId: 6eeb0eda790b671179acf2de14acace757a2a2488b3618bd7a0e8ce30c5286e6
name: 3isec-qubes-sys-vpn
arch: x86_64
version: 1.4
epoch: 0
release: 1.fc32
summary: Create an openvpn proxy in Qubes
rpm_license: GPLv3+
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: 3isec-qubes-sys-vpn-1.4-1.fc32.src.rpm
location_href: 3isec-qubes-sys-vpn-1.4-1.fc32.x86_64.rpm
checksum_type: sha256
description:
  This package sets up a VPN gateway, named sys-vpn, using openvpn.
  It follows the method detailed in the Qubes docs,
   https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md
  using iptables and CLI scripts.

  The package creates a qube called sys-vpn based on the debian-11-minimal
  template.  If the debian-11-minimal template is not present, it will
  be downloaded and installed - this may take some time depending on your
  net connection.

  There are minor changes to the firewall rules on sys-vpn to ensure
  blocking of outbound connections.

  After installing, copy your openvpn configuration file or zip file
  to sys-vpn.
  Run setup_vpn to set up the VPN.
  There should be a menu item for this script - if you cannot see it, you may
  need to refresh the application list in sys-vpn settings.
  When finished, restart sys-vpn.

  To use the VPN, set sys-vpn as the netvm for your qubes(s).
  All traffic will go through the VPN.
  The VPN will fail closed if the connection drops.
  No traffic will go through clear.

  If you remove the package, the salt files will be removed.
  **The sys-vpn gateway will also be removed.**
  To do this ALL qubes will be checked to see if they use sys-vpn.
  If they do, their netvm will be set to `none`.

  You can, of course, use template-openvpn to create other VPN gateways.


