Kowa's Blog

Short-lived certificates: a nuisance or an automation opportunity?

Sun, 31 May 2026 00:00:00 GMT

(Sticker by Puzzoz)

The advent of the World Wide Web, based on the HTTP (HyperText Transfer Protocol) protocol, introduced an incredible ability to connect information, but it did so by leaving a fundamental vulnerability: the lack of intrinsic security.

The traffic exchanged between a user and a server traveled in plaintext, a flaw that opened the door to a multitude of attacks. Malicious actors, using relatively simple tools, could intercept and read the entire conversation. Some will shudder recalling tools like Firesheep, which exploited this insecurity to make side-jacking trivial. This allowed the theft of active sessions from PCs connected to the same Wi-Fi network, granting access to social profiles or services as if the attacker were the legitimate user.

But the risks went far beyond simple interception: the lack of identity verification allowed attackers to impersonate a legitimate server (man-in-the-middle attacks) with the goal of stealing sensitive credentials, distributing malware, or committing fraud.

Faced with such a scenario, the need to protect communications and guarantee the authenticity of the parties involved strongly emerged. It was essential to ensure that the website the user was interacting with was actually the declared one and that the communication was incomprehensible to prying eyes. The solution to this dual problem was the evolution of HTTP into the HTTPS (HTTP Secure) protocol, achieved through the adoption and extension of the X.509 digital certificate system. These certificates, issued by trusted third-party organizations called Certification Authorities (CAs), play a crucial role.

Digital certificates fulfill two central and complementary functions for the security of web communications. The first function consists of enabling communication encryption, typically through protocols like SSL/TLS, which is an essential step to ensure the confidentiality and integrity of the data exchanged between parties.

In parallel, certificates are fundamental for validation and the fight against impersonation. This occurs because the issuance of a certificate by a Certification Authority (CA) is subject to the verification of domain ownership by the applicant. This mechanism ensures that the user's browser, by trusting the CA, obtains the necessary proof to validate that the server it is interacting with is actually who it claims to be, thereby preventing fraud attempts or man-in-the-middle attacks.

The introduction of this mechanism marked a turning point for web security.

However, the mass adoption of HTTPS was not immediate. For years, many websites(particularly personal blogs, small artisan sites, or less "critical" portals) continued to operate on insecure HTTP.

The reasons were often economic and logistical: certificates, although not prohibitively expensive (around ten euros a year or slightly more), still represented a fixed expense that was not always perceived as indispensable. Consequently, unprotected connections were frequently used, or, in an attempt to save money, self-signed certificates were employed. The latter, while guaranteeing encryption, were not issued by a recognized CA. As a result, browsers considered them untrusted, forcing users to manually confirm a security exception. This created a sub-optimal user experience and, above all, sent an ambiguous signal regarding security.

In the realm of home banking and e-commerce, however, maximum reliability is required. For a period of time, Extended Validation (EV) certificates were used in an attempt to further improve the certainty of being connected to the right site. This type of certificate could only be obtained through the verification of company documentation and involved a high cost, limiting its use to entities with specific needs. In return, users with this certificate saw the company name on a green background in the browser bar alongside the URL. We say "saw" in the past tense because this option was removed. It proved largely ineffective in protecting users, as certification authorities often failed to conduct truly in-depth checks.

The epochal turning point in the landscape of web security and certificate management arrived in 2016 with the public launch of Let's Encrypt.

This initiative, promoted by prominent organizations such as the Electronic Frontier Foundation (EFF), the Mozilla Foundation, and Cisco Systems, introduced a revolutionary concept: a fully automated certification authority (CA) that offers free X.509 certificates.

The impact of Let's Encrypt was immediately perceived as extremely positive, particularly by system engineers and server administrators.

Let's Encrypt my beloved! (Sticker by Puzzoz)

The keystone was the introduction of tools like certbot, a software client that automates the entire lifecycle of the certificate. After a single initial configuration on their web servers, which could include setting up domain challenges like HTTP-01 or DNS-01 for domain ownership verification, administrators could finally eliminate the worry associated with renewals.

