Dev/About Debian Packaging
Debian Packaging of Kicksecure Design Documentation / Recommends vs Depends / --no-install-recommends / Files in Home Folder / Files in /etc/skel
Analyzing Dependency Chains[edit]
reverse-depends[edit]
1. Modify /etc/dpkg/origins/default
.
sudo unlink /etc/dpkg/origins/default sudo ln -s /etc/dpkg/origins/debian /etc/dpkg/origins/default
2. Download the source package.
apt source package
3. Undo afterwards to prevent unexpected issues.
sudo unlink /etc/dpkg/origins/default sudo ln -s /etc/dpkg/origins/whonix /etc/dpkg/origins/default
Install ubuntu-dev-tools
. To accomplish that, the following steps A. to D. need to be done.
A. Update the package lists.
sudo apt update
B. Upgrade the system.
sudo apt full-upgrade
C. Install the ubuntu-dev-tools
package.
Using apt
command line parameter --no-install-recommends
is in most cases optional.
sudo apt install --no-install-recommends ubuntu-dev-tools
D. Done.
The procedure of installing ubuntu-dev-tools
is complete.
reverse-depends evolution-data-server
meta packages[edit]
Recommends vs Depends[edit]
This is about Recommends:
vs Depends:
in context of debian/control
.
debian/control
: There are separate meta packages for dependencies and recommended packages. For example:
kicksecure-xfce
kicksecure-cli
The reason for this is, because if we used the Recommends:
field for Kicksecure meta packages (those who pull the required Debian upstream packages for creating Kicksecure), we could not install them using apt
with --install-recommends
, which is apt
's default option, because that would also install packages recommend by any dependency we install.
On the other hand, if we installed using apt --no-install-recommends
, the packages Kicksecure meta packages recommends, will not get installed.
Therefore splitting them into packages suffixed *-dependencies
or *-recommended
which both use Depends:
and installing them using --no-install-recommends
appeared to be the only solution.
Otherwise it would install packages such as virtuoso
, soprano
and vlc
, which are not useful in context of Kicksecure™.
The Recommends:
and Suggests:
field is still being used but this is mostly useful for one package advertising related packages users using apt-cache show package-name
and Packages for Debian Hosts.
See also:
Files in Home Folder[edit]
Packages placing files /home
folder must use the correct mechanism for doing so. Using defined mechanisms (see below) might be appropriate. Directly writing /home
is prohibited for reasons listed below.
/home
is for users. Not for distribution contributors.- Leads to a dpkg interactive conflict resolution dialog when package file is updated, in case file gets modified by the user or a program in the home folder (which is often very likely), which is a usability issue, which we try to avoid.
serious
lintian
errordir-or-file-in-home
.
- Makes the package unfit for inclusion into
packages.debian.org
(very long term goal) (or other package repositories). - Looks amateurish in the eyes of Debian packagers.
- Makes the package unfit for inclusion into
- For which user? User
user
only? Inconsistent for multi user use cases. Hard to combine with future Multiple Boot Modes for Better Security - an Implementation of Untrusted Root withuser
, usersecureadmin
and usersuperadmin
. - Doesn't work / inconsistent in Qubes
Template. Since packages are usually upgraded in Templates, the change never propagates to the home folder of the App Qube since it has an independently persistent home folder.
- Special code would be required to handle these cases. Such as a script that runs after boot but in Template that are not Disposable Template only. Example:
- https://github.com/Kicksecure/tb-updater/blob/master/lib/systemd/system/tb-updater-first-boot.service
- More code to carry around, understand interactions, bugfix, maintain, explain, audit.
- https://github.com/Kicksecure/tb-updater/blob/master/lib/systemd/system/tb-updater-first-boot.service
- Special code would be required to handle these cases. Such as a script that runs after boot but in Template that are not Disposable Template only. Example:
- In most cases there are more suitable mechanisms to reach the implementation goal than writing into the user's home folder.
- Files in /etc/skel
- If not, the lack of such mechanisms should be discussed with / requested from upstream.
Files in /etc/skel[edit]
- Files in
/etc/skel
are not as bad as files in/home
folder.- Works for any user.
- Inconsistencies. Not deployed through
/etc/skel
mechanism if file is added to a package after a user account was created. I.e. users who upgraded will miss that file.- Needs special code to handle such cases.
- If the file from
/etc/skel
is in the user's home folder, it's hard to update it. Updating the file in/etc/skel
won't effect the user's version of the file in the user's home folder.- Needs special code to handle such cases.
Modifying Default Configuration of Third Party Packages[edit]
Taking systemd as an example. Suppose /lib/systemd/system/systemd-random-seed.service
modifications are desired.
File /lib/systemd/system/systemd-random-seed.service
is owned by a third party package systemd
.
dpkg -S /lib/systemd/system/systemd-random-seed.service
systemd: /lib/systemd/system/systemd-random-seed.service
- Editing
/lib/systemd/system/systemd-random-seed.service
.- Is the worst (changes get lost on systemd package gets upgraded) (there is a solution using
dpkg-divert
encapsulated in a more sane by usingconfig-package-dev
displace
and we use it in Kicksecure source code where it could not be avoided but if avoidable it is best avoided if possible somehow).
- Is the worst (changes get lost on systemd package gets upgraded) (there is a solution using
- Shipping
/etc/systemd/system/systemd-random-seed.service
- would be better but still not great (this is for local administrator, not linux distribution)
/lib/systemd/system/systemd-random-seed.service.d
folder and a file such as/lib/systemd/system/systemd-random-seed.service.d/30_something.conf
- is an ideal solution for linux distributions such as Kicksecure since it does not takeover files by other packages and does not take away something from the local system administrator or user.
config-package-dev[edit]
Debian package xfce4-session
owns file /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml
. Therefore package xfce-desktop-config-dist
cannot directly overwrite it.
Preparing to unpack .../xfce-desktop-config-dist_1.4-1_all.deb ... Unpacking xfce-desktop-config-dist (3:1.4-1) ... dpkg: error processing archive /mnt/initialdeb/pool/main/w/xfce-desktop-config-dist/xfce-desktop-config-dist_1.4-1_all.deb (--unpack): trying to overwrite '\''/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml'\'', which is also in package xfce4-session 4.12.1-6 Errors were encountered while processing: /mnt/initialdeb/pool/main/w/xfce-desktop-config-dist/xfce-desktop-config-dist_1.4-1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) ' + apt_get_exit_code=100
config-package-dev can help with such situations.
Examples on how to use config-package-dev displace:
- https://github.com/Kicksecure/desktop-config-dist/commit/0e9daa97e9f9e70120c969aa9c9d52cace46971a
- https://github.com/Kicksecure/security-misc/commit/93c08210545dd77b608515351154bcc16c8464b4
Ideally avoided as per above.
https://debathena.mit.edu/config-packages/
- upstream bug report dpkg-divert: warning: diverting file '/etc/issue' from an Essential package with rename is dangerous, use --no-rename
Desktop Environment (Xfce) Settings Changes[edit]
Testing modified desktop environment (Xfce) settings files in /etc/skel
or /home/user
is cumbersome.
When Xfce is shutdown, it might undo the manual or package modified settings in user home folder /home/user
as part of Xfce "save settings" procedure on shutdown. Therefore after reboot these settings might be reverted and could not be actually tested.
A script which is supposed to be run from a virtual console to simplify the steps:
/usr/libexec/helper-scripts/desktop-background-skel-test
Kicksecure / Whonix™ Package Design[edit]
- whonix-base-files: Whonix-Host, Whonix-Gateway, Whonix-Workstation
- whonix-libvirt: Whonix-Host only
- anon-gw-base-files: Whonix-Gateway only
- anon-ws-base-files: Whonix-Workstation only
- kicksecure-base-files: Kicksecure-VMs and Kicksecure-Hosts
- vm-config-dist: Kicksecure-VMs and Whonix-VMs
See Also[edit]
- Versioning Format Conventions
- Build Documentation
- Build Documentation to build any package by Kicksecure such as security-misc
- Dev/Build_Documentation/generic-package
Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 11 year success story and maybe DONATE!