Rewriting EXIF tags in JPEGs

Some out-of-camera JPEGs have bad metadata that digiKam doesn’t parse correctly. The problematic photos have the same characteristics:

  1. In the Properties tab, there is no Photograph Properties section, instead digiKam has a digiKam Properties section with the caption set to None.
  2. In the Metadata tab, not metadata is shown under Exif. However, full details are available under Exiftool.

The solution is to rewrite the EXIF tags using exiftool. This fixes the bad metadata and allows digiKam to properly read the photo’s metadata.

exiftool -overwrite_original -all= -tagsfromfile @ -all:all *.JPG

For the files with bad EXIF metadata, the command will report the following warning:

Warning: [minor] Error reading PreviewImage from file - DSC06635.JPG

Setting up WireGuard on Debian

WireGuard is a modern VPN solution, which is much easier to configure than OpenVPN and its likes. In this tutorial, we assume a simple setup where we want to route all clients network traffic through the VPN, exiting through the server.

Server configuration

$ sudo apt install wireguard
$ PRIVATE_KEY=$(wg genkey)

Now we create the configuration file for our tunnel (wg0).

$ cat <<EOF | sudo tee /etc/wireguard/wg0.conf
[Interface]
PrivateKey = $PRIVATE_KEY
Address = 10.8.0.1/24, fd0d:d325:45c0::1/64
ListenPort = 51820
SaveConfig = true

PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
EOF

If you have a firewall, you’ll need to open up UDP port 51820 (or whatever configured as the ListenPort).

Enable IPv4 and IPv6 forwarding, so we can route all the client traffic through the server (and reload sysctl configuration)

$ echo net.ipv4.ip_forward=1 | sudo tee /etc/sysctl.d/40-wireguard.conf
$ echo net.ipv6.conf.all.forwarding=1 | sudo tee -a /etc/sysctl.d/40-wireguard.conf
$ sudo sysctl --system 

Enable and start the WireGuard service:

$ sudo systemctl enable --now wg-quick@wg0.service

Finally, take note of the server public key (it will be a short base64 encoded string):

$ echo $PRIVATE_KEY | wg pubkey

You’ll need it in the next step.

Peer configuration

$ sudo apt install wireguard
$ PRIVATE_KEY=$(wg genkey)
$ PUBLIC_KEY=$(echo $PRIVATE_KEY | wg pubkey)
$ SERVER_PUBLIC_KEY=6TDw+U2WFhkaKUy/xXrCRtuZvB2m2SFN7URZA5AkGis=
$ SERVER_IP=8.8.8.8

Replace the value of SERVER_PUBLIC_KEY with the public key of your server, and SERVER_IP with the correct IP address of your server.

Edit /etc/wireguard/wg0.conf

$ cat <<EOF | sudo tee /etc/wireguard/wg0.conf
[Interface]
PrivateKey = $PRIVATE_KEY
Address = 10.8.0.2/24, fd0d:d325:45c0::2/64

[Peer]
PublicKey = $SERVER_PUBLIC_KEY
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = $SERVER_IP:51820
EOF

Setting AllowedIPs = 0.0.0.0/0, ::/0 will route all traffic through the VPN connection. If you don’t want to do that, edit the configuration file, and set AllowedIPs = 10.8.0.0/24, fd0d:d325:45c0::0/64.

We need to make the server aware of the peer. The following command should be executed on the server.

$ sudo wg set wg0 peer $PUBLIC_KEY allowed-ips 10.8.0.2,fd0d:d325:45c0::2

where PUBLIC_KEY is the value of the client’s public key (stored in the $PUBLIC_KEY environment variable).

The /etc/wireguard/wg0.conf will be updated according and make the added peer configuration persistent due to the SaveConfig = true. The configuration update will take place the next time the WireGuard interface goes down.

You can also import the profile into NetworkManager and easily enable/disable the new interface via GNOME:

$ sudo nmcli connection import type wireguard file /etc/wireguard/wg0.conf

Android Peer

It is also useful to have WireGuard on the phone. WireGuard supports both iOS and Android, and the setup should be similar in both cases. Start by installing WireGuard from the Play Store. The next step is to generate the required configuration. It can be done directly on the phone, or by creating a configuration file on your computer and transferring it, which I find simpler.

$ PRIVATE_KEY=$(wg genkey)
$ PUBLIC_KEY=$(echo $PRIVATE_KEY | wg pubkey)
$ SERVER_PUBLIC_KEY=6TDw+U2WFhkaKUy/xXrCRtuZvB2m2SFN7URZA5AkGis=
$ SERVER_IP=8.8.8.8
$ cat <<EOF > wg0.conf
[Interface]
PrivateKey = $PRIVATE_KEY
Address = 10.8.0.3/24, fd0d:d325:45c0::3/64

[Peer]
PublicKey = $SERVER_PUBLIC_KEY
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = $SERVER_IP:51820
EOF

Again, make the server aware of the client by running the following command on the server:

$ sudo wg set wg0 peer $PUBLIC_KEY allowed-ips 10.8.0.3,fd0d:d325:45c0::3

Transfer the configuration file wg0.conf to the phone and load it using the WireGuard app.

Update 2023-11-30: Added IPv6 configuration.

Connecting to WP2 Enterprise network with EAP-TLS authentication

Recently, I had to connect to a hidden WiFi network with an EAP-TLS authentication. When configured via the NetworkManager UI on Ubuntu, it would work. However, on Debian Unstable running Gnome 42 and on Arch, the same process didn’t work. The problem seems to be an empty configuration line for domain-suffix-match that gets created. To solve it, you can remove the domain-suffix-match using nmcli:

$ nmcli connection modify CorpSSID 802-1x.domain-suffix-match ""