This change not only drastically reduced operational costs and the probability of service interruptions due to expired certificates, but it also contributed significantly to the global increase in HTTPS adoption, pushing the web towards a higher baseline level of security. The automation provided by Let's Encrypt and certbot transformed a manual, repetitive, and error-prone task into a process managed in the background, allowing system engineers to focus on higher value-added activities. The adoption of certificates on the web was further accelerated by the introduction of the same mechanism on the Cloudflare CDN. The latter made it possible to add encryption between the edge and the user's device via the "Flexible" configuration. Although not the most secure option, it offers security benefits for the end user without requiring server-side configurations, making it particularly useful for hosting providers that had not yet integrated Let's Encrypt.

With this absolute proliferation of certificates, especially those distributed through automated systems, a radical change arrived from the most popular browsers regarding how they communicate a website's reliability to the user. A website using a certificate is no longer merely considered "secure"; rather, sites without HTTPS are now deemed downright "dangerous", displaying risk warnings and banners to the user before connection.

Another disruptive novelty brought about by this new paradigm is the drastic reduction in the maximum lifespan of an issuable certificate. It began in 2015 by fixing the duration at three years, dropping to two in 2018, and finally to just one in 2020 to stimulate a more frequent rotation of keys.

The widespread diffusion of certificates, particularly those issued automatically, triggered an epochal shift in how browsers communicate a website's reliability to users. Today, the use of a certificate is no longer the distinguishing feature of a "secure" site; conversely, the lack of HTTPS makes sites "dangerous", pushing browsers to display warnings and banners about risks before establishing a connection.

Today, we are in a phase of further change. Authorities and browsers are pushing for even shorter durations to force the adoption of automation; in the future, the maximum duration of certificates will shrink even further. Here is what is expected for the coming years: the limit will drop to 200 days by March 15, 2026, to 100 days by March 15, 2027, and the maximum duration will be only 47 days by March 15, 2029. The goal is to make certificates "disposable". If a certificate lasts only a few weeks, a hacker who steals its key has very little time to exploit it. Furthermore, if a vulnerability is discovered in an encryption algorithm, the entire web can migrate to a new one in less than two months simply by waiting for the natural renewal of certificates.

Date	Maximum Certificate Lifespan	Technical Verification
2015	3 years	Capped at 39 months
2018	2 years	Capped at 825 days
2020	1 year	Capped at 398 days by Apple/Google
March 15, 2026	200 days	Phase 1 of the new CA/B mandate
March 15, 2027	100 days	Phase 2 of the new CA/B mandate
March 15, 2029	47 days	Phase 3 of the new CA/B mandate

Certificate lifespan roadmap

The adoption of an automated system for the renewal and management of digital certificates is no longer a simple 'commodity' or a choice of convenience, but a mandatory operational and security constraint for any organization. In the current cybersecurity landscape, where certificate expiration is increasingly brief (short-term certificates, or short-lived certificates), manually installing a certificate or relying on manual processes for its renewal now constitutes a significant technical debt.

The transition to a short-lived certificates policy should not be seen as a bureaucratic burden for IT, but as a catalyst for indispensable infrastructural modernization. The goal of the Certification Authorities is clear: they want to reduce the risk in the event that security keys are compromised, and they also want to accelerate the adoption of more robust cryptographic standards. This, however, makes it impossible to manage the entire process manually.

