mejo roamingmejo roaminghttps://blog.freesources.org//mejo roamingikiwiki2020-08-25T14:42:34Zcryptsetup-suspendhttps://blog.freesources.org//posts/2020/08/cryptsetup-suspend/2020-08-25T14:42:34Z2020-08-25T14:42:34Z
<h2 id="Introducing_cryptsetup-suspend">Introducing cryptsetup-suspend</h2>
<p>Today, we're introducing <code>cryptsetup-suspend</code>, whose job is to protect the content of your harddrives while the system is sleeping.</p>
<p><strong>TL;DR:</strong></p>
<ul>
<li>You can lock your encrypted harddrives during suspend mode by <a href="https://blog.freesources.org//#index6h2">installing <code>cryptsetup-suspend</code></a></li>
<li>For <code>cryptsetup-suspend</code> to work properly, at least Linux kernel 5.6 is required</li>
<li>We hope that in a bright future, everything will be available out-of-the-box in Debian and it's derivatives</li>
</ul>
<p><strong>Before:</strong></p>
<p><img src="https://blog.freesources.org/images/timeline_old.svg" alt="timeline_old.svg" /></p>
<p><strong>After:</strong></p>
<p><img src="https://blog.freesources.org/images/timeline_new.svg" alt="timeline_new.svg" /></p>
<h2 id="Table_of_contents">Table of contents</h2>
<h2 id="What_does_this_mean_and_why_should_you_care_about_it.3F">What does this mean and why should you care about it?</h2>
<p>If you don't use full-disk encryption, don't read any further. Instead, think about, what will happen if you lose your notebook on the train, a random person picks it up and browses through all your personal pictures, e-mails, and tax records. Then encrypt your system and come back.</p>
<p>If you believe full-disk encryption is necessary, you might know that it only works when your machine is powered off. Once you turn on the machine and decrypt your harddrive, your encryption key stays in RAM and can potentially be <a href="https://blog.appsecco.com/breaking-full-disk-encryption-from-a-memory-dump-5a868c4fc81e">extracted by malicious software or physical access</a>. Even if these attacks are non-trivial, it's enough to worry about. If an attacker is able to extract your disk encryption keys from memory, they're able to read the content of your disk in return.</p>
<p>Sadly, in 2020, we hardly power off our laptops anymore. The sleep mode, also known as "suspend mode", is just too convenient. Just close the lid to freeze the system state and lift it anytime later in order to continue. Well, convenience usually comes with a cost: during suspend mode, your system memory is kept powered, all your data - including your encryption keys - stays there, waiting to be extracted by a malicious person. Unfortunately, there are <a href="https://blog.appsecco.com/breaking-full-disk-encryption-from-a-memory-dump-5a868c4fc81e">practical attacks</a> to extract the data of your powered memory.</p>
<p>Cryptsetup-suspend expands the protection of your full-disk encryption to all those times when your computer sleeps in suspend mode. Cryptsetup-suspend utilizes the suspend feature of <a href="https://gitlab.com/cryptsetup/cryptsetup/blob/master/README.md">LUKS</a> volumes and integrates it with your Debian system. Encryption keys are evicted from memory before suspend mode and the volumes have to be re-opened after resuming - potentially prompting for the required passphrases.</p>
<p>By now, we have a working prototype which we want to introduce today. We did quite some testing, both on virtualized and bare-metal Debian and Ubuntu systems, with and without graphical stack, so we dare to unseal and set free the project and ask you - the community - to test, review, criticize and give feedback.</p>
<p><strong>Here's a screencast of <code>cryptsetup-suspend</code> in action:</strong></p>
<p><video width="450" controls>
<source src="/images/cryptsetup-suspend-screencast.webm" type="video/webm">
Your browser doesn't support the video tag.
</video></p>
<h2 id="State_of_the_implementation.3A_where_are_we.3F">State of the implementation: where are we?</h2>
<p>If you're interested in the technical details, here's how <code>cryptsetup-suspend</code> works internally. It basically consists of three parts:</p>
<p><img src="https://blog.freesources.org/images/cryptsetup-suspend.svg" alt="cryptsetup-suspend.svg" /></p>
<ol>
<li><code>cryptsetup-suspend</code>: A C program that takes a list of LUKS devices as arguments, suspends them via <code>luksSuspend</code> and suspends the system afterwards. Also, it tries to reserve some memory for decryption, which we'll explain below.</li>
<li><code>cryptsetup-suspend-wrapper</code>: A shell wrapper script which works the following way:
<ol>
<li>Extract the initramfs into a ramfs</li>
<li>Run (systemd) pre-suspend scripts, stop udev, freeze almost all <a href="https://en.wikipedia.org/wiki/Cgroups">cgroups</a></li>
<li>Chroot into the ramfs and run <code>cryptsetup-suspend</code></li>
<li>Resume initramfs devices inside chroot after resume</li>
<li>Resume non-initramfs devices outside chroot</li>
<li>Thaw groups, start udev, run (systemd) post-suspend scripts</li>
<li>Unmount the ramfs</li>
</ol>
</li>
<li>A systemd unit drop-in file overriding the <code>Exec</code> property of <code>systemd-suspend.service</code> so that it invokes the script <code>cryptsetup-suspend-wrapper</code>.</li>
</ol>
<p>Reusing large parts of the existing cryptsetup-initramfs implementation has some positive side-effects: Out-of-the-box, we support all LUKS block device setups that have been supported by the Debian cryptsetup packages before.</p>
<p>Freezing most processes/cgroups is necessary to prevent possible race-conditions and dead-locks after the system resumes. Processes will try to access data on the locked/suspended block devices eventually leading to buffer overflows and data loss.</p>
<h2 id="Technical_challenges_and_caveats">Technical challenges and caveats</h2>
<ul>
<li><strong>Dead-locks at suspend</strong>: In order to prevent possible dead-locks between suspending the encrypted LUKS disks and suspending the system, we have to tell the Linux kernel to <em>not</em> <code>sync()</code> before going to sleep. A <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c052bf82c6b00ca27aab0859addc4b3159dfd3a4">corresponding patch</a> got accepted upstream in Linux 5.6. See section <a href="https://blog.freesources.org//#What_about_the_kernel_patch.3F">What about the kernel patch?</a> below for details.</li>
<li><strong>Race conditions at resume</strong>: Likewise, there's a risk of race conditions between resuming the system and unlocking the encypted LUKS disks. We went with freezing as many processes as possible as a counter measurement. See last part of section <a href="https://blog.freesources.org//#State_of_the_implementation.3A_where_are_we.3F">State of the implementation: where are we?</a> for details.</li>
<li><strong>Memory management</strong>: Memory management is definitely a challenge. Unlocking disks might require a lot of memory (if <a href="https://en.wikipedia.org/wiki/Key_derivation_function">key derivation function</a> is argon2i) and the swap device most likely is locked at that time. See section <a href="https://blog.freesources.org//#All_that_matters_to_me_is_the_memories.21">All that matters to me is the memories!</a> below for details.</li>
<li><strong>systemd dependency</strong>: Our implementation depends on systemd. It uses a unit drop-in file for <code>systemd-suspend.service</code> for hooking into the system suspend process and depends on systemds cgroup management to freeze and thaw processes. If you're using a different init system, sorry, you're currently out of luck.</li>
</ul>
<h3 id="What_about_the_kernel_patch.3F">What about the kernel patch?</h3>
<p>The problem is simple: the Linux kernel suspend implementation enforces a <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/power/suspend.c?h=v5.5#n569">final filesystem sync() before the system goes to sleep</a> in order to prevent potential data loss. While that's sensible in most scenarios, it may result in dead-locks in our situation, since the block device that holds the filesystem is already suspended. The <code>fssync()</code> call will block forever as it waits for the block device to finish the <code>sync()</code> operation. So we need a way to conditionally disable this <code>sync()</code> call in the Linux kernel resume function. That's what <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c052bf82c6b00ca27aab0859addc4b3159dfd3a4">our patch</a> does, by introducing a run-time switch at <code>/sys/power/sync_on_suspend</code>, but it only got accepted into the Linux kernel recently and was first released with Linux kernel 5.6.</p>
<p>Since release 4.3, the Linux kernel at least provides a build-time flag to disable the <code>sync()</code>: <code>CONFIG_SUSPEND_SKIP_SYNC</code> (that was called <code>SUSPEND_SKIP_SYNC</code> first and renamed to <code>CONFIG_SUSPEND_SKIP_SYNC</code> in kernel release 4.9). Enabling this flag at build-time protects you against the dead locks perfectly well. But while that works on an individual basis, it's a non-option for the distribution Linux kernel defaults. In most cases you still want the <code>sync()</code> to happen, except if you have user-space code that takes care of the <code>sync()</code> just before suspending your system - just like our <code>cryptsetup-suspend</code> implementation does.</p>
<p>So in order to properly test <code>cryptsetup-suspend</code>, you're strongly advised to run Linux kernel 5.6 or newer. Fortunately, Linux 5.6 is available in <code>buster-backports</code> thanks to the Debian Kernel Team.</p>
<h3 id="All_that_matters_to_me_is_the_memories.21">All that matters to me is the memories!</h3>
<p>One of the tricky parts is memory management. Since version 2, LUKS uses argon2i as default key derivation function. Argon2i is a memory-hard hash function and LUKS2 assigns the minimum of half of your systems memory or 1 GB to unlocking your device. While this is usually unproblematic during system boot - there's not much in the system memory anyway - it can become problematic when suspending. When cryptsetup tries to unlock a device and wants 1 GB of memory for this, but everything is already occupied by your browser and video player, there's only two options what to do:</p>
<ol>
<li>Kill a process to free some memory</li>
<li>Move some of the data from memory to swap space</li>
</ol>
<p>The first option is certainly not what you expect when suspending your system. The second option is impossible, because swap is located on your harddrive which we have locked before. Our current solution is to allocate the memory after freezing the other processes, but before locking the disks. At this time, the system can still move data to swap, but it won't be accessed anymore. We then release the memory just in time for cryptsetup to claim it again. The implementation of this is still subject to change.</p>
<p><img src="https://blog.freesources.org/images/memories.gif" alt="memories.gif" /></p>
<h3 id="What.27s_missing.3A_A_proper_user_interface">What's missing: A proper user interface</h3>
<p>As mentioned before, we consider <code>cryptsetup-suspend</code> usable, but it certainly still has bugs and shortcomings. The most obvious one is lack of a proper user interface. Currently, we switch over to a tty command-line interface to prompt for passphrases when unlocking the LUKS devices. It certainly would be better to replace this with a graphical user interface later, probably by using plymouth or something alike. Unfortunately, it seems rather impossible to spawn a real graphical environment for the passphrase prompt. That would imply to load the full graphical stack into the ramfs, raising the required amount of memory significantly. Lack of memory is currently our biggest concern and source of trouble.</p>
<p>We'd definitely appreciate to learn about your ideas how to improve the user experience here.</p>
<h2 id="Let.27s_get_practical.3A_how_to_use">Let's get practical: how to use</h2>
<p><strong>TL;DR:</strong> On Debian Bullseye (Testing), all you need to do is to install the <a href="https://packages.debian.org/experimental/cryptsetup-suspend"><code>cryptsetup-suspend</code> package from experimental</a>. It's not necessary to upgrade the other cryptsetup packages. On Debian Buster, cryptsetup packages from backports are required.</p>
<ol>
<li>First, be sure that you're running Linux kernel 5.6 or newer. For Buster systems, it's available in <a href="https://packages.debian.org/buster-backports/linux-image-amd64">buster-backports</a>.</li>
<li>Second, if you're on Debian Buster, install the <a href="https://packages.debian.org/buster-backports/cryptsetup">cryptsetup 2:2.3.3-2~bpo10+1 packages from buster-backports</a>.</li>
<li>Third, install the <a href="https://packages.debian.org/experimental/cryptsetup-suspend"><code>cryptsetup-suspend</code> package from experimental</a>. Beware that <code>cryptsetup-suspend</code> depends on <code>cryptsetup-initramfs (>= 2:2.3.3-1~)</code>. Either you need the cryptsetup packages from <code>testing/unstable</code>, or the backports from <code>buster-backports</code>.</li>
<li>Now that you have the <code>cryptsetup-suspend</code> package installed, everything should be in place: Just send your system to sleep. It should switch to a virtual text terminal before going to sleep, ask for a passphrase to unlock your encrypted disk(s) after resume and switch back to your former working environment (most likely your graphical desktop environment) afterwards.</li>
</ol>
<h2 id="Security_considerations">Security considerations</h2>
<p>Suspending LUKS devices basically means to remove the corresponding encryption keys from system memory. This protects against all sort of attacks trying to read them from there, e.g. <a href="https://en.wikipedia.org/wiki/Cold_boot_attack">cold-boot attacks</a>. But, <code>cryptsetup-suspend</code> only protects the encryption keys of your LUKS devices. Most likely there's more sensitive data in system memory, like all kinds of private keys (e.g. OpenPGP, OpenSSH) or documents with sensitive content.</p>
<p>We hope that the community will help improve this situation by providing useful pre-/post-suspend scripts. A positive example is <a href="https://keepassxc.org/">KeepassXC</a>, which is able to lock itself when going to suspend mode.</p>
<h2 id="Related_and_similar_projects">Related and similar projects</h2>
<ul>
<li>Systemd Homed: systemd recently got a <a href="https://github.com/systemd/systemd/blob/master/docs/HOME_DIRECTORY.md">new feature to manage home directories</a>. It brings support for encrypting your home directory within a LUKS2 container <em>and</em> for suspending the LUKS2 container during system sleep. It all is limited to systemd home directories though and doesn't help with other LUKS devices.</li>
<li>There's several earlier <code>luks-suspend-*</code> implementations. Unfortunately, neither of them deal with all the <a href="https://blog.freesources.org//#Technical_challenges_and_caveats">Technical challenges and caveats</a> we discovered. Still we'd like to mention some of them:</li>
<li><a href="https://github.com/nailfarmer/debian-luks-suspend/">debian-luks-suspend</a></li>
<li><a href="https://github.com/guns/go-luks-suspend/">go-luks-suspend</a></li>
<li><a href="https://github.com/vianney/arch-luks-suspend/">arch-luks-suspend</a></li>
</ul>
<h2 id="Links">Links</h2>
<ul>
<li>Our Linux kernel patch: <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c052bf82c6b00ca27aab0859addc4b3159dfd3a4">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c052bf82c6b00ca27aab0859addc4b3159dfd3a4</a></li>
<li>The <code>debian/experimental</code> branch of our Debian cryptsetup packaging repository, containing <code>cryptsetup-suspend</code> related changes: <a href="https://salsa.debian.org/cryptsetup-team/cryptsetup/-/tree/debian/experimental">https://salsa.debian.org/cryptsetup-team/cryptsetup/-/tree/debian/experimental</a></li>
<li><code>cryptsetup-suspend</code> manpage: <a href="https://salsa.debian.org/cryptsetup-team/cryptsetup/-/blob/debian/experimental/debian/doc/cryptsetup-suspend.xml">https://salsa.debian.org/cryptsetup-team/cryptsetup/-/blob/debian/experimental/debian/doc/cryptsetup-suspend.xml</a></li>
</ul>
<h2 id="Feedback_and_Comments">Feedback and Comments</h2>
<p>We'd be more than happy to learn about your thoughts on cryptsetup-suspend. For specific issues, don't hesitate to open a <a href="https://bugs.debian.org/cryptsetup-suspend">bugreport against cryptsetup-suspend</a>. You can also reach us via mail - see the next section for contact addresses. Last but not least, comments below the blogpost work as well.</p>
<h2 id="Authors">Authors</h2>
<ul>
<li>Tim (tim at systemli.org)</li>
<li>Jonas (jonas at freesources.org)</li>
</ul>
switch to swayhttps://blog.freesources.org//posts/2019/12/switch_to_sway/2020-02-03T13:33:59Z2019-12-05T14:10:00Z
<h1 id="Switching_from_Gnome_to_a_tiling_window_manager">Switching from Gnome to a tiling window manager</h1>
<p>After having thought about it since "forever", I finally decided to switch
to a tiling window manager. I went with sway since it runs on wayland and
since it seems to be the recommended "wayland version of i3", a tiling
window manager that many of my tech friends use ;)</p>
<p>After a few days of using sway, I'm pretty sure that I won't switch back
anytime soon. It feels super convenient to have all windows tiled on the
screen and being able to rearrange and resize them easily with a few
keyboard shortcuts.</p>
<p>There's still some things that didn't work instantly, so I'll try to
document them here in hope that it's useful to others. Feedback welcome!</p>
<p>This blog post covers the following topics:</p>
<ul>
<li><a href="https://blog.freesources.org//#Install_sway_on_Debian_Buster">Install sway on Debian Buster</a></li>
<li><a href="https://blog.freesources.org//#Basic_sway_configuration">Basic sway configuration</a></li>
<li><a href="https://blog.freesources.org//#Picking_an_application_launcher">Picking an application launcher</a></li>
<li><a href="https://blog.freesources.org//#Configure_the_status_bar">Configure the status bar</a></li>
<li><a href="https://blog.freesources.org//#Configure_a_notification_daemon">Configure notification daemon</a></li>
<li><a href="https://blog.freesources.org//#Preserve_working_directory_in_new_terminal_instances">Preserve working directory in new terminal
instances</a></li>
<li><a href="https://blog.freesources.org//#Use_gnome-keyring_as_SSH_agent_with_sway">Use gnome-keyring as SSH agent with
sway</a></li>
<li><a href="https://blog.freesources.org//#What.27s_missing">What's missing</a></li>
</ul>
<h2 id="Install_sway_on_Debian_Buster">Install sway on Debian Buster</h2>
<p>I run Debian Buster on my work machine. The sway components aren't available
in Buster or buster-backports yet, so I went with installing the packages
from Unstable or experimental manually. I'll probably help with backporting
them to buster-backports once I settled on using sway.</p>
<p>Lucky enough, sway packages only bring one dependency that's not satisfied
in Buster, which is <code>libjson-c4</code>. So for now, to install the sway Debian
packages on Buster, you have to do the following:</p>
<div class="highlight-sh"><pre class="hl">mkdir ~<span class="hl opt">/</span>devel<span class="hl opt">/</span>sway <span class="hl opt">&&</span> <span class="hl kwb">cd</span> ~<span class="hl opt">/</span>devel<span class="hl opt">/</span>sway
wget http<span class="hl opt">://</span><span class="hl kwc">ftp</span>.de.debian.org<span class="hl opt">/</span>debian<span class="hl opt">/</span>pool<span class="hl opt">/</span>main<span class="hl opt">/</span>w<span class="hl opt">/</span>wlroots<span class="hl opt">/</span>libwlroots3_0.7<span class="hl num">.0</span><span class="hl opt">-</span><span class="hl num">2</span>_amd64.deb
wget http<span class="hl opt">://</span><span class="hl kwc">ftp</span>.de.debian.org<span class="hl opt">/</span>debian<span class="hl opt">/</span>pool<span class="hl opt">/</span>main<span class="hl opt">/</span>s<span class="hl opt">/</span>scdoc<span class="hl opt">/</span>scdoc_1.10<span class="hl num">.0</span><span class="hl opt">-</span><span class="hl num">1</span>_amd64.deb
wget http<span class="hl opt">://</span><span class="hl kwc">ftp</span>.de.debian.org<span class="hl opt">/</span>debian<span class="hl opt">/</span>pool<span class="hl opt">/</span>main<span class="hl opt">/</span>s<span class="hl opt">/</span>swaybg<span class="hl opt">/</span>swaybg_1.0<span class="hl opt">-</span><span class="hl num">2</span>_amd64.deb
wget http<span class="hl opt">://</span><span class="hl kwc">ftp</span>.de.debian.org<span class="hl opt">/</span>debian<span class="hl opt">/</span>pool<span class="hl opt">/</span>main<span class="hl opt">/</span>s<span class="hl opt">/</span>swaylock<span class="hl opt">/</span>swaylock_1.4<span class="hl opt">-</span><span class="hl num">1</span>_amd64.deb
wget http<span class="hl opt">://</span><span class="hl kwc">ftp</span>.de.debian.org<span class="hl opt">/</span>debian<span class="hl opt">/</span>pool<span class="hl opt">/</span>main<span class="hl opt">/</span>s<span class="hl opt">/</span>swayidle<span class="hl opt">/</span>swayidle_1.5<span class="hl opt">-</span><span class="hl num">1</span>_amd64.deb
wget http<span class="hl opt">://</span><span class="hl kwc">ftp</span>.de.debian.org<span class="hl opt">/</span>debian<span class="hl opt">/</span>pool<span class="hl opt">/</span>main<span class="hl opt">/</span>s<span class="hl opt">/</span>sway<span class="hl opt">/</span>sway-backgrounds_1.2<span class="hl opt">-</span><span class="hl num">1</span>_all.deb
wget http<span class="hl opt">://</span><span class="hl kwc">ftp</span>.de.debian.org<span class="hl opt">/</span>debian<span class="hl opt">/</span>pool<span class="hl opt">/</span>main<span class="hl opt">/</span>j<span class="hl opt">/</span>json-c<span class="hl opt">/</span>libjson-c4_0.13<span class="hl num">.1</span><span class="hl opt">+</span>dfsg-6_amd64.deb
wget http<span class="hl opt">://</span><span class="hl kwc">ftp</span>.de.debian.org<span class="hl opt">/</span>debian<span class="hl opt">/</span>pool<span class="hl opt">/</span>main<span class="hl opt">/</span>s<span class="hl opt">/</span>sway<span class="hl opt">/</span>sway_1.2<span class="hl opt">-</span><span class="hl num">1</span>_amd64.deb
apt <span class="hl kwc">install</span> .<span class="hl opt">/</span>libwlroots3_0.7<span class="hl num">.0</span><span class="hl opt">-</span><span class="hl num">2</span>_amd64.deb .<span class="hl opt">/</span>scdoc_1.10<span class="hl num">.0</span><span class="hl opt">-</span><span class="hl num">1</span>_amd64.deb .<span class="hl opt">/</span>swaybg_1.0<span class="hl opt">-</span><span class="hl num">2</span>_amd64.deb .<span class="hl opt">/</span>swaylock_1.4<span class="hl opt">-</span><span class="hl num">1</span>_amd64.deb .<span class="hl opt">/</span>swayidle_1.5<span class="hl opt">-</span><span class="hl num">1</span>_amd64.deb .<span class="hl opt">/</span>sway-backgrounds_1.2<span class="hl opt">-</span><span class="hl num">1</span>_all.deb .<span class="hl opt">/</span>libjson-c4_0.13<span class="hl num">.1</span> .<span class="hl opt">/</span>sway_1.2<span class="hl opt">-</span><span class="hl num">1</span>_amd64.deb
<span class="hl slc"># Install dunst, i3status and dmenu</span>
apt <span class="hl kwc">install</span> dunst i3status suckless-tools
<span class="hl slc"># Install brightnessctl (for controlling the screen backlight) and</span>
<span class="hl slc"># blueman (for bluetooth management)</span>
apt <span class="hl kwc">install</span> brightnessctl brightness-udev blueman
</pre></div>
<h2 id="Basic_sway_configuration">Basic sway configuration</h2>
<p>Sway brings a good basic configuration at <code>/etc/sway/config</code>. In order to
customize it, copy the file over to <code>~/.config/sway/config</code>. First things
I changed were the following:</p>
<pre><code># Disable windows title bars
default_border pixel
# Use tilix wrapper as terminal emulator (more on that later)
set $term ~/.config/sway/scripts/tilix-wrapper.sh
# My internal laptop screen
set $laptop_screen eDP-1
# Command to lock screen
set $lock 'swaylock -F -f -e -K -l -c 000000'
# Default wallpaper
output * bg ~/Pictures/favourite_background.jpg fill
# Idle configuration
exec swayidle -w \
timeout 300 $lock \
timeout 600 'swaymsg "output * dpms off"' \
resume 'swaymsg "output * dpms on"' \
before-sleep $lock
# Internal Thinkpad Keyboard
input "1:1:AT_Translated_Set_2_keyboard" {
xkb_layout de,us
# Change keyboard layouts on <Super>+<Space>
xkb_options grp:win_space_toggle
}
# Cherry Keyboard
input "1130:275:Cherry_GmbH_CHERRY_Wired_Keyboard" {
xkb_layout de,us
# Change keyboard layouts on <Super>+<Space>
xkb_options grp:win_space_toggle
}
# Internal Thinkpad Touchscreen
input "2:7:SynPS/2_Synaptics_TouchPad" natural_scroll "enabled"
# Status Bar
bar {
position top
# Use i3status as status bar
status_command i3status
}
# Custom key bindings
# Lock screen
bindsym $mod+Escape exec $lock
# Audio and brightness key bindings
bindsym XF86AudioRaiseVolume exec pactl set-sink-volume @DEFAULT_SINK@ +5%
bindsym XF86AudioLowerVolume exec pactl set-sink-volume @DEFAULT_SINK@ -5%
bindsym XF86AudioMute exec pactl set-sink-mute @DEFAULT_SINK@ toggle
bindsym XF86AudioMicMute exec pactl set-source-mute @DEFAULT_SOURCE@ toggle
bindsym XF86MonBrightnessDown exec brightnessctl set 5%-
bindsym XF86MonBrightnessUp exec brightnessctl set +5%
bindsym XF86AudioPlay exec playerctl play-pause
bindsym XF86AudioNext exec playerctl next
bindsym XF86AudioPrev exec playerctl previous
# Bindings for Firefox and Thunderbird
bindsym $mod+Shift+b exec "env MOZ_ENABLE_WAYLAND=1 firefox"
bindsym $mod+Shift+m exec "thunderbird"
# Autostart
# Start dunst, a notification daemon
exec dunst
# Start some programs in fixed worspaces
assign [app_id="firefox"] → 1
exec "env MOZ_ENABLE_WAYLAND=1 firefox"
assign [class="thunderbird"] → 2
exec "thunderbird"
</code></pre>
<h2 id="Picking_an_application_launcher">Picking an application launcher</h2>
<p>The default application launcher to be used is dmenu (from suckless-tools).
While it works okayish, I don't particularly like it. In my eyes, it looks
rather old-fashioned, and even worse, it doesn't seem to have support for
freedesktop.org desktop entries.</p>
<p>I looked around a bit and <a href="https://hg.sr.ht/~scoopta/wofi">wofi</a> sounded
pretty promising. It's not in Debian yet but was easy to compile. A big
downer though is that it depends on a newer libglib2.0 version (2.60) than
in Debian Buster. I still compiled it in a Bullseye schroot and got a
first impression. I like it's look and feel (after a bit CSS customization)
and probably I'll go with packaging it for Debian.</p>
<p>For the moment, I'm stuck with dmenu on my working system, though.</p>
<p>Update: I <a href="https://packages.debian.org/wofi">packaged wofi</a> in the meantime
and decided to install libglib2.0 from Bullseye to fullfill its dependencies.
So I'm running wofi now and I'm very happy with it so far.</p>
<p>Fore reference, here's my wofi config file (<code>~/.config/wofi/config</code>):</p>
<pre><code>mode=drun
colors=colors
filter_rate=100
</code></pre>
<p>And my custom wofi stylesheet (<code>~/.config/wofi/style.css</code>):</p>
<pre><code>window {
margin: 5px;
#border: 2px solid #282C34;
#border: 2px solid blue;
#background-color: #282C34;
#background-color: #282C34;
background-color: transparent;
}
#input {
margin-left: 70px;
margin-right: 70px;
margin-top: 10px;
margin-bottom: 10px;
border: 2px solid blue;
#border: 2px solid #777D87;
border: 2px solid grey;
#background-color: #E5C07B;
#background-color: #282C34;
background-color: darkgrey;
}
#scroll {
margin: 5px;
#border: 2px solid #282C34;
border: 2px solid #61AFEF;
#background-color: #777D87;
#background-color: #ABB2BF;
background-color: #282C34;
}
#inner-box {
margin: 20px;
}
#text {
margin: 5px;
color: #E5C07B;
}
</code></pre>
<h2 id="Configure_the_status_bar">Configure the status bar</h2>
<p>I decided to go with the <code>i3status</code> status bar and it serves my purposes
pretty well. Here's my config (<code>/.config/i3status/config</code>):</p>
<pre><code># i3status configuration file.
# see "man i3status" for documentation.
# It is important that this file is edited as UTF-8.
# The following line should contain a sharp s:
# ß
# If the above line is not correctly displayed, fix your editor first!
general {
#colors = true
colors = false
interval = 5
}
order += "load"
order += "wireless _first_"
order += "ethernet _first_"
order += "path_exists VPN"
order += "battery all"
order += "tztime local"
# Customized wireless status
wireless _first_ {
format_up = "W: (%quality at %essid) %ip"
format_down = "W: down"
}
# Only show ethernet status when connected
ethernet _first_ {
# if you use %speed, i3status requires root privileges
format_up = "E: %ip"
format_down = ""
}
# Display VPN status
path_exists VPN {
# path exists when a VPN tunnel launched by nmcli/nm-applet is active
path = "/proc/sys/net/ipv4/conf/tun0"
}
# Customized battery status
battery all {
format = "%status %percentage"
status_chr = "⚡"
status_bat = "🔋"
status_full = "☻"
}
# Localized time format
tztime local {
#format = "%Y-%m-%d %H:%M:%S"
format = "%a %d. %b %Y %H:%M"
}
load {
format = "L: %1min"
}
</code></pre>
<h2 id="Configure_a_notification_daemon">Configure a notification daemon</h2>
<p>I'm really used to getting notifications by my chat programs (XMPP, IRC,
Signal), and I don't want to dismiss this. So I installed dunst and
configured sway to auto-start it (see above). That's it, it worked
instantly. Well, that was easy :)</p>
<h2 id="Preserve_working_directory_in_new_terminal_instances">Preserve working directory in new terminal instances</h2>
<p>One thing that really annoyed me after switching to sway was, that the
working directory wasn't preserved when spawning new terminal instances.
I often open five or more terminal instances in parallel when working on
a complex project, and I'm very used to just open a new terminal and
continue working in the same directory there immediately.</p>
<p>So I was really eager to find a solution here. Turned out that it's not
that easy and needs a bit of dirty scripting, but I found a solution (with
help from some nice folks in #sway on Freenode).</p>
<p>First some words about the problem: spawning a new terminal in sway
doesn't use whatever sophisticated means to spawn new instances of the
same terminal process. Instead, it just spawns a fresh process of your
favourite terminal emulator. While I really like tilix and used it as a
tiling terminal emulator, I no longer want to use it's tiling features
when I now have a tiling <em>window manager</em>. I'll stick for tilix for now
as I like its look and feel, though.</p>
<p>So if the new terminal emulator process doesn't know about the working
directory of your former terminal, what to do about it?</p>
<p>The solution: Luckily, it's possible to identify the PID of your focused
window in sway using <code>swaymsg -t get_tree</code>. In case that the focused
window is a terminal emulator, it's parent ID should be your shell. And
the shells <code>PWD</code> can easily be determined by reading the symlink
<code>/proc/$PID/cwd</code>.</p>
<p>So let's put this in a wrapper script under
<code>~/.config/sway/scripts/tilix-wrapper.sh</code>:</p>
<div class="highlight-sh"><pre class="hl"><span class="hl slc">#!/bin/sh</span>
<span class="hl slc"># Small script that tries to determine the PWD of the focused terminal</span>
<span class="hl slc"># (in sway tiling window manager) and pass it to the newly spawned one.</span>
TERMINAL_CMD<span class="hl opt">=</span><span class="hl str">"tilix --new-process"</span>
FOCUSED_PID<span class="hl opt">=</span><span class="hl str">""</span>
<span class="hl kwa">if</span> <span class="hl opt">[ !</span> <span class="hl kwb">type</span> jq <span class="hl num">2</span><span class="hl opt">>/</span>dev<span class="hl opt">/</span>null <span class="hl opt">];</span> <span class="hl kwa">then</span>
<span class="hl kwb">echo</span> <span class="hl str">"ERROR: jq not installed"</span> <span class="hl opt">>&</span><span class="hl num">2</span>
<span class="hl kwa">else</span>
FOCUSED_PID<span class="hl opt">=</span><span class="hl str">"$(swaymsg -t get_tree | jq '.. | select(.type?) |</span>
<span class="hl str"> select(.type=="</span>con<span class="hl str">") | select(.focused==true).pid')"</span>
<span class="hl kwa">fi</span>
FOCUSED_PWD<span class="hl opt">=</span><span class="hl str">""</span>
<span class="hl slc"># Check if $FOCUSED_PID is an integer</span>
<span class="hl kwa">if</span> <span class="hl opt">[</span> <span class="hl str">"</span><span class="hl ipl">$FOCUSED_PID</span><span class="hl str">"</span> <span class="hl opt">-</span>eq <span class="hl str">"</span><span class="hl ipl">$FOCUSED_PID</span><span class="hl str">"</span> <span class="hl num">2</span><span class="hl opt">>/</span>dev<span class="hl opt">/</span>null <span class="hl opt">];</span> <span class="hl kwa">then</span>
FOCUSED_PPID<span class="hl opt">=</span><span class="hl str">"$(ps -o pid= --ppid "</span><span class="hl kwd">$FOCUSED_PID</span><span class="hl str">" | awk '{print</span> <span class="hl ipl">$1</span><span class="hl str">}')"</span>
<span class="hl kwa">if</span> <span class="hl opt">[</span> <span class="hl str">"</span><span class="hl ipl">$FOCUSED_PPID</span><span class="hl str">"</span> <span class="hl opt">-</span>eq <span class="hl str">"</span><span class="hl ipl">$FOCUSED_PPID</span><span class="hl str">"</span> <span class="hl num">2</span><span class="hl opt">>/</span>dev<span class="hl opt">/</span>null <span class="hl opt">];</span> <span class="hl kwa">then</span>
FOCUSED_PWD<span class="hl opt">=</span><span class="hl str">"$(readlink "</span><span class="hl opt">/</span>proc<span class="hl opt">/</span><span class="hl kwd">$FOCUSED_PPID</span><span class="hl opt">/</span>cwd<span class="hl str">")"</span>
<span class="hl kwa">fi</span>
<span class="hl kwa">fi</span>
<span class="hl slc"># Spawn terminal in background</span>
<span class="hl kwa">if</span> <span class="hl opt">[ -</span>d <span class="hl str">"</span><span class="hl ipl">$FOCUSED_PWD</span><span class="hl str">"</span> <span class="hl opt">];</span> <span class="hl kwa">then</span>
<span class="hl kwd">$TERMINAL_CMD</span> <span class="hl opt">--</span>working-directory<span class="hl opt">=</span><span class="hl str">"</span><span class="hl ipl">$FOCUSED_PWD</span><span class="hl str">"</span> $@ <span class="hl opt">&</span>
<span class="hl kwa">else</span>
<span class="hl kwd">$TERMINAL_CMD</span> $@ <span class="hl opt">&</span>
<span class="hl kwa">fi</span>
</pre></div>
<p>Finally, we have to set the script as <code>$term</code> in sways config (see
above). Yay, now I've a solution to preserve my working directory when
spawning new terminals!</p>
<h2 id="Use_gnome-keyring_as_SSH_agent_with_sway">Use gnome-keyring as SSH agent with sway</h2>
<p>Another super annoying thing was that my SSH agent no longer worked with
sway, mostly because I used gnome-keyring before and it wasn't spawned
automatically when starting sway. So let's change that. I found it a bit
complicated to get this working as docs on the internet said a lot of
different things, but in the end, the following worked.</p>
<p>Since I still use gdm3 as desktop manager, gnome-keyring-daemon is started
automatically during login. So the only thing that's missing is to initalize
the gnome-keyring-daemon when starting a terminal. To do so, add the following
to <code>~/.profile</code> (in order to only do it on a login shell):</p>
<div class="highlight-sh"><pre class="hl"><span class="hl slc"># Connect to and initalize gnome-keyring-daemon when in sway session</span>
<span class="hl kwa">if</span> <span class="hl opt">[</span> <span class="hl str">"</span><span class="hl ipl">$DESKTOP_SESSION</span><span class="hl str">"</span> <span class="hl opt">=</span> <span class="hl str">"sway"</span> <span class="hl opt">];</span> <span class="hl kwa">then</span>
<span class="hl kwb">export</span> $<span class="hl opt">(</span>gnome-keyring-daemon <span class="hl opt">--</span>start<span class="hl opt">)</span>
<span class="hl kwa">fi</span>
</pre></div>
<p></p>
<h2 id="What.27s_missing">What's missing</h2>
<ul>
<li>I want to start profanity (XMPP client) and irssi (IRC client) automatically
in workspace 3, but so far I failed to find a working filter for sways
<code>assign</code> feature to identify tilix instances with profanity/irssi (in order
to automatically assign those terminals to workspace 3).</li>
<li>I miss the redshift feature of gnome 3. <a href="http://jonls.dk/redshift/">redshift</a>
itself doesn't support wayland yet. There's a <a href="https://github.com/minus7/redshift/commits/wayland">fork with wayland
support</a>, but I didn't
find time to look into it yet.</li>
<li>I'll probably switch from i3status to
<a href="https://github.com/ultrabug/py3status">py3status</a> soon as it's list of
modules looks really promising.</li>
</ul>
debian lts report 2019.10https://blog.freesources.org//posts/2019/10/debian_lts_report_2019.10/2019-10-29T14:47:03Z2019-10-29T14:47:03Z
<h1><em>Debian LTS</em> report for October 2019</h1>
<p>This month I was allocated 0 hours and carried over 14.5 hours from August.
Unfortunately, once again I didn't find time to work on LTS issues. Since
I expect it to stay that way for a few more months, I set the limit of hours
that I get allocated to 0 last month already. I'll give back the remaining
14.5 hours and continue with LTS work once I again have some spare cycles
to do so.</p>
<h2 id="Links">Links</h2>
<ul>
<li><a href="https://wiki.debian.org/LTS">Debian Wiki: Debian Long Term Support</a></li>
<li><a href="https://www.freexian.com/services/debian-lts.html">Freexian: Debian Long Term Support</a></li>
</ul>
debian lts report 2019.09https://blog.freesources.org//posts/2019/10/debian_lts_report_2019.09/2019-10-08T14:34:42Z2019-10-08T14:34:42Z
<h1><em>Debian LTS</em> report for September 2019</h1>
<p>This month I was allocated 10 hours and carried over 9.5 hours from August.
Unfortunately, again I didn't find much time to work on LTS issues, partially
because I was travelling. I spent 5 hours on the task listed below. That
means that I carry over 14.5 hours to October.</p>
<ul>
<li>Issued <a href="https://lists.debian.org/debian-lts-announce/2019/09/msg00013.html">DLA 1921-1</a> for CVE-2019-14513/dnsmasq.</li>
</ul>
<h2 id="Links">Links</h2>
<ul>
<li><a href="https://wiki.debian.org/LTS">Debian Wiki: Debian Long Term Support</a></li>
<li><a href="https://www.freexian.com/services/debian-lts.html">Freexian: Debian Long Term Support</a></li>
</ul>
debian lts report 2019.08https://blog.freesources.org//posts/2019/09/debian_lts_report_2019.08/2019-09-12T13:13:11Z2019-09-12T13:13:11Z
<h1><em>Debian LTS</em> report for August 2019</h1>
<p>This month I was allocated 10 hours. Unfortunately, I didn't find much time to
work on LTS issues, so I only spent 0.5 hours on the task listed below. That
means that I carry over 9.5 hours to September.</p>
<ul>
<li>Triaged CVE-2019-13640/qbittorrent: After digging through the code, it became obvious that qbittorrent 3.1.10 in Debian Jessie is not affected by this vulnerability as the affected code is not present yet.</li>
</ul>
<h2 id="Links">Links</h2>
<ul>
<li><a href="https://wiki.debian.org/LTS">Debian Wiki: Debian Long Term Support</a></li>
<li><a href="https://www.freexian.com/services/debian-lts.html">Freexian: Debian Long Term Support</a></li>
</ul>
debian lts report 2019.07https://blog.freesources.org//posts/2019/08/debian_lts_report_2019.07/2019-08-06T10:17:04Z2019-08-03T15:29:23Z
<h1><em>Debian LTS</em> report for July 2019</h1>
<p>This month I was allocated 17 hours. I also had 2 hours left over from Juney,
which makes a total of 19 hours. I spent all of them on the following tasks/
issues.</p>
<ul>
<li><a href="https://lists.debian.org/debian-lts-announce/2019/07/msg00002.html">DLA-1843-1</a>: Fixed CVE-2019-10162 and CVE-2019-10163 in pdns.</li>
<li><a href="https://lists.debian.org/debian-lts-announce/2019/07/msg00011.html">DLA-1852-1</a>: Fixed CVE-2019-9948 in python3.4. Also found, debugged and fixed several further regressions in the former CVE-2019-9740 patches.</li>
<li>Improved testing of LTS uploads: We had some internal discussion in the Debian LTS team on how to improve the overall quality of LTS security uploads by doing more (semi-)automated testing of the packages before uploading them to jessie-security. I <a href="https://lists.debian.org/debian-lts/2019/07/msg00015.html">tried to summarize</a> the internal discussion, bringing it to the public debian-lts mailinglist. I also did a lot of testing and worked on Jessie support in <a href="https://salsa.debian.org/salsa-ci-team/">Salsa-CI</a>. Now that <a href="https://salsa.debian.org/salsa-ci-team/images/merge_requests/74">salsa-ci-team/images MR !74</a> and <a href="https://salsa.debian.org/ci-team/debci/merge_requests/89">ci-team/debci MR !89</a> got merged, we only have to wait for a new debci release in order to enable autopkgtest Jessie support in Salsa-CI. Afterwards, we can use the Salsa-CI pipeline for (semi-)automatic testing of packages targeted at jessie-security.</li>
</ul>
<h2 id="Links">Links</h2>
<ul>
<li><a href="https://wiki.debian.org/LTS">Debian Wiki: Debian Long Term Support</a></li>
<li><a href="https://www.freexian.com/services/debian-lts.html">Freexian: Debian Long Term Support</a></li>
</ul>
debian lts report 2019.06https://blog.freesources.org//posts/2019/07/debian_lts_report_2019.06/2019-07-01T12:59:09Z2019-07-01T12:59:09Z
<h1><em>Debian LTS</em> report for June 2019</h1>
<p>This month I was allocated 17 hours. I also had 1.75 hours left over from May,
which makes a total of 18.75 hours. I spent 16.75h of them on the following
issues, which means I again carry over 2h to the next month.</p>
<ul>
<li><a href="https://lists.debian.org/debian-lts-announce/2019/06/msg00003.html">DLA 1817-1</a>: Uninitialized read in XBM support of libgd2. Related CVE: CVE-2019-11038.</li>
<li>Work on sqlite3 security update: Spent quite some time on working on two CVEs (CVE-2019-8457 and CVE-2019-5827) that are not easy to fix. <a href="https://lists.debian.org/debian-lts/2019/06/msg00013.html">Suggested to ignore CVE-2019-8457</a> and <a href="https://salsa.debian.org/security-tracker-team/security-tracker/commit/1264caea292378531bf7447251efcf1be93d5a0d">prepared packages that contain a (likely incomplete) fix for CVE-2019-5827</a>.</li>
<li><a href="https://lists.debian.org/debian-lts-announce/2019/06/msg00025.html">DLA 1837-1</a>: Several vulnerabilities in the rdesktop RDP client.</li>
<li><a href="https://lists.debian.org/debian-lts-announce/2019/07/msg00000.html">DLA 1837-2</a>: Regression update for the 1.8.6-0+deb8u1 rdesktop upload.</li>
</ul>
<h2 id="Links">Links</h2>
<ul>
<li><a href="https://wiki.debian.org/LTS">Debian Wiki: Debian Long Term Support</a></li>
<li><a href="https://www.freexian.com/services/debian-lts.html">Freexian: Debian Long Term Support</a></li>
</ul>
debian lts report 2019.05https://blog.freesources.org//posts/2019/06/debian_lts_report_2019.05/2019-06-04T17:24:31Z2019-06-04T17:24:31Z
<h1><em>Debian LTS</em> report for May 2019</h1>
<p>This month I was allocated 17 hours. I spent 15.25 hours on the following
issues:</p>
<ul>
<li><a href="https://lists.debian.org/debian-lts-announce/2019/04/msg00027.html">DLA 1766-1</a>: OpenPGP signature spoofing in evolution. On this issue I actually spent way more time than expected during April. I took over some of the remaining hours to May.</li>
<li><a href="https://lists.debian.org/debian-lts-announce/2019/05/msg00007.html">DLA 1778-1</a>: Several vulnerabilities in symfony, a PHP web application framework.</li>
<li><a href="https://lists.debian.org/debian-lts-announce/2019/05/msg00029.html">DLA 1791-1</a>: Several vulnerabilities in drupal7, a PHP web site platform.</li>
</ul>
<h2 id="Links">Links</h2>
<ul>
<li><a href="https://wiki.debian.org/LTS">Debian Wiki: Debian Long Term Support</a></li>
<li><a href="https://www.freexian.com/services/debian-lts.html">Freexian: Debian Long Term Support</a></li>
</ul>
debian lts report 2019.04https://blog.freesources.org//posts/2019/04/debian_lts_report_2019.04/2019-04-26T21:20:47Z2019-04-26T21:20:47Z
<h1><em>Debian LTS</em> report for April 2019</h1>
<p>After a longer break (~two years) I again took part in the funded Debian LTS
project in April 2019.</p>
<p>I was allocated 14 hours and spent all of them (and even a bit more) on the
following two issues:</p>
<ul>
<li><a href="https://lists.debian.org/debian-lts-announce/2019/04/msg00008.html">DLA 1748-1</a>: Several security fixes for apache2</li>
<li><a href="https://lists.debian.org/debian-lts-announce/2019/04/msg00027.html">DLA 1766-1</a>: OpenPGP signature spoofing in evolution</li>
</ul>
<h2 id="Links">Links</h2>
<ul>
<li><a href="https://wiki.debian.org/LTS">Debian Wiki: Debian Long Term Support</a></li>
<li><a href="https://www.freexian.com/services/debian-lts.html">Freexian: Debian Long Term Support</a></li>
</ul>
debian cryptsetup sprint reporthttps://blog.freesources.org//posts/2018/06/debian_cryptsetup_sprint_report/2018-06-27T13:40:36Z2018-06-26T14:26:42Z
<h1 id="Cryptsetup_sprint_report">Cryptsetup sprint report</h1>
<p>The Cryptsetup team – consisting of Guilhem and Jonas – met on June 15 to 17
in order to work on the Debian cryptsetup packages. We ended up working
three days (and nights) on the packages, refactored the whole initramfs
integration, the SysVinit init scripts and the package build process and
discussed numerous potential improvements as well as new features. The whole
sprint was great fun and we enjoyed a lot sitting next to each other, being
able to discuss design questions and implementation details in person
instead of using clunky internet communication means. Besides, we had very
nice and interesting chats, contacted other Debian folks from the Frankfurt
area and met with jfs on Friday evening.</p>
<h2 id="Splitting_cryptsetup_into_cryptsetup-run_and_cryptsetup-initramfs">Splitting cryptsetup into cryptsetup-run and cryptsetup-initramfs</h2>
<p>First we split the cryptsetup initramfs integration into a separate package
<code>cryptsetup-initramfs</code>. The package that contains other Debian specific
features like SysVinit scripts, keyscripts, etc. now is called
<code>cryptsetup-run</code> and <code>cryptsetup</code> itself is a mere metapackage depending on
both split off packages. So from now on, people can install <code>cryptsetup-run</code>
if they don't need the cryptsetup initramfs integration. Once Buster is
released we intend to rename <code>cryptsetup-run</code> to <code>cryptsetup</code>, which then
will no longer have a strict dependency on <code>cryptsetup-initramfs</code>. This
transition over two releases is necessary to avoid unexpected breakage on
(dist-)upgrades. Meanwhile <code>cryptsetup-initramfs</code> ships a hook that upon
generation of a new initramfs image detects which devices need to be
unlocked early in the boot process and, in case it didn't find any, suggests
the user to remove the package.</p>
<p>The package split allows us to define more fine-grained dependencies: since
there are valid use case for wanting the cryptsetup binaries scripts but not
the initramfs integration (in particular, on systems without encrypted root
device), <code>cryptsetup</code> ≤2:2.0.2-1 was merely recommending <code>initramfs-tools</code>
and <code>busybox</code>, while <code>cryptsetup-initramfs</code> now has hard dependencies on
these packages.</p>
<p>We also updated the packages to latest upstream release and uploaded
2:2.0.3-1 on Friday shortly before 15:00 UTC. Due to the cryptsetup →
cryptsetup-{run,initramfs} package split we hit the NEW queue, and it was
manually approved by an ftpmaster… a mere 2h later. Kudos to them! That
allowed us to continue with subsequent uploads during the following days,
which was beyond our expectations for this sprint :-)</p>
<h2 id="Extensive_refactoring_work">Extensive refactoring work</h2>
<p>Afterwards we started working on and merging some heavy refactoring commits
that touched almost all parts of the packages. First was a refactoring of
the whole cryptsetup initramfs implementation that downsized both the
cryptroot hook and script dramatically (less than half the size they were
before). The logic to detect crypto disks was changed from parsing
/etc/fstab to /proc/mounts and now the sysfs(5) block hierarchy is used to
detect dm-crypt device dependencies. A lot of code duplication between the
initramfs script and the SysVinit init script was removed by outsourcing
common functions into a shared shell functions include file that is sourced
by initramfs and SysVinit scripts. To complete the package refactoring, we
also overhauled the build process by migrating it to the latest Debhelper 11
style. <code>debian/rules</code> as well was downsized to less than half the size and
as an extra benefit we now run the upstream build-time testsuite during the
package build process.</p>
<p>Some git statistics speak more than a thousand words:</p>
<div class="highlight-bash"><pre class="hl">$ git <span class="hl opt">--</span>no-pager <span class="hl kwc">diff</span> <span class="hl opt">--</span>ignore-space-change <span class="hl opt">--</span>shortstat debian<span class="hl opt">/</span><span class="hl num">2</span><span class="hl opt">%</span><span class="hl num">2.0.2</span><span class="hl opt">-</span><span class="hl num">1</span>..debian<span class="hl opt">/</span><span class="hl num">2</span><span class="hl opt">%</span><span class="hl num">2.0.3</span><span class="hl opt">-</span><span class="hl num">2</span> <span class="hl opt">--</span> .<span class="hl opt">/</span>debian<span class="hl opt">/</span>
<span class="hl num">92</span> files changed<span class="hl opt">,</span> <span class="hl num">2247</span> insertions<span class="hl opt">(+),</span> <span class="hl num">3180</span> deletions<span class="hl opt">(-)</span>
$ <span class="hl kwc">find</span> .<span class="hl opt">/</span>debian <span class="hl opt">-</span><span class="hl kwb">type</span> f \<span class="hl opt">! -</span>path .<span class="hl opt">/</span>debian<span class="hl opt">/</span>changelog <span class="hl opt">-</span>print0 | <span class="hl kwc">xargs</span> <span class="hl opt">-</span>r0 <span class="hl kwc">cat</span> | <span class="hl kwc">wc</span> <span class="hl opt">-</span>l
<span class="hl num">7342</span>
$ <span class="hl kwc">find</span> .<span class="hl opt">/</span>debian <span class="hl opt">-</span><span class="hl kwb">type</span> f \<span class="hl opt">! -</span>path .<span class="hl opt">/</span>debian<span class="hl opt">/</span>changelog <span class="hl opt">-</span><span class="hl kwb">printf</span> x | <span class="hl kwc">wc</span> <span class="hl opt">-</span>c
<span class="hl num">106</span>
</pre></div>
<h1 id="On_CVE-2016-4484">On CVE-2016-4484</h1>
<p>Since 2:1.7.3-2, our initramfs boot script went to sleep for a full minute
when the number of failed unlocking attempts exceeds the configured value
(<code>tries</code> crypttab(5) option, which defaults to 3). This was added in order
to defeat local brute force attacks, and mitigate one aspect of
<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4484">CVE-2016-4484</a>;
back then Jonas wrote a <a href="https://blog.freesources.org/posts/2016/12/CVE-2016-4484/">blog post to cover that story</a>. Starting with
2:2.0.3-2 we changed this behavior and the script will now sleep for one
second after <em>each</em> unsuccessful unlocking attempt. The new value should
provide better user experience while still offering protection against local
brute force attacks for very fast password hashing functions. The other
aspect mentioned in the security advisory — namely the fact that the initramfs
boot process drops to a root (rescue/debug) shell after the user fails to
unlock the root device too many times — was not addressed at the time, and
still isn't. initramfs-tools has a boot parameter <code>panic=<sec></code> to disable the
debug shell, and while setting this is beyond the scope of cryptsetup, we're
planing to ask the initramfs-tools maintainers to change the default. (Of
course setting <code>panic=<sec></code> alone doesn't gain much, and one would need to
lock down the full boot chain, including BIOS and boot loader.)</p>
<h2 id="New_features_.28work_started.29">New features (work started)</h2>
<p>Apart from the refactoring work we started/continued work on several new features:</p>
<ul>
<li>We started to integrate luksSuspend support into system suspend. The idea
is to luksSuspend all dm-crypt devices before suspending the machine in
order to protect the storage in suspend mode. In theory, this seemed as
simple as creating a minimal chroot in ramfs with the tools required to
unlock (luksResume) the disks after machine resume, running luksSuspend from
that chroot, putting the machine into suspend mode and running <code>luksResume</code>
after it got resumed. Unfortunately it turned out to be way more complicated
due to unpredictable race conditions between <code>luksSuspend</code> and machine
suspend. So we ended up spending quite some time on debugging (and
understanding) the issue. In the end it seems like the final sync() before
machine suspend ( https://lwn.net/Articles/582648/ ) causes races in some
cases as the dm-crypt device to be synced to is already luksSuspended. We
ended up sending a <a href="https://www.saout.de/pipermail/dm-crypt/2018-June/005896.html">request for help to the dm-crypt mailinglist</a> but
unfortunately so far didn't get a helpful response yet.</li>
<li>In order to get internationalization support for the messages and password
prompts in the initramfs scripts, we <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901702">patched gettext and locale support
into initramfs-tools</a>.</li>
<li>We started some preliminary work on adding <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537842">beep support to the cryptsetup
initramfs and sysVinit scripts</a> for better
accessibility support.</li>
</ul>
<p>The above features are not available in the current Debian package yet, but
we hope they will be included in a future release.</p>
<h2 id="Bugs_and_Documentation">Bugs and Documentation</h2>
<p>We also squashed quite some longstanding bugs and improved the crypttab(5)
documentation. In total, we squashed <a href="https://qa.debian.org/data/bts/graphs/c/cryptsetup.png">18 bugs</a> during the sprint,
the oldest one being from June 2013.</p>
<h2 id="On_the_need_for_better_QA">On the need for better QA</h2>
<p>In addition to the many crypttab(5) options we also support a huge variety
of block device stacks, such as LUKS-LVM2-MD combined in all ways one can
possibly imagine. And that's a Debian addition hence something we, the
cryptsetup package maintainers, have to develop and maintain ourselves. The
many possibilities imply corner cases (it's not a surprise that complex or
unusual setups can break in subtle ways) which motivated us to completely
refactor the Debian-specific code, so it becomes easier to maintain.</p>
<p>While our final upload squashed 18 bugs, it also introduced new ones. In
particular 2 rather serious regressions which fell through our tests. We
have thorough tests for the most usual setups, as well as for some complex
stacks we hand-crafted in order to detect corner cases, but this approach
doesn't scale to covering the full spectrum of user setups: even with
minimal sid installations the disk images would just take far too much
space! Ideally we would have a automated test-suite, each test deploying a
new transient sid VM with a particular setup. As the current and past
regressions show, that's a beyond-the-scenes area we should work on. (In
fact that's an effort we started already, but didn't touch during the sprint
due to lack of time.)</p>
<h2 id="More_to_come">More to come</h2>
<p>There's some more things on our list that we didn't find time to work on.
Apart from the unfinished new features we mentioned above, that's mainly the
LUKS nuke feature that <a href="https://www.kali.org/tutorials/nuke-kali-linux-luks/">Kali Linux ships</a> and the <a href="https://github.com/systemd/systemd/pull/3007#issuecomment-214313933">lack of
keyscripts support to crypttab(5) in systemd</a>.</p>
<h2 id="Conclusion">Conclusion</h2>
<p>In our eyes, the sprint was both a great success and great fun. We
definitely want to repeat it anytime soon in order to further work on the
open tasks and further improve the Debian cryptsetup package. There's still
plenty of work to be done. We thank the Debian project and its generous
donors for funding Guilhem's travel expenses.</p>
<p><em>Guilhem and Jonas, June 25th 2018</em></p>