Alternatively, you can configure the WiFi network directly with nmcli without setting the problematic property>:

nmcli connection add type wifi ifname wlp0s20f3 \
  con-name CorpSSID \
  802-11-wireless.ssid CorpSSID \
  802-11-wireless-security.key-mgmt wpa-eap \
  802-1x.eap tls \
  802-1x.identity guyru \
  802-1x.client-cert /absolute/path/wifi-certs/signed-certificate.cer \
  802-1x.private-key /absolute/path/wifi-certs/private.key 

It’s important to have absolute paths to both the client certificate and the private key.

GIO can’t mount SMB

When trying to mount SMB share using gio you might encounter the following error:

$ gio mount smb://ptnas1.cellebrite.local
gio: smb://nas.corp.local/: Location is not mountable

This error might be due to a missing gvfs backend. The smb backend should be located in /usr/share/gvfs/mounts/smb.mount. If it is missing, you should install the gvfs-backends package and it should resolve the mounting issue.

If the mount was successful, but you can’t see it under $XDG_SESSION_DESKTOP/gvfss/, you are probably missing the FUSE server that makes the mounted filesystem available to all applications and not only to GIO aware applications. You can install the FUSE server by installing the gvfs-fuse package. The server will automatically run after reboot. If you want to start the server immediately, you can start it manually:

$ /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs

PipeWire showing only dummy output

After the latest PipeWire upgrade on Debian, sound stopped working for. The bluetooth headset would not connect, and in the output options I had only one device labeled dummy output.

This was caused by a recent upgrade of the pipewire-media-session package to version 0.4.1-3. Debian decided that media-session is deprecated in favor of WirePlumber. As part of the package installation, the /usr/share/pipewire/media-session.d/with-pulseaudio file, signalling media-session it should handle audio, gets removed. As I didn’t have WirePlumber installed, nothing managed the audio configuration. The solution is to recreate the file and restart the relevant PipeWire servcies.

$ sudo touch /usr/share/pipewire/media-session.d/with-pulseaudio 
$ systemctl restart --user pipewire pipewire-media-session pipewire-pulse

Creating FIDO2 SSH keys using ssh-keygen

$ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk
  • -t ecdsa-sk specifies the key type to generate. Alternatively, you can generate Ed25519 keys using -t ed25519-sk.
  • -f ~/.ssh/id_ecdsa_sk specify the output path for the newly generated key.

You can provide a passphrase for your key if you would like to do so. Unlike normal ssh keys, the private key is not that sensitive, as it is useless without the physical security key itself.

ed25519-sk vs ecdsa-sk

Newer YubiKeys (firmware >=5.2.3) and some other FIDO2 keys, support Ed25519 keys. Ed25519 have some advantages over the common ECDSA keys in several aspects:

  • Ed25519 is based on the Curve25519 vs NIST P-256 used for ecdsa-sk. Curve25519 is generally regarded as faster and safer than NIST P-256, see SafeCurves. Furthermore, the underlying signature algorithm (Schnorr vs DSA) is slightly faster for Ed25519
  • EdDSA in general, and Ed25519 in particular, uses deterministic nonce versus random nonce used by ECDSA. This means that ECDSA is prune to catastrophic entropy failure (see the famous fail0verflow PS3 hack as an example). Assuming your key has access to high entropy randomness, that shouldn’t be a problem. However, that assumption might turn out false, like in the case of the reduced initial randomness in the Yubikey FIPS Series.

In the bottom line, if you have access to a key that supports ed25519-sk then it’s preferable to use it. If you don’t, that’s not something to worry about to much. There are probably weaker points in your threat model anyway.

If your FIDO2 key doesn’t support ed25519-sk you will get the following error when trying to generate a key:

Key enrollment failed: requested feature not supported

Moving keys to a new computer

If you want to use the keys on a new computer, you will have to copy over the private key file that you generated. That will normally be ~/.ssh/id_ecdsa_sk or ~/.ssh/id_ed25519_sk, depending on the type of key you generated.

Alternatively, you can generate resident keys which are completely stored on the YubiKey. To generate resident keys, append the -O resident to your ssh-keygen command. Example:

$ ssh-keygen -t ecdsa-sk -O resident

To import the keys to a new device, use the -K option:

$ ssh-keygen -K

This will download all the keys (public and private) from the YubiKey to the current directory. There is no need to manually transfer any key files.

YubiKey Series 5 devices can hold up to 25 resident keys.

Setting SPF Record

SPF allows one to specify which SMTP servers can send emails on behalf of a domain. The SPF record is defined as a DNS TXT record and specifies the list of allowed senders for the domain.

"v=spf1 a ip4:134.209.224.112 include:_spf.mx.cloudflare.net include:_spf.google.com ~all"
  • v=spf1 specifies that this TXT record is indeed an SPF record.
  • a include the IP addresses of the domain, as returned by the A or AAAA records. This is required to let your own server send emails.
  • ip4:134.209.224.112 allows a specific server by IP address to send emails. You can also use netmasks (ie /20) to allow ranges.
  • include:_spf.mx.cloudflare.net allows Cloudflare Email Routing to forward emails for your domain.
  • include:_spf.google.com allow sending emails via Google Workspace/Gmail.
  • ~all This marks every other server not listed so far as insecure/spam, but the email will be accepted. This can be replaced by -all which would tell the recipient to reject emails from unauthorized servers.

References

List obsolete packages using Apt

Apt 2.0 introduced a new feature allowing to use smarter patterns when listing packages. This allows to list all obsolete packages using the specifier ?obsolete or the shorthand ~o.

$ apt list ?obsolete

It will list all locally installed packages and packages.

You can also list all packages not provided by Debian (it will also catch packages once provided by Debian but since then remove from the repositories):

$ apt list --installed "?not(?origin(debian))"