Kicksecure APT Repository
Kicksecure stable / testers / developers APT Repository. How to change from one suite to another? How to disable Kicksecure APT Repository?
Kicksecure APT Repository Overview
Kicksecure currently provides four repository choices:
stableAPT repository: Recommended for most users. The production level packages focus on providing the most reliable Kicksecure experience. 
stable-proposed-updatesAPT repository: After testing by a wider audience, these packages migrate to the stable repository. 
testersAPT repository: Recommended for testers, since it is only briefly tested by Kicksecure developers. It could break APT during an upgrade, requiring terminal commands to rectify the problem. 
developersAPT repository: As above, except it includes untested changes. These changes may eventually migrate to the testers repository there is reasonable certainty that these changes will not break the update system. It is not recommended, unless the user is in touch with the development team.
Due to the Kicksecure design, a user's security is unlikely to be materially affected by preferring the "beta" (
stable-proposed-updates) or "alpha" (
testers) repositories over the default stable one. 
Change Kicksecure APT Repository
It is easy for users to switch between Kicksecure repositories.
If you are using [[Qubes|Template:Q project name]], please press Expand on the right.
If you are using Kicksecure, please press Expand on the right.
Afterwards, the following window will appear.
Figure: Auto-update Configuration
Figure: Repository Selection
Command Line Interface
If you are a terminal user, please press Expand on the right.
In Terminal, run.
Figure: Launch Terminal
Figure: Run repository-dist
Choose one of the following repositories based on personal preferences.
sudo repository-dist --enable --repository stable
sudo repository-dist --enable --repository stable-proposed-updates
sudo repository-dist--enable --repository testers
sudo repository-dist --enable --repository developers
To use the repository, follow the usual update instructions.
Disable Kicksecure APT Repository
For Trust reasons some users may prefer not to use Kicksecure APT Repository. In that case, it is necessary to update Debian packages in Kicksecure from source code, which is inconvenient.
All Default-Download-Version Kicksecure variants have the Kicksecure APT repository enabled. It can be disabled via the GUI or in a terminal with the Derivative Repository Tool.
Table: Kicksecure APT Repository Disabling
|Platform / Method||Instructions|
|Kicksecure Built from Source Code||If Kicksecure is built from source code, Kicksecure APT Repository is not added by default. The only exception is if users opt in using a build configuration. It is also possible to verify that it is already disabled.|
|Kicksecure Default-Download-Version: GUI||
|Kicksecure Default-Download-Version: Terminal||To disable it in a terminal, run. |
sudo repository-dist --disable
Users can optionally verify Kicksecure APT repository is disabled after this procedure.
Verify Kicksecure APT Repository is Disabled
To check the Kicksecure APT repository was successfully disabled, run the following tests.
1. Use apt-key.
sudo apt-key finger
This test should not show any Kicksecure-specific keys, such as Patrick Schleizer's OpenPGP key.
2. Check if file
If it does not exist, the procedure was successful.
3. Optional: conduct additional tests as a precaution.
/etc/apt/sources.list file. It should not include the Kicksecure APT Repository.
Next examine the /etc/apt/sources.list.d/ folder as well.
- Kicksecure Debian package - which ones are safe to remove?
- Building/upgrading Kicksecure Debian packages from source code
- APT development notes
If possible, users are requested to run a separate testers-only Kicksecure that has the
testersrepository enabled. If too few people test Kicksecure, undiscovered issues might migrate to the stable repository.
- Users are recommended to make a VM clone for this repository just in case it breaks. That way changes can be rolled back if necessary.
betaare avoided because they have generally lost their meaning in the software field; many applications remain in
betastatus for years, even though they work perfectly well.