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]

https://github.com/Kicksecure/kicksecure-meta-packages/blob/master/debian/control

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.

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 error dir-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.
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 with user, user secureadmin and user superadmin.
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.
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 using config-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).
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:

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

Dev/About Debian Packaging

Contents