Index of /Templates_4.1

Qubes templates

All templates are signed with my Qubes OS Signing key:
pub   4096R/C8C0C2EF 2016-06-25
      Key fingerprint = 4B1F 400D F256 51B5 3C41  41B3 8B3F 30F9 C8C0 C2EF
uid                  unman (Qubes OS signing key) 
sub   4096R/4731B36C 2016-06-27 [expires: 2022-06-30]

You can read about how to get a copy of the key, and how to validate it here.
You will need to copy the key in to dom0:
qvm-run -p qube 'cat PATH_TO_KEY ' >
and then import it: sudo rpm --import

Download the template you want to use, and copy it into dom0:
replacing TEMPLATE_PACKAGE_NAME with a name of your choice.
Then check the signature by (e.g):

Templates like Parrot or Kali are based on Debian testing.
To avoid breakage when updating, the core Qubes packages are on hold. This means that they will not be updated. You can confirm this by running apt-mark showhold in the template.
apt-mark unhold will remove the hold, and allow you to update the Qubes packages.
I suggest you restore the hold apt-mark hold to make sure that the Qubes packages are not removed when updating other packages.

So, while updating a template you will see that some packages cannot be upgraded because they will conflict with the Qubes packages.
Periodically, in the template, remove the hold on the Qubes packages. Update the package list with apt update and then update the Qubes packages - either manually with apt install... , or using a manager like aptitude, and selecting Qubes packages for upgrade.
Once the upgrade has been completed, put the Qubes packages back on hold, and upgrade again.

Undoubtedly a pain, but less than the pain of breaking your qubes, and having to crawl backwards to get them working again.
Then again, if you use aptitude you would be able to see what changes would be made, opt to retain the Qubes packages - always keep the Qubes packages, and avoid breakage that way. This depends on you looking to see what changes will be made and acting accordingly. Using apt-mark hold will take some pressure off.