In modern container-based architectures, where services are dynamically created, deleted, and scaled, automating the certificate lifecycle (i.e., issuance, renewal, distribution, and revocation) is not just a best practice, but a fundamental requirement to ensure compliance and service continuity. Platforms that manage large-scale workloads, such as Kubernetes, need integrated tools to manage identity and cryptography. In this context, solutions like Cert Manager become essential. Integrated on Kubernetes, Cert Manager automates communication with Certification Authorities (such as Let's Encrypt or internal CAs), ensuring that each service (Pod, Ingress, or Route) has a valid certificate that is automatically renewed. This eliminates the possibility of service interruptions due to unexpected expirations.

For traditional systems or hybrid infrastructures that do not use Kubernetes-native platforms, automation can be managed through Configuration Management tools like Ansible. In this scenario, Ansible acts as an orchestrator, deploying and configuring the Certbot utility on individual operating systems (web servers, load balancers, etc.). Using configuration files called playbooks, Ansible can ensure that Certbot is installed and configured correctly, execute Certbot to obtain and renew certificates from CAs like Let's Encrypt, distribute the obtained certificates to the correct services (for example, by configuring Nginx or Apache), and, finally, restart or reload the services to apply the new certificates. This method ensures that even older or non-containerized servers can benefit from the security offered by short-term certificates without requiring human intervention for each renewal.

The adoption of short-term certificates forces organizations to definitively abandon the era of manual renewals. Investing in automation tools, whether it is Cert Manager on Kubernetes or orchestrating Certbot via Ansible, is not an expense, but a net gain in terms of security, operational efficiency, and the reduction of so-called technical debt. In this way, what seemed like a "nuisance" turns into a real opportunity to improve the digital infrastructure.

Static web hosting on Kubernetes with OCI images as volumes

Mon, 18 May 2026 00:00:00 GMT

Sticker by @puzzoz

Introduced in Kubernetes 1.31, promoted to beta in 1.33 and entered in stable with Kubernetes 1.36, we can use OCI images as volumes for containers. They are now a possible storage choice among Persistent Volume Claims, empty directory, pod metadata, Config Maps and Secrets. This option can take advantage of the existing tooling and CI/CD already present to deliver an archive containing any kind of data.

OCI images, the evolution of Docker images, have become a new way to deliver artifacts, to the point that they are also used by some Linux distributions to build and ship system updates.

By leveraging OCI images with this new feature we can improve our static website development and deployment by decoupling webserver image and static website build, simplifying application versioning and making quicker web server patching without rebuilding everything.

Creating website images, the old way

Until now, the standard way to host a website on Kubernetes was, after eventually building the site assets, to extend a web server image (in this case Nginx) with the files of the static website copied in the www root folder. An example Containerfile for building my website with this approach could be the following:

FROM registry.access.redhat.com/ubi10/nodejs-24-minimal:10.1 as build
WORKDIR $HOME
ADD package*.json ./
RUN --mount=type=cache,mode=0777,uid=1001,gid=0,target=node_modules \
    npm ci --only=production
ADD . .
RUN --mount=type=cache,mode=0777,uid=1001,gid=0,target=node_modules \
    --mount=type=cache,mode=0777,uid=1001,gid=0,target=public \
    --mount=type=cache,mode=0777,uid=1001,gid=0,target=.cache \
    npm run build

FROM registry.access.redhat.com/ubi10/nginx-126:10.1
CMD nginx -g "daemon off;"
COPY --from=build $HOME/public $HOME

With the new approach, we can replace the Nginx base image with scratch that is an empty base image, as opposed to a distro or runtime base image developer use in a typical scenario.

FROM registry.access.redhat.com/ubi10/nodejs-24-minimal:10.1 as build
WORKDIR $HOME
ADD package*.json ./
RUN --mount=type=cache,mode=0777,uid=1001,gid=0,target=node_modules \
    npm ci --only=production
ADD . .
RUN --mount=type=cache,mode=0777,uid=1001,gid=0,target=node_modules \
    --mount=type=cache,mode=0777,uid=1001,gid=0,target=.cache \
    npm run build

FROM scratch
COPY --from=build /opt/app-root/src/public /

Let's see with podman images what are the differences between the two images:

REPOSITORY                       TAG          IMAGE ID      CREATED         SIZE
ghcr.io/kowalski7cc/website      scratch      f1e26dd79993  13 seconds ago  140 MB
ghcr.io/kowalski7cc/website      nginx        a108d5cebad5  4 minutes ago   428 MB

We can see the image kowalski7cc/website:scratch is taking significantly less space than the kowalski7cc/website:nginx image without changing anything about the website!

At this point we can push our smaller image and prepare a Kubernetes deployment to it.

The basic syntax to use a OCI image as a volume is the following:

...
spec:
  containers:
  - volumeMounts:
    - name: volume
      mountPath: /volume
    ...
  volumes:
  - name: volume
    image:
      reference: $VOLUME_IMAGE
      pullPolicy: IfNotPresent
...

So we can create a deployment like this example for an Nginx container, where we mount the ghcr.io/kowalski7cc/website:scratch image under the /opt/app-root/src, which is the default path used by Red Hat's Nginx image named registry.access.redhat.com/ubi10/nginx-126:10.1. With this image, it is required to override the default image command with ["nginx", "-g", "daemon off;"], otherwise Nginx would not start and instead we would find OCP s2i stub script.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: website
  name: website
  namespace: website
spec:
  selector:
    matchLabels:
      app: website
  template:
    metadata:
      labels:
        app: website
      namespace: website
    spec:
      containers:
        - image: registry.access.redhat.com/ubi10/nginx-126:10.1
          imagePullPolicy: IfNotPresent
          name: website
          command:
            - nginx
            - -g
            - daemon off;
          ports:
            - containerPort: 8080
              name: http
              protocol: TCP
          volumeMounts:
            - mountPath: /opt/app-root/src
              name: html
      volumes:
        - image:
            pullPolicy: Always
            reference: ghcr.io/kowalski7cc/website:scratch
          name: html

Automating static site build with Actions

Once we have deployed our first image, we can automatize the build with any kind of pipeline. If you are using a forge compatible with GitHub Actions, such as Gitea or Forgejo, you can use the Action. In this example I'm using Gatsbyjs framework for my website, but you can use your preferred one. After static site build, I use Red Hat buildah step to copy in a scratch image the static assets and publish them on my registry.

name: Build and push

on:
  push:
    branches: ["master"]

env:
  REGISTRY: my-private-registry
  IMAGE_NAME: ${{ github.repository }}
  NODE: 24

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v6

      - name: Use Node.js ${{ env.NODE }}
        uses: actions/setup-node@v6
        with:
          node-version: ${{ env.NODE }}
          cache: npm

      - name: Get npm cache directory
        id: npm-cache-dir
        shell: bash
        run: echo "dir=$(npm config get cache)" >> ${GITHUB_OUTPUT}

      - uses: actions/cache@v5
        with:
          path: ${{ steps.npm-cache-dir.outputs.dir }}
          key: ${{ runner.os }}-node${{ env.NODE }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node${{ env.NODE }}-

      - name: Install dependencies
        run: npm ci

      - name: Caching Gatsby
        id: gatsby-cache-build
        uses: actions/cache@v5
        with:
          path: |
            public
            .cache
          key: ${{ runner.os }}-gatsby-build-${{ github.run_id }}
          restore-keys: |
            ${{ runner.os }}-gatsby-build-

      - name: Build
        run: npm run build

      - name: Upload public assets for job ${{ github.run_id }}
        uses: actions/upload-artifact@v7
        with:
          if-no-files-found: error
          name: public
          path: public/

  push-raw:
    needs: build
    runs-on: ubuntu-latest

    permissions:
      packages: write

    steps:
      - name: Download public assets for job ${{ github.run_id }}
        uses: actions/download-artifact@v8
        with:
          name: public
          path: public

      - name: Build Image
        id: build-image
        uses: redhat-actions/buildah-build@v2
        with:
          base-image: scratch
          image: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: "latest ${{ github.run_id }}"
          context: public
          content: public
          oci: true

      - name: Push To Registry
        id: push-to-quay
        uses: redhat-actions/push-to-registry@v2
        with:
          image: ${{ steps.build-image.outputs.image }}
          tags: ${{ steps.build-image.outputs.tags }}
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Print image url
        run: echo "Image pushed to ${{ steps.push-to-quay.outputs.registry-paths }}"

Web hosting is not the limit

With this approach, we can apply the same paradigm with other types of application. For example we can have a OpenJDK Runtime for running our Java application, and have a pipeline build only the JAR artifact inside a OCI image and just push that on a registry. Or a more complex application runtime such as JBoss, where we can have our WARs inside a image and configurations stored inside Config Maps and just mount them in the container using a flexible deployment!

Every application which needs a runtime image, already provided by a vendor, can potentially use this approach. We could even build standard applications and just mount them on a distro base image, almost like how systemd's sysextensions work!

Kubernetes reference

Use an Image Volume With a Pod

Systemd-boot install on Fedora 32 (Updated for Fedora 40)

Wed, 03 Jan 2024 00:00:00 GMT

Systemd logo

Since many years, GRUB has been the default manager of every Linux distribution. This until systemd-boot has born, allowing easier configuration and promising enhanced security for our devices.

Let's see how to install it on Fedora 32 or Fedora 40

If you're planning to install Fedora 39 or more recent, you can directly configure anaconda to use systemd-boot as bootloader, adding the following argument in the boot command line:

inst.sdboot

you can check the details on the Fedora 39 documentation and the Change on the Fedora Wiki.

This still not covers booting with secure boot enabled, you will need to enroll your own keys. You can use a tool like sbctl to do that.

Take you responsabilities first

I am not responsible for bricked computers, system instabilities, dead cats, thermonuclear war or you getting fired because you lost important work.

Please make a backup of your device or of the data, and make a boot drive in case of necessity. Do some research if you have any concerns about steps documented in this guide.

YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.

Check if you are running EFI

Before doing anything, you should check that you are running using EFI, and if you have Secure Boot enabled, you may want to turn it off now.

To do that, you can use the following one-liner:

test -d /sys/firmware/efi && echo EFI || echo Legacy

If the result of the command will be "EFI", you're good to go with this guide.

Move ESP mount to /efi

First of all, we need to move the ESP partition from /boot/efi to /efi

Let's start by creating the folder for EFI mount point

sudo mkdir /efi

You can use Vim (or any other text editor you like) to edit the fstab file using this command:

sudo cp /etc/fstab /etc/fstab.bak # (Make a backup first if you are unsure)
sudo vi /etc/fstab

Edit the line by entering in "insert mode" by pressing the "i" button

UUID=xxxx-xxxx    /boot/efi    vfat    umask=0077,shortname=winnt 0 2

to:

UUID=xxxx-xxxx    /efi    vfat    umask=0077,shortname=winnt 0 2

Press the esc button to return to normal mode, followed by ":wq" to save the modified file and quit.

If you edited correctly you should be able to run successfully the following commands to unmount the efi partition and mount it to the new path:

sudo systemctl daemon-reload
sudo umount /boot/efi
sudo umount /boot
sudo mount /efi

After this you will be able to cleanup the boot partition as well.

Install systemd-boot

The firts step is to create a folder in the ESP directory with the machine-id in the name

sudo mkdir /efi/$(cat /etc/machine-id)

If you have Fedora 34+, you need to remove GRUB from DNF's protected packages

sudo rm /etc/dnf/protected.d/{grub,shim}*

install systemd-boot and then uninstall GRUB related packages.

sudo dnf remove -y grubby grub2\* memtest86\* && sudo rm -rf /boot/*
sudo dnf install -y systemd-boot-unsigned sdubby

Do not reboot after this, or you will not be able to boot!

Edit the file /etc/kernel/install.conf to have tge following content:

BOOT_ROOT=/efi
layout=bls

We can delete the boot partition using parted and resize the esp partition. Pay attention to this step, as deleted partitions are (usually) unrecoverable. By default Fedora should create the first partition arount 500-600MB in VFAT for EFI/ESP and the second partition around 1-1.5GB for boot. With this layout you can safely delete the second one and grow the first. Your partition table may differ, you can check this with parted /dev/YOUR_DISK print.

In my case the system disk is /dev/vda:

sudo parted /dev/vda rm 2
sudo umount /dev/vda1
sudo growpart /dev/vda 1
sudo mount /efi

If you have used a custom partition layout, you will know how to proceed, good luck!

Now we can install the bootloader and the kernel entries:

cat /proc/cmdline | cut -d ' ' -f 2- | sudo tee /etc/kernel/cmdline
sudo bootctl install
sudo kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz
sudo dnf reinstall kernel-core

If everyting installs correcry, now you can reboot, and you should boot normally using systemd-boot

You can verify everything working correctly with

sudo bootctl

You can use sbctl to setup Secure Boot signature with sistemd boot and enroll your keys.

Enjoy systemd-boot!

systemd-boot running inside GNOME Boxes

Sources

Thanks to all these people for their guides and tips:

Automatic LUKS 2 disk decryption with TPM 2 on Fedora

Wed, 03 Jan 2024 00:00:00 GMT

Photo courtesy of George Becker

You just switched to Linux after years of Windows, and after setting up full disk encryption with LUKS2, you already miss one handy Windows feature: BitLocker and its automatic disk unlock.

Today we will learn how to approximate its behavior under the popular Linux distribution Fedora

If you are using an old version of Fedora, you must use clevis to bind the TPM2 (TPM 1.0 is not supported and never will be) key to the LUKS volume, but if you are using Fedora 35 or later, you can use the new systemd-cryptenroll command.

First chech for available TPM2 devices:

systemd-cryptenroll --tpm2-device=list

And check for Secure Boot status, you need to enable it in order to prevent tampering with the boot process:

mokutil --sb-state

If you have a TPM2 device, you can use the following command to bind the TPM2 key to the LUKS volume:

sudo systemd-cryptenroll --wipe-slot tpm2 --tpm2-device auto --tpm2-pcrs "0+1+2+3+4+5+7+9" /dev/nvme0n1p3

where --tpm2-pcrs is the list of PCRs to use for the binding, you can find more information about PCRs later in this article.

You need to update the /etc/crypttab file to unlock the volume at boot:

luks-7a02e564-b7fa-4837-a3ec-3b83752c3a20 UUID=1f7f5ba4-01f8-419e-ae48-5daaa69bd1e6 none discard,tpm2-device=auto

On earlier versions of Fedora (before 36), you may update dracut to include libtss2 in the initramfs:

Create a file /etc/dracut.conf.d/tss2.conf with the following content:

install_optional_items+=" /usr/lib64/libtss2* "

and then regenerate the initramfs:

dracut -f

You can also add a recovery key to the LUKS volume. It's the same as the normal key, but it's generated with higher entropy.

systemd-cryptenroll --recovery-key /dev/nvme0n1p3

Clevis installation and configuration

The things we need (besides the LUKS2 installation we already did) to accomplish this task are the Trusted Platform Module

First things first, we need to install the Clevis framework and the needed plugins with Fedora's DNF package manager with this simple command:

sudo dnf install clevis clevis-luks clevis-dracut clevis-udisks2 clevis-systemd

Then we need to find the LUKS volume to bind, we can use the tool lsblk to find the volume (In my case it was nvme0n1p3).

[kowalski7cc@Kaos ~]$ lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
nvme0n1                                       259:0    0   477G  0 disk
├─nvme0n1p1                                   259:1    0   600M  0 part  /boot/efi
├─nvme0n1p2                                   259:2    0     1G  0 part  /boot
└─nvme0n1p3                                   259:3    0 475,4G  0 part
  └─luks-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 253:0    0 475,3G  0 crypt
    ├─fedora_localhost--live-root             253:1    0    70G  0 lvm   /
    ├─fedora_localhost--live-swap             253:2    0   7,8G  0 lvm   [SWAP]
    └─fedora_localhost--live-home             253:3    0 397,6G  0 lvm   /home

If we are right we should have an output like this using the tool cryptsetup:

[kowalski7cc@Kaos ~]$ sudo cryptsetup luksDump /dev/nvme0n1p3
[sudo] password di kowalski7cc:
LUKS header information
Version:        2
Epoch:          3
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

PCR IDS

To make sure our boot has not tampered, we must choose some PCRs to validate against the boot.

Here is a table with the IDs and a small description of its usage:

PCR ID	Description
0	Firmware
1	Firmware configuration
2	Option ROMs
3	Option ROMs configuration
4	MBR
5	MBR Configuration
6	State transition
7	Platform-specific
8 - 15	Operating System reserved
16	Debug
23	Applications

Finally we can use the following command to set up the decryption key usin the TPM PCRs:

sudo clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_ids":"0,1,2,3,4,5,6,7"}'

If it's correct, it will ask for your LUKS encryption password and add the Clevis key to the LUKS header.

Key upgrade procedure

When we do a kernel upgrade, probably our saved key will be invalidated. At this point, we need first to locate the Clevis key slot in the LUKS header.

We can use the command cryptsetup luksDump like before to locate it.

[kowalski7cc@Kaos ~]$  sudo cryptsetup luksDump /dev/nvme0n1p3
[sudo] password di kowalski7cc:
LUKS header information
Version:        2
Epoch:          7
...
Tokens:
  0: clevis
  Keyslot:  1
...

We can see that clevis is using Keyslot 1, so we can proceed with

sudo clevis luks unbind -d /dev/nvme0n1p3 -s 1

Then we can use sudo clevis luks bind... again to set up the new key.

Some notes and small thoughts about security

At the moment I've tested successfully Clevis only with GRUB
GRUB doesn't support measured boot, so it could be possible to tamper
You need a full trusted chain of boot, e.g. using secureboot
- You need to allow only your keys
- Oops! Microsoft Accidentally Leaks Backdoor Keys to Bypass UEFI Secure Boot
- Exploiting signed bootloaders to circumvent UEFI Secure Boot
TPM 2 has been proved to be unsafe when used alone
More things about secureboot, trustedboot, measuredboot

Top userful JavaScript shorthands

Mon, 23 Aug 2021 00:00:00 GMT

The if-else shorthand

if (age < 18) {
  console.log("You cannot drive in some states");
} else {
  console.log("You can drive in some states");
}

shorthand:

console.log(
  age < 18
    ? "Non You cannot drive in some states"
    : "You can drive in some states"
);

react:

<div>
  {age < 18 ? (
    <Button disabled>You cannot drive</Button>
  ) : (
    <Button>Book your exam</Button>
  )}
</div>

Spread Operator Shorthand

let numbers = [2, 3];
let fullNumbers = [1, ...numbers, 4, 5];

react:

function GreetingFunction() {
  return <Greeting firstName='Kowalski' lastName='Dragon' />;
}

becomes

function GreetingFunction() {
  const props = { firstName: "Kowalski", lastName: "Dragon" };
  return <Greeting {...props} />;
}

Destructuring

let people = ["Max", "Anna", "Tom"];
let [firstBoy, , secondBoy] = people;
firstBoy; // Max
secondBoy; // Tom

Or Short-circuit Evaluation

if (variable1 !== null || variable1 !== undefined || variable1 !== "") {
  let variable2 = variable1;
} else {
  let variable2 = "new";
}

shorthand:

const variable2 = variable1 || "new";

Object Property Shorthand

const x = 1920,
  y = 1080;
const obj = { x: x, y: y };

shorthand:

const obj = { x, y };

Arrow Functions Shorthand

function sayHello(name) {
  console.log("Hello", name);
}

setTimeout(function () {
  console.log("Loaded");
}, 2000);

list.forEach(function (item) {
  console.log(item);
});

shorthand:

sayHello = (name) => console.log("Hello", name);

setTimeout(() => console.log("Loaded"), 2000);

list.forEach((item) => console.log(item));

Implicit Return Shorthand

function calcCircumference(diameter) {
  return Math.PI * diameter;
}

shorthand:

calcCircumference = diameter => (
  Math.PI * diameter;
)

Default Parameter Values

function volume(l, w, h) {
  if (w === undefined) w = 3;
  if (h === undefined) h = 4;
  return l * w * h;
}

shorthand:

volume = (l, w = 3, h = 4) => l * w * h;
volume(2); //output: 24

And shorthand with implicit return and arrow function

function isNotEmpty(arr) {
  if (Array.isArray(arr) && arr.length > 0) {
    return true;
  } else {
    return false;
  }
}

shorthand:

const isNotEmpty = (arr) => Array.isArray(arr) && arr.length > 0;

react:

<div>{articles > 0 && <ul>...</ul>}</div>

Template Literals

const welcome = "You have logged in as " + first + " " + last + ".";
const db = "http://" + host + ":" + port + "/" + database;

const welcome = `You have logged in as ${first} ${last}`;
const db = `http://${host}:${port}/${database}`;

Sources

Gain back the control of your browser

Thu, 17 Jun 2021 00:00:00 GMT

Image by 200 Degrees from Pixabay

Some sites decided that, for security or whatever any other reasons, you should not use certain browser functionalities. We can change that behaveaur using bookmarklets, bookmarks you can store in your web browser that contains some JavaScript that add new features to it.

Just add them to your favorites, and "press" on them when you need them!

Some userful bookmarklets

To add a bookmarklets to your browser, drag and drop the link in your favourites bar or add a new bookmark using the "minified bookmarklet version" as the url of the bookmark.

Allow Paste

Source:

var allowPaste = function (e) {
  e.stopImmediatePropagation();
  return true;
};
document.addEventListener("paste", allowPaste, true);

Minified bookmarklet version:

javascript: void document.addEventListener(
  "paste",
  function (t) {
    return (t.stopImmediatePropagation(), !0);
  },
  !0
);

Right Click

Code:

javascript:void(document.oncontextmenu = null))

Text Selection

Source:

function R(a) {
  ona = "on" + a;
  if (window.addEventListener)
    window.addEventListener(
      a,
      function (e) {
        for (var n = e.originalTarget; n; n = n.parentNode) n[ona] = null;
      },
      true
    );
  window[ona] = null;
  document[ona] = null;
  if (document.body) document.body[ona] = null;
}
R("click");
R("mousedown");
R("mouseup");
R("selectstart");

Minified bookmarklet version:

javascript: (function () {
  function R(n) {
    ((ona = "on" + n),
      window.addEventListener &&
        window.addEventListener(
          n,
          function (n) {
            for (var o = n.originalTarget; o; o = o.parentNode) o[ona] = null;
          },
          !0
        ),
      (window[ona] = null),
      (document[ona] = null),
      document.body && (document.body[ona] = null));
  }
  (R("click"), R("mousedown"), R("mouseup"), R("selectstart"));
})();

Sources:

My homelab

Thu, 19 Sep 2019 00:00:00 GMT

"The Rack"

What is packed inside my rack

Ubiquiti USG 4 Pro
Patch Panel
Cable organizer
Ubiquiti UniFi Switch 16 PoE
Tim Hub
Tado° Smart Thermostat
Dell R210 II
- Intel Xeon E3 1265l V2
- 16GB ECC Buffered
- 2x 3TB WD Red
- Samsung 860 Evo 250GB SSD
UPS CyberPower 900VA

Total power usage: Less than 120 Watts!

Server Dell R210 II

Happy homelabbing everyone!

My battlestation

Tue, 17 Sep 2019 00:00:00 GMT

My battlestation

What is on my desk

Dell XPS 13 9350
- Intel Core i7 6560U
- Samsung 500GB SSD NVMe
- 16GB DDR3l
- 4K touch display
Edifier Luna Eclipse
Dell WD15 Dock
AOC 23" FHD 3D monitor
~~Google~~ Nest Home Mini
Logitech Keyboard K810
Logitech MX Master mouse
Kysoh TuxDroid

My penguin robot, TuxDroid

That's it :)