Proton Pass as 1Password alternative?

Published

In the days before Christmas 1Password had a pretty stupid issue which broke syntax highlighting on all sites using PrismJS. As my 1Password subscription also runs out soon, this nudged me to look at alternatives.

I'd love to use a European provider, or perhaps even self-host my own solution, and I can't help but think that that 1Password issue is a symptom of sloppy engineering. And while I don't have specific doubts about 1Password's security standards, it's still sort of concerning that 1Password apparently just dumps random npm.js dependencies in its extension, which has all my credentials. The NPM ecosystem doesn't have a stellar security track record after all.

So I took a look at Proton Pass. Unfortunately it didn't make the cut, and can't (yet) replace 1Password for me. But that's probably just because I've been using 1Password for a long time (I think it's almost ten years by now), and gotten used to many of 1Password's features. Had I started fresh, I'd quite likely kept using Proton Pass, as it's a pretty good password manager, and the rest of the Proton product suite is pretty cool too. I'll likely take another look at Proton Pass in a year or two, and since it's pretty much impossible to find good in-depth technical comparisons of different password managers, I figured I'd keep note of my testing here.

I think I'll also look at self-hosting Bitwarden with vaultwarden, but since that's a bit more effort to set up, I haven't had the time yet. Maybe I'll have another blog post about this soonish.

Read more…

forgejo-runner image with mkosi

Published

Codeberg doesn't have much CI capacity so I bring my own action runners to run workflows in my Codeberg repositories. I use mkosi to build a generic system image containing the runner as well as all dependencies I need for CI, which I can then deploy on any system (e.g. spare laptops at home, hosted cloud VMs, etc.) that uses systemd. This post shows the image definition.

Read more…

Build Arch packages with git sources on OBS

Published

After the infamous xz backdoor incident there's been a general move towards building packages directly from Git sources for the sake of transparency, instead of using upstream provided tarballs.

Now, I like to build my Arch packages on the public openSUSE Build service (OBS) generously sponsored by SUSE, but building packages from Git sources poses a bit of a challenge on OBS: the public instance does not permit network access during builds and requires all sources to be present upfront along with the PKGBUILD. This prevents makepkg from fetching the git sources during build. However, with a small trick we can simply commit a “snapshot” of the source repo along with the PKGBUILD.

Read more…

Simple Secure Boot in Fedora

Published

Fedora doesn't use a proper secure boot setup: It doesn't use unified kernel images and still leaves unsigned initrd files around. Generally, it still seems to consider secure boot support just as means to boot and install on secure-boot locked machines with Microsoft's keys, instead of a proper security tool a user should make use of to really own their own machines.

In this article we'll explore how we can setup secure boot with custom keys. The result works pretty well, and uses no fancy trickery or weird hacks, but is probably still firmly outside of what Fedora supports and will perhaps break with future Fedora releases.

Note: I use Fedora 40 in this article; it may or may not apply to other Fedora 40 versions, both earlier and later. As far as I understand Fedora is actively working on systemd-boot support, UKIs, and secure boot; the whole area is pretty much a moving target and may change a lot in between Fedora releases.

Read more…

Arch Linux rescue image with mkosi

Published

In this post we'll build a small single-file Arch Linux rescue image for EFI systems.

We will end up with a single EFI executable of about 400 MiB (further optimization can get it down to about 200MiB) which embeds a fully-fledged Arch Linux system. We can then put this image on the EFI partition and sign it for secure boot, which gives us a rescue single-file rescue system to boot into in case the main Arch installation does not boot anymore. From that rescue system we can then chroot into the main installation to repair it.

The image will include metadata which enables systemd-boot to automatically discover the image and add it to its menu when we place in /efi/EFI/Linux (the bootloader specification calls these "type 2 entries", see Type #2 EFI Unified Kernel Images).

You can find my personal version of the image built in this post at https://codeberg.org/swsnr/rescue-image.

Read more…

Install Arch with Secure boot, TPM2-based LUKS encryption, and systemd-homed

Published

Update: I no longer use dracut, and the corresponding part of this blog post no longer reflects my setup.

This article describes my Arch Linux setup which combines Secure Boot with custom keys, TPM2-based full disk encryption and systemd-homed into a fully encrypted and authenticated, yet convenient Linux system.

This setup draws inspiration from Authenticated Boot and Disk Encryption on Linux and Unlocking LUKS2 volumes with TPM2, FIDO2, PKCS#11 Security Hardware on systemd 248 by Lennart Poettering.

Read more…

Compose emojis

Published

On Linux you can define custom sequences for the Compose key. You just need to create a ~/.XCompose file and can start to define new sequences for e.g. emojis:

include "%S/en_US.UTF-8/Compose"

<Multi_key> <period> <p> <r> <a> <y> : "🙏"
<Multi_key> <period> <less> <3> <parenright> : "😍"
<Multi_key> <period> <less> <3> <period> : "❤️"
<Multi_key> <period> <less> <3> <asterisk> : "😘"

man 5 Compose documents the format, though Gtk doesn’t seem to support all of it: It doesn’t handle includes apparently, and always seems to include its own hard-coded list of compose sequences.

There is a nice Gist with some sequences.

Read more…

The mysterious disapperance of Docker images

Published

A node hosts a Gitlab runner and a small k3s cluster which runs a few services as regular kubernetes deployments. A CI job pinned to that runner builds Docker images for these services services, updates the image of the corresponding deployments, and starts a few system and acceptance tests. The CI job does not push those images to the in-house registry; to avoid polluting the registry with hundreds of images it just builds locally.

Each test then scales each deployment to zero replicas to effectively stop all services, clears the system’s underlying database, and scales the service deployments back to a small number of replicas sufficient for testing.

The whole thing runs fine until one day the replicas randomly fail to start.

Read more…