Mostly indieweb builders - BlogFlock

Revisiting Leander v Sweden and Big Brother Watch - Bert Hubert's writings

2026-11-10T19:10:00.000Z

Governments in Europe are gearing up to increase their bulk surveillance capabilities. One check on their ambitions is the European Convention on Human Rights. In this piece, I want to highlight recent jurisprudence from the European Court of Human Rights (ECtHR), and interpret the case law in light of current cybersecurity and AI developments. This interpretation may have relevance for future evaluations of SIGINT and other bulk data collection programs. Because what seemed reasonable a few years ago may no longer be so.

Stickerbombed: Lenovo X1 Carbon Gen 14 Aura - マリウス

2026-11-10T05:32:01.000Z

Especially with laptops being an attractive target for thieves at airports and touristic areas, I not only enjoy telling a story through the appearance of my devices, but I also find customizing the appearance a good way to deceive snatchers into mistaking these items for something of lower and potentially uninteresting value.

Unlike the average tech bro that collects stickers of their favorite tech corporations and stacks, only to stick them onto their MacBooks in an uninspiring way, I prefer to carefully plan my stickerbombing and create a well-crafted collage that tells a story. For that, I use stickers that I collect throughout my travels, and also order specific stickers, which I then cut into new motifs. Instead of Silicon Valley logos, my works usually contain imagery that is reflective of personal life events, social topics, and sometimes satire.

If you like this sort of art and are looking for further inspiration for your own projects, you might enjoy the books by Stickerbombworld, as well as the c/stickerbomb and r/stickerbomb communities.

Stickerbombed X1 Carbon (back)

ARIN-prop-355: Clarification of Recipient Requirements for 8.3 Transfers - Home on American Registry for Internet Numbers

2026-11-10T05:00:00.000Z

Problem Statement

The 12-month hold placed on a recipient of an 8.3 transfer that prohibits a recipient becoming the source entity of a subsequent 8.3 transfer is not sufficiently clear in a number of community members’ views, leading to poor experiences and operational complications for those community members. Members have requested a clearer statement of this condition in policy.

Policy Statement

Current Text:

Under 8.3:

Conditions on source of the transfer (third bullet point):

Ontology #2: wish you were here - lcamtuf’s thing

2026-11-10T03:16:45.000Z

My articles about philosophy aren’t popular, but I think they’re needed in the tech industry. In the series so far, I broadly argue against the rejection of metaphysics — that is, a framework that reconciles the experience of being human with the scientific theory of the material world. Without it, many techies gravitate toward radical utilitarian views that can justify almost any harm.

If you need to catch up on the series, I have it laid out in the recommended reading order:

To take a break from proselytizing, let’s continue the discussion of ontology: a branch of philosophy that deals with the nature of being. In the previous installment, we showed that it has thought-provoking ideas about time, with interesting tie-ins to cosmology and sci-fi. Today, let’s talk about things that could have been.

That which isn’t real

Similarly to epistemology — the study of knowledge — ontology aims for a degree of rigor in how it talks about the world. It’s accepted that some concepts are too ambiguous or otherwise not conductive to philosophical inquiry, but the goal is to have a reasonably precise way to address the largest possible slice of reality.

Epistemology has shown us that this is worthwhile: codifying the methods of reasoning netted us a comprehensive theory of mathematics, ridding the field of numerous paradoxes and endowing the remaining hazards with well-defined shapes: the halting problem, Gödel’s incompleteness, and so forth.

Unfortunately, a practically useful theory of existence is a bit more elusive. In the most inclusive sense, “existence” is just the right to be that’s bestowed upon any coherent, logically permissible idea. For example, we may say that the number two exists and the number frombty-nine does not. Alas, if we take this view, we end up with a chaotic menagerie of philosophical entities that don’t actually exist and could never occupy the same physical reality.

Most philosophers agree that concrete, singular objects — for example, your left shoe — have firm ontological standing. At the same time, the shoe isn’t just a clump of atoms; the laws of physics have no discernible opinion on where a shoe begins or what purpose it serves. The object is more usefully modeled as a physical manifestation of an underlying concept; the atoms’ shoeness must be established through observer testimony or through the application of some ad-hoc classification formula.

From there, we must give some consideration to the ontological status of the general concept of footwear. The idea has no specific physical embodiment: there’s no Chaussure des Archives in a vault in Paris. Nevertheless, we can distill the essential, common attributes of boots, flip-flops, and sneakers; it’s what lets us look at a new object and exclaim “a-ha, that’s a shoe”. This collection of properties — a universal — probably ought to exist in the sphere of philosophical discourse, no different from the concept of any particular shoe.

This conclusion, in turn, makes it hard to say no to individual objects that exist in the understanding but aren’t currently instantiated in the physical realm. Such possibilia may include William Shakespeare, who’s no longer with us; or any number of completely imaginary creatures, such as unicorns or the girlfriend-slash-boyfriend of your dreams.

“Automat”, Edward Hopper (1927)

The resulting possibilist ontology is filled to the brim with physically nonexistent beings. To make the idea more palatable, we can sort these non-instantiated entities into hypothetical realms — possible worlds — each still bound by the laws of reason, but allowed to diverge from the state of affairs on planet Earth. This way, the ontological clutter is averted and the unicorns have a place to roam.

The logic of “maybe”

The wrench in the works is that these alternative realities are out of each for conventional formal logic. This system of reasoning operates on bivalent truths; if pigs don’t fly, there’s no simple way to add “…but they could!”. In an earlier introduction to the topic, I noted that we can construct counter-to-fact conditionals, but such sentences are always true, with no hope of inspecting the world beyond:

“Another subjective issue crops up with the following statement:
It feels wrong, but there’s nothing we can disprove: the consequent (B) is false, but so is the antecedent (A) it’s gated on. We just don’t like that the sentence limits our imagination: perhaps if pigs could fly, all pumpkins would be donut-shaped? But if the task at hand is to work from true premises toward logical conclusions, and A is not a true premise, why the heck are we trying to form opinions about B? It’s a universe that doesn’t exist; we’re not given the axioms that govern it.”

The missive made sense at the time, but in retrospect, it seems a bit short-sighted; we want to reason about these hypotheticals to see where they lead. Are the unicorns having fun, or have we condemned them to a life of philosophical misery?…

The solution is modal logic; its basic form, due to Saul Kripke, introduces two new operators: ◊ (“it is possible that…”) and ◻ (“it is necessary that…”). The mechanics of these operators are fleshed out by adding a couple of new axioms; for example, we can say that the necessity of p automatically implies its truth in the current frame of reference:

By itself, modal logic doesn’t explain the source of modality — i.e., it doesn’t spell out the mechanism by which some propositions are deemed necessary and others are merely possible. Luckily, to ground it a bit better, we can now lean on the concept of possible worlds: ◻p simply tells us that the proposition must be true in every logically-consistent reality, while ◊p says that there’s at least one possible world in which p is true.

German novelty postcard, detail (circa 1929).

Of course, we’re still leaving a pretty important question unanswered: what do we really mean by a “possible world”?

The abstractionist within

The abstractionist answer is probably what you expect: every possible world is a primitive, conceptual entity that represents the way things could have been. It is sometimes modeled as a maximal collection of propositions that describe the totality of the world’s hypothetical state of affairs. In this respect, it is reminiscent of the nebulous, uppercase Truth of reality.

The most unsatisfying aspect of abstractionism is that it dodges the question of how these worlds come to be or what space they occupy. They snap into existence from modal logic — a form of computation — so perhaps they’re akin to numbers: consequences of mathematical theory that, if not actively thought about, simply retreat into the metaphysical void and later emerge unharmed.

But then, imagine Wendell Norton of Bellewood, Kentucky. Wendell is 52 years old; every night, he dreams of frolicking in the fields of Unicorn World 17. Is this world truly on the same footing as Unicorn World 3273, of which no one has ever thought at all? Can we say the same of the inhabitants of these two realities?…

The Central Finite Curve

This is where concretists chime in with a resounding “yes”. To the adherents of this philosophy, there’s no qualitative difference between possible worlds and the actual one. The distinction is indexical: your subjective self just happens to find itself in one of many parallel, causally-separated realities. It’s similar to how “now” isn’t a distinguished property of any specific time; it’s just the moment you’re in.

Detail of “Allegory of Good Government”, Ambrogio Lorenzetti (circa 1339)

Although concretism may seem ontologically extravagant, it meshes well with the many-worlds interpretation of quantum mechanics, as developed Hugh Everett around the same time. Everett’s interpretation posits that the collapse of the quantum wave function that occurs on measurement corresponds to the formation of parallel, decohered realities that account for each possible outcome. The theory was originally not taken seriously, but it has gained more acceptance in the past couple of decades — in part because it deals away with some of the persistent paradoxes of the parent theory.

The main problem with concretism is the apparent collapse of morality: if free will exists, then every morally good decision you make spawns a mirror world in which you’ve taken the evil choice (and vice versa). Since the sum of good and evil seems to remain the same, and since your world has no privileged ontological status, it would appear that it doesn’t matter how you behave.

If you find concretism provocative, here’s a parting shot: if all possible worlds exist, what about impossible ones? These are the realities that contain contradictions or where the laws of logic no longer hold. What stops them from being formed — and could you ever end up in one?…

Subscribe now

Using a Raspberry Pi Pico to control a large-scale model locomotive -- part 2 - Kevin Boone's website

2026-11-09T16:45:10.000Z

A simple way to control locomotive speed whilst playing realistic "steam engine" sounds. This article describe the assembly of the controller carriage and its electronics.

Using a Raspberry Pi Pico to control a large-scale model locomotive - Kevin Boone's website

2026-11-09T15:03:08.000Z

A simple way to control locomotive speed whilst playing realistic "steam engine" sounds.

Veterans Day Closing Information - Home on American Registry for Internet Numbers

2026-11-09T05:00:00.000Z

The ARIN office will be closed on Wednesday, 11 November, in observance of Veterans Day. ARIN’s office will reopen with normal operating hours on Thursday, 12 November.

Build container images with a Forgejo runner and Docker-in-Docker - Solene'%

2026-11-09T00:00:00.000Z

# Introduction

This article is the second of a series about building my container images on my Forgejo server. In the previous article, I explained how I run a private registry with zot.

The images are now built by Forgejo Actions, which is the CI of Forgejo, compatible with the GitHub Actions syntax (mostly). The jobs are executed by the Forgejo runner, a program you install on another system which takes the jobs from Forgejo and runs them in containers or as a regular user, beware that using it as a regular user might never clean completely betweens builds and has less sandboxing.

=> https://forgejo.org/docs/latest/admin/actions/runner-installation/ Forgejo runner installation documentation

The biggest challenge of the whole setup was to have the Forgejo runner able to build container images, because the jobs already run inside a container.

In this blog post, you will learn how I run the Forgejo runner with Docker-in-Docker, and how a workflow builds, tests and pushes an image to zot.

# The runner

The runner runs in a dedicated VM. It is started as a container, next to a special container called "DinD" (Docker in Docker, not dinde which is a turkey in French), which is a Docker daemon running inside a container. The CI jobs talk to this Docker daemon to build and start containers.

The DinD container needs privileges to run, but it does not give any privilege to the runner. The jobs can build images, but they do not run as privileged containers. The whole thing is not easy to grasp, I have to admit.

## Why a dedicated VM

All my services run in Incus, and Docker-in-Docker would need a privileged container to work, which I do not want. The jobs also run code I do not control, like the dependencies of a project, so I prefer a better isolation than a container. This is why the runner lives in its own virtual machine, it has better security and I can allow priviliged containers to run.

The VM is created in Incus with OpenTofu, and it runs Ubuntu like the rest of my infrastructure. I gave it 4 vCPU, 8 GB of memory and 40 GiB of disk, but this is arbitrary, it depends on what you build. Compiling a kernel, generating a NixOS ISO or rendering a Hugo website do not need the same resources.

Because the VM only runs jobs, I consider it as something I can throw away and recreate at any time. For the same reason, I do not filter its outgoing network access, there are too many different things downloaded by the jobs for a filter to be practical, and it does not contain sensitive data.

## Podman and Docker

The runner itself is started by podman, and the DinD container is started by Docker. It may look strange to use both, but the reason is simple. I declare everything with podman quadlets, and Docker-in-Docker only works well with Docker. The Docker container is the exception, it is started at boot by a command run from a systemd service, while the podman containers use quadlets.

I could totally start the CI runner within Docker, but my whole deployment framework is using podman so I prefered to keep things simple for an extra dozen megabytes.

## Registering the runner

The get the runnre working with Forgejo, you need to authenticate the runner, there is a registration mechanism between the two. The network flow is that the runner is connected to Forgejo and receive orders, not Forgejo connecting to runners.

I registered the runner by hand, and I stored the registration secret with sops. I did not see a reason to automate it, because I only have to do it once, if I need to do it again once it would take a couple minutes.

The registration is well explained in the Forgejo documentation.

=> https://forgejo.org/docs/latest/admin/actions/runner-installation/ Forgejo runner installation documentation

## Starting the runner and DinD

The DinD container is started with this command, using the Docker image `docker:dind`:

```
docker run -p 192.168.200.200:2376:2375 --detach --privileged --restart always --name dind_container docker:dind dockerd -H tcp://0.0.0.0:2375 --tls=false
```

The container runs privileged, because this is required by Docker-in-Docker. The Docker daemon listens on the port 2375 and all interfaces inside the container, which is published on the port 2376 of the VM on the IP 192.168.200.200. TLS is disabled, so anyone who can reach this port controls the daemon but this is local traffic only. The port 2376 should only be reachable from the VM itself, so be careful with your firewall.

The runner has two ways to talk to a Docker daemon. In its configuration, `docker_host` is set to `unix:///var/run/docker.sock`, which is the podman socket, so the runner starts the job containers with podman. The jobs running in these containers need to build images, so they use the DinD daemon through TCP. This is done by setting the variable `DOCKER_HOST` for the jobs, in the `envs` section of the runner configuration file:

```
envs:
DOCKER_HOST: tcp://192.168.200.200:2376
```

I had issues using `127.0.0.1` here, I think because of the nesting of the containers. So the VM has a dummy network interface, which is a virtual interface not connected to anything, with the address `192.168.200.200`. This address is only reachable from the VM itself, and the jobs use it to reach DinD. You can use another private address if you prefer.

There is one thing to keep in mind with this setup. The image store of the DinD daemon is shared by all the repositories using the runner, so a job could reuse an image or a layer left by a job of another repository. This is why my builds always use `--pull --no-cache`.

# The workflow

The workflow building the image is in `.forgejo/workflows/image.yml` in the repository of my Airthings exporter, which is public (it is an IoT device to measure air quality).

=> https://git.coopix.eu/public/airthings-prometheus-exporter airthings-prometheus-exporter repository

Here is a reduced version of it, without the verification of the base images, which is covered in the last article of this series:

```
name: image

on:
push:
branches: [main]
paths: ['Containerfile', 'requirements.txt', 'airthings_exporter.py', 'airthings_site.py']
pull_request:
paths: ['Containerfile', 'requirements.txt', 'airthings_exporter.py', 'airthings_site.py', '.forgejo/workflows/image.yml']
workflow_dispatch:

concurrency:
group: image-${{ github.ref }}
cancel-in-progress: false

jobs:
publish:
runs-on: alpine-node
env:
TAG: ${{ github.event_name == 'pull_request' && 'airthings-exporter:pr' || 'registry.example.org/airthings/airthings-exporter:latest' }}
steps:
- name: Tools
run: apk add --no-cache docker-cli docker-cli-buildx

- uses: actions/checkout@v4

- name: Login to the registry
if: github.event_name != 'pull_request'
env:
REGISTRY_CI: ${{ secrets.REGISTRY_CI }}
run: printf '%s' "$REGISTRY_CI" | docker login registry.example.org -u ci-airthings --password-stdin

- name: Build
run: docker build --pull --no-cache -f Containerfile -t "$TAG" .

- name: Start
run: docker run --rm --entrypoint python "$TAG" -c 'import prometheus_client, requests, dotenv, airthings_exporter, airthings_site'

- name: Push
if: github.event_name != 'pull_request'
run: docker push "$TAG"
```

Replace `registry.example.org` with the address of your registry, and create the secret `REGISTRY_CI` in the repository settings with the password of the `ci-airthings` account created in zot.

Some explanations:

* the workflow runs on every pull request, and when a change lands on `main`, but only if a file used in the image changed
* there is one `concurrency` group per branch, so checking a pull request does not wait for a push from `main`, this is overkill here but useful if you work with multiple people working on a project at the same time
* on a pull request, the image gets a local tag and the job never logs in to the registry, so the registry password is not available to the code of the pull request, the push only happens once the pull request is merged. The code in a PR in review should not be considered safe.
* the `-f Containerfile` part is needed because Docker only looks for a file named `Dockerfile`
* the step "Start" is a small test, it starts Python in the image and imports all the modules, if something is missing the job fails before the push

The repository is public, so you can see the runs of this workflow on the Actions page.

=> https://git.coopix.eu/public/airthings-prometheus-exporter/actions airthings-prometheus-exporter Actions page

# Conclusion

I really like this setup. I now use Renovate everywhere to keep the dependencies up to date (thanks to the fellow mastodon follower who suggested me Renovate). It opens a pull request, the workflow builds the image to check that it works, I merge the pull request, the image is built again and pushed to the registry. Then podman auto-update updates the container on the system, you can see an example in the airthings-prometheus-exporter repository.

The Docker-in-Docker setup was very complicated to get right, but since I build containers in a CI which already runs in containers, it is required.

If you need more CPU/memory for a project, you can also run a runner on your personal computer and use it only for this project. Having a runner not available 24/7 is not an issue, the jobs will be handled when the runner is started.

The runner itself is very easy to deploy. The hard part was DinD, it took me at least 2 hours to understand how to make it work. The Forgejo documentation has explanations, but it takes time to really understand what is happening between the runner, the job containers and the DinD daemon.

In the next article, I will explain how Renovate opens pull requests to update the dependencies and the base images, these pull requests are built and tested by this workflow before I merge them.

The race to secure record-like information for domains - Built on Shards of Silicon: Robert Alexander's Tech Blog

2026-11-09T00:00:00.000Z

It’s sort of surprising, but we’re still figuring out how to secure simple, record-like information for domain names in an application-accessible way.

Think about it. How would you bind the following to a domain name?

example.com
    Key-1: Value-1
    Key-2: Value-2

Importantly, how would you secure it?

DNS and DNSSEC

Since we’re talking about domain names, lets start with DNS. The classic solution adds configuration as TXT records:

_PROTOCOL.EXAMPLE.COM.  IN  TXT   "v=PROTOCOLv1; Key-1=Value-1; Key-2=Value-2"

Notice that we use an underscored subdomain label to make it clear we aren’t talking about a hostname. The protocol name is then repeated to make it abundantly clear this record is related to the protocol.

As is, we can’t claim this solution is secure. DNS-based network interference is trivial and widespread. The best practice for securing DNS records is DNSSEC, which uses cryptographic signing.

I’m not going to debate the security properties of DNSSEC in this post. There are strong opinions on both sides and the most helpful answer likely depends on the context in which you work. For the sake of this blog post I’ll wave my hands and call this “secure enough” to side-step the issue. In any case, the rest of the post doesn’t depend on a favorable or unfavorable assessment of the security properties of DNSSEC.

DNSSEC is uncommon

Even the strongest supporters of DNSSEC need to face the reality that DNSSEC isn’t widely adopted.

There’s no single answer that quantifies DNSSEC adoption. At Fox Loop Software I collect adoption metrics for various Internet protocols; we just released the first dashboard. Our approach highlights that adoption rates vary widely depending on which cohort you measure. For example, here are the adoption rates of DNSSEC signed MX records among second-level domain names that accept email:

Cohort	Adoption rate
Tranco top 1,000	12.3%
Tranco top 1,000,000	7.5%
.COM	1.4%
.GOV	10.4%
.SE	62.8%

From the perspective of an application developer, it is not reasonable to expect that a customer domain name will support DNSSEC. Until this changes, application developers must use alternate solutions if they need security.

The web approach

If my application is web-based then there’s a pretty obvious solution as I already have an HTTPS secured endpoint. I can use the HTTPS .well-known approach (RFC 8615).

GET https://example.com/.well-known/protocol.txt
---
Version: PROTOCOLv1
Key-1: Value-1
Key-2: Value-2

These records are secured by HTTPS. The developer experience is excellent: adding a record could be as easy as dropping a file in a web server directory. Fetching records is a simple HTTP GET request.

But not everything is a web-based application. Can we extend this solution to other protocols?

Case study: Email

Email is a very old protocol, predating not only TLS but the entire Internet as well. Over time all sorts of additions have been bolted on to modernize and maintain the protocol. Many of these additions added new DNS TXT records, such as SPF, DKIM, and DMARC. These records can be secured by DNSSEC but do not require it, so tampering of these records is unmitigated or otherwise tolerated.

Let’s look past these examples to a problem that clearly requires a secure record.

The hostname mis-match problem

Email has an awkward problem, which is how hostnames are managed. When a message transfer agent (MTA) relays an email it needs to discover the destination MTA. This is solved using an MX record, which specifies the target MTA’s domain name. I’ve measured that around 80% of domains host their email on a different domain name, often using providers like Google or Microsoft.

When sending an email, the MTA will discover a chain from the user’s email address to the receiving MTA’s TLS certificate, like this:

An insecure chain from the email address to the TLS certificate

The sending MTA now needs to decide if it trusts the connection. Unfortunately, smtp.provider.com, as seen in the TLS certificate, does not match example.com, as provided in the email address. The only link between the two domain names is an MX record, which typically unsigned and therefor insecure. Without trustworthy information, certificate validation cannot succeed and the sending MTA must skip validation.

Lack of certificate validation means that receiving MTAs can use a self-signed, expired, or even a certificate with the wrong name; the sending MTA does not care. This approach is known as “opportunistic encryption” and it provides strong protection against passive eavesdropping. But without a way to validate the receiving MTA’s TLS certificate, active attacks remained unmitigated.

Email cannot enforce authenticated MTA-to-MTA transit encryption until this hostname mis-match problem is solved in a secure way.

A problem end-to-end encryption cannot solve

Many email security conversations focus on end-to-end encryption. It is a great solution to many of the security problems facing email, but it doesn’t fully address the problem being discussed here.

Message relaying requires the MTA to know the recipient’s email address. This is known as “envelope information” and it cannot be end-to-end encrypted. Methods like PGP encryption can not and do not protect this information, as they only encrypt the message body.

The only way to protect this information from network-level attackers is to ensure the message is delivered to the correct MTA, which requires authenticated transit encryption.

Non-analogous to the web

When I first encountered this issue I was surprised as there is no analogous problem on the web. The issue relates to the semantic difference between a CNAME and an MX record. A CNAME record pointing at a web hosting provider’s server is a matter of identity and that server can get a TLS certificate to prove it. An MX record does not permit the target email server to get a corresponding TLS certificate.

A web browser is able to compare the name in the TLS certificate with the name shown in the address bar and can expect these to strictly match. An MTA doesn’t compare the name in the TLS certificate with the domain name in the “to” address as a mismatch is typically expected.

Further, email is sent asynchronously so there are no humans involved in MTA-to-MTA communications. While web browsers can show a certificate warning message to allow users to make their own security decisions, an MTA is all on its own. Email providers often tout support for transit encryption but the lack of certificate validation makes email traveling between MTAs about as secure as a user browsing the web while always clicking through invalid certificate warnings.

Interestingly, email has adopted two solutions to this problem: a DNSSEC-based approach and an HTTPS .well-known approach. This give us a unique opportunity to compare these approaches head-to-head as they attempt to solve the same problem.

SMTP DANE

The DNSSEC approach is SMTP DNS-based Authentication of Named Entities (DANE) (RFC 7672), which was standardized in 2015. DANE requires DNSSEC signing in both the customer and email provider’s DNS zones for the protection to have full effect.

DANE adds the TLSA DNS record. Here’s an example:

_25._tcp.mail.provider.com.  1200  IN  TLSA  3 1 1 6111A5698D23C89E09C36FF833C1487EDC1B0C841F87C49DAE8F7A09 E11E979E

This record indicates that the MTA-to-MTA connection can use authenticated encryption. Specifically, this record indicates that the receiving MTA should provide a TLS certificate with a public key digest of “6111A…”. Validating this pinned certificate does not depend on the certificate authority (CA) system.

SMTP DANE signals that it should be possible to cryptographically validate the chain from the domain name in the email address to the domain name on the receiving MTA’s TLS certificate.

One key benefit of DNSSEC, which we’ll revisit, is that blocking of a signed record can be distinguished from a non-existent policy. When the TLSA record does not exist, the authoritative DNS server should provide a signed proof of non-existence (NSEC). This acts as a fail safe: if DNSSEC is enabled and the sender cannot determine the DANE policy, then the sender can conclude that it is not safe to send the message as network interference may be present.

MTA-STS

Email providers realized that slow adoption of DNSSEC was delaying authenticated transit encryption between MTAs. They looked at what other tools were available and found inspiration from the HTTPS .well-known approach. Standardized in 2018, SMTP MTA Strict Transport Security (MTA-STS) (RFC 8461) provides an HTTPS-based solution.

Here’s what it looks like:

GET https://mta-sts.example.com/.well-known/mta-sts.txt
---
version: STSv1
mode: enforce
mx: smtp.provider.com
max_age: 604800

Notice that the mta-sts subdomain is used instead of the bare domain. This best practice stems from the need to isolate security policies from whatever website lives at the bare domain; often a marketing website which may not have a security posture suitable for cross-protocol policies like MTA-STS. To distinguish any pre-existing use of the mta-sts subdomain the “_mta-sts” TXT record must also be set.

_mta-sts.example.com. 3600     IN      TXT     "v=STSv1; id=190906205100Z;"

Finally, policy caching was added as a partial mitigation of intermittent network interference.

Like DANE, MTA-STS signals that the sender should strictly authenticate TLS. The MX record is duplicated in the MTA-STS policy, relying on HTTPS to secure the link. MTA-STS requires the receiving MTA to have a TLS certificate issued by a well-trusted CA.

An MTA-STS policy document is fairly unchanging, making it well-suited for inexpensive, widely available, and highly scalable static web hosting. Many domain owners implement MTA-STS by adding the subdomain to an existing web server, as a virtual host, although it turns out this isn’t always a good idea.

MTA-STS challenges

The TLS certificate renewal process is an obvious point of failure for MTA-STS. When a user-facing website goes down users complain, support tickets are filed, and the certificates are quickly renewed. The MTA-STS policy server fails open when it’s certificate expires. Senders will fall back to using opportunistic encryption and users won’t notice any disruption. As such an expired TLS certificate on an MTA-STS policy server can go unnoticed. To address this lack of visibility, TLS Reporting (RFC 8460) was created, which allows email servers to share deliverability reports with each other.

Another problem, which I think is an even larger issue, are web servers that block email servers from accessing their MTA-STS policy. You’ve probably noticed a sharp rise in bots, scrapers, and other unwanted automated traffic impacting the web. In the rush to protect web servers from these ills many sites inadvertently blocked access to their MTA-STS policy. An email server fetching an MTA-STS policy can look a lot like unwanted traffic: it’s automated and its coming from data center IP ranges. Misapplying security policies intended to protect user-facing websites from unwanted bot traffic degrades API-like interfaces.

Comparing MTA-STS and DANE

One unique benefit of SMTP DANE is that the policy cannot be blocked without the sender noticing. An MTA-STS policy server can be blocked just like any other web server and this blocking cannot easily be distinguish from a non-existent policy.

While MTA-STS caching can protect against intermittent network-level blocking of the policy server, the first email sent to a domain is always vulnerable due to an empty cache. The effectiveness of MTA-STS in preventing an on-path attacker from intercepting email is questionable if the same on-path attacker can block the sender from discovering the MTA-STS policy.

By these measures, DANE seems like the stronger option.

DANE’s reliance on DNSSEC signing is its major weakness. Measurements show that 0.9-1.2% of domain names that receive email have DANE support, which doesn’t provide much practical protection yet. Worse, large providers like gmail.com lack DNSSEC support, so the per-user impact may be larger. Unless DNSSEC adoption can grow among large email providers, DANE can only be a partial solution. In contrast, HTTPS is very widely adopted making MTA-STS familiar to practitioners, even with these challenges.

Improving MTA-STS

The web has blazed a path that MTA-STS can likely follow. HTTP Strict Transport Security (HSTS) (RFC 6769) is essentially MTA-STS for the web (or visa-versa). HSTS is similarly vulnerable when the cache is empty. Web browsers mitigate this issue using a preload list, which ships in the browser. Out-of-the-box, the web browser knows that popular websites, like wikipedia.com, strictly use HTTPS. While there are challenges with HSTS, like the size of the list, this may have marginal impact for a server-side technology like email.

I think MTA-STS can copy this solution. There are unknowns, like who would build an MTA-STS preload list, why we trust them to do so, and the exact semantics needed for a domain to be added. In any case, I think we should wait on increased MTA-STS adoption before we take those next steps.

The race is on

The adoption rates of MTA-STS and SMTP DANE tell an important story about how application protocols can secure domain information in practice. The fact that email has both a DNSSEC and an HTTPS approach gives us a way to spectate.

Current measurements show that MTA-STS has overtaken DANE among the top-ranked domain names.

Tranco Rank	DANE adoption	MTA-STS adoption
Top 1K	1.0%	2.6%
Top 10K	1.2%	1.9%
Top 100K	1.1%	1.3%
Top 1M	1.0%	0.7%

Given the importance of protecting messages, including envelope information which cannot be end-to-end encrypted, these results are disappointing.

Prior work shows that TLS downgrade attacks on email are widespread. With the slow adoption of email security protocols since that study, the situation is unlikely to have improved. We can and should do better.

These SMTP DANE and MTA-STS measurements will be published quarterly. Subscribe to the newsletter to follow the trends.

Similar approaches

MTA-STS isn’t the only protocol that works this way.

OpenPGP Web Key Directory (WKD) (draft-koch-openpgp-webkey-service-22) uses an HTTPS .well-known approach to secure PGP key distribution, facilitating end-to-end encryption of message bodies.

GET https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe

The WKD “advanced method”, seen above, follows the best practice of using a protocol-specific subdomain.

The analogous DNSSEC-based approach is OPENPGPKEY (RFC 7929).

._openpgpkey.example.com. IN OPENPGPKEY

Unfortunately, the SHA-256 hash does not provide meaningful privacy. Use of this protocol can leak the email addresses of your correspondents to passive network-level eavesdroppers. This highlights the importance of encryption, not just signing.

Other protocols like Mail AutoConfig (draft-ietf-mailmaint-autoconfig-07) simplify the process of setting up an email client and similar applications.

GET https://autoconfig.example.com/.well-known/client-autoconfig.xml?emailaddress=fred@example.com

Again we see this protocol follow the security best practice of using a protocol-specific subdomain.

There are over 100 registered .well-known URIs, showing the popularity of this approach. Many of these tolerate lower security properties and use the bare domain name instead of a protocol-specific subdomain.

Complementary solutions

While I’ve thus far framed the discussion as a competition, DNSSEC and HTTPS .well-known are actually complementary. We don’t need one approach to defeat the other: we’ll see ecosystem improvements as both solutions are adopted, side-by-side. HTTPS .well-known can offload large policy documents and allow rapid experimentation, avoiding the size limits of UDP packets and the slow process of adding new DNS record types. DNSSEC can sign the CAA record, providing improved security during TLS certificate issuance.

DANE could even replace the CAs entirely, a topic of renewed interest after the recent eMudhra mishap. After all, we wouldn’t need the CAs if we had a secure DNS.

I see complementary nature of DNSSEC and HTTPS .well-known emphasized in another draft, Domain Authority (DA): A DNS-Designated Service Endpoint for Domain Information (draft-swaminathan-da-00), which seeks to standardize the use of HTTPS to add capabilities to domain names beyond what DNS can natively support. While I think the current draft is too ambitious in scope, it provides a great summary of the benefits an HTTPS-based policy retrieval layer can provide beyond DNS.

Unfortunately, we still have an insecure DNS. But progress in the domain name ecosystem is not blocked by DNS. MTA-STS shows that an HTTPS approach is immediately usable.

Hello! I'm Robert Alexander, a DevSecOps consultant available for contract work. This blog features some of my work and thoughts on software, the cloud, and security. You can subscribe to my posts with your favorite RSS client and follow me on Mastodon.

If you'd like to show your appreciation and help support my writing, you can do so via this link.

Statements are my own and do not represent the positions or opinions of my employer.

The DO's and Don'ts of Post-Quantum DNSSEC - Potaroo blog

2026-11-08T22:00:00.000Z

There has been a lot of interest in recent months on the topic of post-Quantum cryptography (PQC) and DNSSEC. It appears likely that the day will come when our current suite of cryptographic algorithms could not resist efforts to break them using appropriately powerful quantum computers. Some folk say this day is decades away, while others are predicting we have just a small number of years. We have suitably strong quantum-resistant algorithms that we can use. The only problem is that these post-quantum digital signatures are up to 40 times as large as the signatures we use today. And this has some serious implications for the operation of DDNSSEC.

First steps in bare-metal programming using UEFI -- part 6 - Kevin Boone's website

2026-11-08T19:07:13.000Z

The sixth part of a series about bare-metal programming for x86 PC-type computers, using Linux for development. This article is about drawing graphics.

The web used to belong somewhere - Manuel Moreale — Everything Feed

2026-11-08T14:10:00.000Z

There are a couple of related ideas I found myself writing about here and there, either on the IRC server or on Quxnet. Ideas and thoughts about what the web used to be, how it used to feel, about how things have changed, and what can be done to bring at least some of the old web back.

We often point fingers at the big social media platforms, with their relentless algorithmic curation as the cause for the awfulness of the modern web. Maybe we blame the SEO folks, or the influencers. There’s a multitude of different characters who each played their role in turning the “old web” into “today’s web”. And I’m not going to pretend they didn’t play a role, because they did.

What I am going to argue for, though, is that there’s something else that has contributed a lot more to the changes that we’ve seen over the past few decades, and that’s the fact that the web used to belong somewhere. And I mean that in the physical sense. I’m not the first one to say this; you can find plenty of other posts out there making this exact point. But it’s a point worth repeating.

There was a time when in order to go online you had to physically go to a specific place: a desk in the house, an internet cafe, a computer lab. The web wasn’t always with you, and you were not always in it and with it. You had to go somewhere, do what you needed to do, and then leave.

BRB? AFK? Acronyms from what feels like a distant past. You are never away from the keyboard today, because there’s a phone following you around everywhere all the time. The internet feels exhausting these days because it’s always there. It’s become what feels like an inescapable presence, for better or for worse.

I’ve been particularly unhappy over the past few weeks, for a variety of reasons. And one thing I noticed is that every time I’m in a down phase of life, I can go look at my phone usage and it’s inevitably higher than it should be. At least for me, there’s a 1:1 correlation between how good I feel and how much of a presence the phone is in my life. And the phone is just a proxy for the web because browsing is 95% of what I do on my phone, since I don’t game and I don’t have social apps.

And that’s quite ironic considering I make websites for a living. I build for the web, and at the same time, spending more time than necessary on it makes me terribly unhappy.

But it feels different when I can leave the web behind, when I can get up from my chair, leave my desk, and the web is no longer with me. That feels healthier. The problem is that most of the world doesn’t work that way anymore. If you leave and come back, you’ll probably have a hard time catching up with everything that has happened while you were away because everybody else is not taking a break. And so even if we managed somehow to get rid of algorithmic curation and infinite scrolls and all those things, the web would still not feel like the “old web”. Because the web used to belong to a place. It sadly doesn’t anymore.

Thank you for using and believing in RSS. You're awesome.

Send me an email :: Sign my guestbook :: Become a supporter

Post on Josh Betz - Josh Betz

2026-11-08T03:28:49.000Z

Democrats should finally pass a law that bans members of Congress from trading individual stocks. It’s extremely popular, directly addresses corruption, and the President would probably sign it — he doesn’t care if members of Congress are allowed to trade stocks.

2026-11-08 Before Sunrise - Alex Schroeder’s Diary

2026-11-08T00:52:02.000Z

2026-11-08 Before Sunrise

A few days ago we watched Before Sunset and today we watched Before Sunrise (1995). Richard Linklater is the director, Julie Delpy and Ethan Hawkes are the main characters. They meet in a train and spend the night in Vienna. And then they go their own ways, promising each other – at the last moment – to meet again, six months later. No exchange of addresses or phone numbers. Just a promise.

The movie is about two people in their early twenties and their conversations about love, life, how they try to connect to each other, their looks, their kisses, their laughs. I am in my early fifties and I recognised many of the cringe dialogues and opinions held in the movie. And I am sooo happy that I met my wife when we were teenagers and never had to risk our relationship in such a way.

Surprisingly, the clubs and bars seemed immediately familiar to us and simultaneously unbelievable as seen from our times. These smoke filled, concrete holes, dirty bars, music, beer, alcohol – this is how we grew up and when I look around Zürich now, thirty years later, it seems like everything turned into a golden Buddha Bar. Then again, what do I know, I never go clubbing anymore.

Anyway, in terms of emotional impact, I could identify far better with the couple nine years later in Before Sunset. But then again, our twenties are so far away. Now we really want to see the third movie.

I talked about the attraction between the two with my wife. How do we feel that they are attracted to each other? What makes them attractive to us? I know what I like most about Delpy’s character: her laughing while she looks at him. And I think I know what other people like about Hawke’s character. He really listens to her, he really wants to know about her and he really wants to spend time with her. My wife agrees.

So many people these days seem to have different beliefs about what makes them attractive. But I like laughing and listening. ❤️

#Movies

Nurture the Muse - Konfetti Explorations

2026-11-08T00:00:00.000Z

Thoughts on: Allende, I. (2026). Storytelling : a masterclass in crafting stories. Bloomsbury.

I have a confession to make. I have never read any of Isabel Allende books, not for lack of trying. Growing up, I was apathetic towards matters of Latin America censorship and the history, my mind always dreaming of distant continents instead. Also, I dreaded the blocks of text Spanish literature, not dyslexia friendly —I did not know I enjoyed reading until I found American literature with more broken-down paragraphs and space meant for children. Perhaps I was just too young. But I digress.

Last night I read “The Threatened Muse”, the second chapter in her new inspirational book. When I received it at my desk to catalogue in Dutch, I was enchanted by its beautiful cover. Before I even processed it, I read the introduction. The moment I finished it, I knew it was meant to be. The fact that I haven’t read her books does not deter me from the fact that she is an amazing writer, if not one of the best ones to exists at the moment.

I bought the English edition, since it is the language I can absorb the most of, and intend to write in. Now I try to read a chapter a week, yes, a week. It is a masterclass on writing, and as such, I plan on only digesting one lesson a week and use it while I write.

Allende briefly explains Latin America history, how since the very beginning of the Spaniard colonist, it has been a plagued by threats and wars against the freedom of expression. Reading fiction often forbidden, and centuries later her own. Her story is quite fascinating, with her first book being published outside of Chile and later finding its way to their people.

Yes, it was published in Spain, by Plaza & Janés. And people would smuggle the book without the covers into the country, until censorship was eliminated for books and theatre plays, because very few people could afford it anyhow. Booksellers would have it under the counter, and people would ask, in secret. (Allende, I. 2023.)[^1]

The story of “The House of Spirits” could be a story on its own! I will look it up and try to read it again now that I am 40, more mature and with an e-reader, where I can cut the number of words per page. I do have the vague notion of having studied it in school, but only by name, in class we only read short stories since economical situations did not allow us to get all the books we needed. We did read “Don Quixote”, and I remember how we all got a school copy which we needed to return at the end. We read it in pairs, per chapter, the teacher did not trust us to read it in full in a month, and she was probably right.

Back to “Storytelling”, in this second chapter, Allende talks about censorship, but also about self-imposed censorship. Which is quite a coincidence. Today I was thinking about the story I am writing for the WWC anthology, about how I thought it silly and yet the muse said —don't judge, write.

I thought about how I am trying to write every day one-hundred true words, even if they also feel strange; even if they feel pointless, because the point is to write and most importantly to write bravely. This only happen when I stop self-censuring. When I write and trust the words, trust the Muse.

The lesson this week —after writing about my Lucid Dreaming adventures and beginning the draft for my “silly story”— is precisely to stop self-censoring, to start writing. Who cares if not everyone enjoys it or even understand it? What matters is that I am writing, and that is doing more than most.

By the same token, please don't obey the critical voice in your head that sows doubt and squashes creativity. That's the most prevailing and dangerous form of self-censorship. This is especially true if you are a woman. Others may doubt your talent, but you should not. Be daring, be loud. (Allende, I. 2026. p. 27)[^2]

I will nurture my Muse. I will listen to it, I will feed it, I will turn it into a loyal companion instead of a critic and write the way I always wanted to write. I will be daring, and I will be loud.

[^1]: Taladrid, A. (2023, September 11). Isabel Allende’s Vision of History. The New Yorker. https://www.newyorker.com/culture/the-new-yorker-interview/isabel-allendes-vision-of-history

[^2]: Allende, I. (2026). Storytelling : a masterclass in crafting stories. Bloomsbury.

♡♡♡ Thank you for using RSS! | Reply by email, the post or drop by my guestbook! | or you could just, you know, make a blog if you haven't and use it to reply to other blogs. The more the merrier! What are you waiting for! I'll even add you to my blogroll. Feel free to ask me for help. ♡ find me here.

Django and LLMs - Lily's Blog

2026-11-08T00:00:00.000Z

Why I don’t use LLMs myself

I don’t like LLMs.

Firstly, I think they have deep ethical problems. Creating them depends on mass plagiarism of creative work. The energy demand to train and run a model is leading to the creation of vast numbers of data centres, often running on fossil fuels, which exacerbates global warming. Cleaning training data often relies on exploitation of impoverished people across the world. The companies creating LLMs claim that it might “destroy humanity” but continue anyway in search of profit and self-interest.

Run a private container registry with zot - Solene'%

2026-11-08T00:00:00.000Z

# Introduction

I wrote a few small programs for my home, mostly Prometheus exporters for IoT devices.  They run in containers, and until recently I had to build their images on my laptop and push them to the server.  This worked, but there was no test before deploying, and I was not updating the base image which is a security issue.

Now, the images are built on the CI of my Forgejo server, and pushed to a container registry in my network, then the servers pull them automatically when there is a new version.

This article is the first of a series of four about this setup:

* a private container registry with zot (this article)
* building container images with a Forgejo runner and Docker-in-Docker
* keeping the dependencies up to date with Renovate
* verifying the base images with cosign and hardening the images

The registry I use is zot, while I use "registry" (the reference registry from the Distribution project) as a pull-through cache.  Zot provides authentication and access control per prefix (like on an object storage bucket policy), which "registry" does not.

=> https://zotregistry.dev/ zot official website

In this blog post, you will learn how to set up zot as a private registry, with one account per project.

# zot

zot is a container registry following the OCI specification, which is the standard format for container images.  It is a single program written in Go, with a single JSON configuration.  It supports per image access control, deduplication of the storage, a retention policy and Prometheus metrics, so I did not need anything else around it.

I could have used Forgejo internal registry but as it is an Internet facing instance, I did not want to expose all containers I push on it, which is not possible here.  Alternatives seemed way too heavy for my simple need.

# Running zot

I run zot with podman as a quadlet, as usual.

In `/etc/containers/systemd/`, create the file `zot.container`:

```
[Container]
ContainerName=zot
# make sure to check the latest stable version instead of v2.1.22
Image=ghcr.io/project-zot/zot:v2.1.22
PublishPort=5010:5010
Volume=registry-data:/var/lib/registry
Volume=/etc/zot/config.json:/etc/zot/config.json:ro
Volume=/etc/zot/htpasswd:/auth/htpasswd:ro

[Service]
Restart=always

[Install]
WantedBy=default.target
```

The container images sent to zot are stored in the volume `registry-data`.

# Configuration

The configuration file can be daunting, but if you take a calm look on it, and use `jq` on it, it makes things a lot easier to grasp.

Here is my file `/etc/zot/config.json`, reduced to one project called `airthings`:

```
{
  "distSpecVersion": "1.1.1",
  "storage": {
    "rootDirectory": "/var/lib/registry",
    "dedupe": true,
    "gc": true,
    "gcDelay": "1h",
    "gcInterval": "24h",
    "retention": {
      "delay": "24h",
      "policies": [
        {
          "repositories": ["**"],
          "deleteReferrers": true,
          "deleteUntagged": true,
          "keepTags": [
            { "patterns": ["^latest$"] },
            { "patterns": [".*"], "mostRecentlyPushedCount": 10 }
          ]
        }
      ]
    }
  },
  "http": {
    "address": "0.0.0.0",
    "port": "5010",
    "realm": "registry",
    "compat": ["docker2s2"],
    "auth": {
      "htpasswd": { "path": "/auth/htpasswd" }
    },
    "accessControl": {
      "metrics": { "anonymousPolicy": ["read"] },
      "repositories": {
        "**": { "anonymousPolicy": ["read"] },
        "airthings/**": {
          "policies": [
            { "users": ["ci-airthings"], "actions": ["read", "create", "update"] }
          ],
          "anonymousPolicy": ["read"]
        }
      },
      "adminPolicy": {
        "users": ["admin"],
        "actions": ["read", "create", "update", "delete"]
      }
    }
  },
  "extensions": {
    "metrics": {
      "enable": true,
      "prometheus": { "path": "/metrics" }
    }
  }
}
```

Some explanations:

* any clients can pull the images without an account, this is fine because the registry is only reachable from my network and no container contains sensitive data in this context
* each project has its own account, which can only push images under its own prefix, so the CI of a project can not overwrite the images of another one
* only the `admin` account can delete images
* the retention keeps the tag `latest` and the 10 most recently pushed tags of each image, the images without a tag anymore are deleted after 24 hours
* `docker2s2` accepts images in the Docker format, because my CI builds with Docker, this will be explained in the next article

The accounts are in a htpasswd file with bcrypt passwords.  You can create an entry with `htpasswd` from the Apache tools (package `httpd-tools` on Fedora, `apache2-utils` on Debian), add `-c` the first time to create the file:

```
htpasswd -B /etc/zot/htpasswd ci-airthings
```

# Pushing and pulling

The CI pushes over HTTPS, through a reverse proxy only reachable from my VPN and from the CI runner.  On each server pulling from it, create `/etc/containers/registries.conf.d/internal-registry.conf`:

```
[[registry]]
location = "192.168.1.50:5010"
insecure = true
```

I made it easier for this guide, but you might want to use a TLS certificate or a reverse proxy in front of it instead of using plain HTTP.  In this case, remove `insecure = true`.

# Metrics

The configuration above enables the Prometheus metrics of zot on `/metrics`, and anyone in my network can read them without an account (this is the `metrics` entry in `accessControl`).  They give the storage size of the images, the requests, and push and pull statistics, which can help to see the registry growing or to check the servers really pull the new images.  The metrics access can be filtered on the reverse proxy in front of zot.

# Conclusion

zot was easy to setup, and the access control by prefix is exactly what I needed to give one account to each project.  So far, I did not have any issue with it, but I will have to check how to handle pruning old data from it one day as it currently holds everything pushed to it indefinitely.

Forgejo internal registry is still a solid choice if you are fine with its limitations, I am using it for public projects providing containers.

In a future article, I will explain how the Forgejo runner builds the images and pushes them to zot.

# Going further

zot has a web interface and can scan the images for vulnerabilities with tools like Trivy, I did not enable these extensions yet.

This does not cover how to handle retention properly.

Horible public key tricks: - Maurycy's Blog

2026-11-08T00:00:00.000Z

So, I've always been somewhat annoyed at SSL/TLS. It requires everyone to go through a complex "ACME" dance just to put up a public website. Worse, certificates expire every few months, so it's not a one and done thing: even with automation, maintaining a certificate requires care to ensure the ACME client always has access to DNS records or the web server.

... and the whole system doesn't even work because certificates are issued over plaintext connections, and trusted certificate aurthorities use very secure keys like "4"

There is prior art of protest SSL implementations, but I do actually want to encrypt web traffic. Passive eavesdropping is a real risk... but preventing it doesn't require the whole certificate thing: therefore, the best choice is a protest certificate.

The only part of the certificate I directly control is the public key. Therefore, the simplest way to obtain a bad certificate is use a vanity private key such as 313333333337 (one of the most eleet primes). However, while the resulting public key would be week, no one would know unless they actually try to break it.

A good protest should be obvious:

# openssl s_client -connect maurycyz.com:443 2> /dev/null \
    | sed -n /BEGIN/,/END/p

-----BEGIN CERTIFICATE-----
MIIFADCCA+igAwIBAgISBjst/cQvgUTu+O7siJYo8bAFMA0GCSqGSIb3DQEBCwUA
MDMxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQwwCgYDVQQD
EwNZUjIwHhcNMjYxMTA4MjE0NzM5WhcNMjcwMjA2MjE0NzM4WjAXMRUwEwYDVQQD
EwxtYXVyeWN5ei5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz
lkaPgD2IZPPtC6fB////You+dont+actually+have+to+pick+random+privat
e+keys//No+one+checks+these+things//A+certificate+aurthority+got
+away+with+the+number+4+for+a+year////8HzhFiAzSv/zKHf7l4u6d6d3w6
nOg7N/C2ra5QvNpFnZVzrS5IcZmvRdi0dcptavcB8s4ThHNZLhY414Mvdo5t0kr0
n8WFrydnc6NEMKDPiZxehnF5D3n7z1piI5YCsNcS0NVFb45+8QvBZrv0O2BSIKNE
7M9hcE00KsaSzZ3eDBsRAgMBAAGjggIoMIICJDAOBgNVHQ8BAf8EBAMCBaAwEwYD
VR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUZoonXxel
KC563vN2kbvwXTLBQgMwHwYDVR0jBBgwFoAUQBUtJnntMiCe35pyHdYyH4EMgQww
MwYIKwYBBQUHAQEEJzAlMCMGCCsGAQUFBzAChhdodHRwOi8veXIyLmkubGVuY3Iu
b3JnLzAnBgNVHREEIDAegg4qLm1hdXJ5Y3l6LmNvbYIMbWF1cnljeXouY29tMBMG
A1UdIAQMMAowCAYGZ4EMAQIBMC0GA1UdHwQmMCQwIqAgoB6GHGh0dHA6Ly95cjIu
Yy5sZW5jci5vcmcvNi5jcmwwggELBgorBgEEAdZ5AgQCBIH8BIH5APcAdgAAGl0a
HC2TdbZIVXj4L3Ghrm7vOX0pfIrjFXvK3uGgHgAAAaG9Vy0ZAAAEAwBHMEUCIEof
iI14E0jzfOz9woGKiiYR4pUAm/Dv9FmFWEr5ma8uAiEAyl2EMpURJ65Oe+FIFE6v
Uj4QomzFJ98qVqhQozQxcC4AfQAai51rjdeR0c0FSe22A1XWBrZPrTDbcf54jw/H
yPvEsQAAAaG9Vy2AAAgAAAUAFVVRHQQDAEYwRAIgTBocYGR/XcTqNx58xJh/pAme
q+w6fDl+NktKUuPBqZcCIFJU6/GE71s9OkORDBC4+XHiQWWxrHk8uuD6nTQzCtHS
MA0GCSqGSIb3DQEBCwUAA4IBAQAUIK5MyB3bhSFc6NOkC1UYYi2BQZN4zDfZMTD1
gGtnK7FCCNKvsanv9FIeGgr7e3A50TJhqIWH42uz9mQt8rnofwKVu7fJ77l/HZIf
oAqNol06AbtwM2I4vOEAZyfD3zAfL/3G70rGw4omDFpzX852Yi3Ou40wpHbdboYY
Bn58bZDvBVaUrKVdTdN+S5Ea2usWKgUjqfouz/VjnlEgLfcxqPwF2IPfPCOPKJH2
uIo3tnjx267OWY3O8nyxuOAxrBuP5fc8g2bEcKI5RewRWh7CCVZB23Ov5dyFQVcb
ICN41m494GUBgwqYpAjLgdIubvyoJzBpACGuIl2QlJza1p/y
-----END CERTIFICATE-----

First, let's look at mathematical framework of RSA. To generate a key, pick two large prime numbers (p and q) and multiply them to yeild the modulus (n). Pick a small number, e as public exponent.

The RSA public key is composed of the modulus (n) and the public exponent:

# Encryption requires knowing e (public)
cyphertext = plaintext^e mod n

The private key contains the modulus and the private exponent (d) which is chosen to be the multiplicate inverse of e modulo n. Exactly how d is found is not relevent, but the process requires knowing p and q.

# Decryption requires knowing d (pivate)
= cyphertext^d mod n

= plaintext^e^d mod n
= plaintext^(e*d) mod n
= plaintext^1 mod n
= plaintext

Ok, back to vanity keys. The standard value for e is 65537 (0x10001), because the small number of set bits makes encryption faster. In fact, the CA I used will refuse to sign keys with a non-standard public exponent, so I can't do anything funny there.

The modulus, n, is either 2,048 or 4,096 "user controlled" bits, so it's the ideal place to hide a message. However, to use the certificate, I'll need to find two large primes that multiply out to the vanity modulus.

My method starts by picking two random primes and calculating the resulting n value. Then, the bytes of n are modified to introduce message into the base64 encoding. Of course, the modified n is not the product of p and q, but this is fixable by setting q to n/p.

The resulting q value is very unlikely to be a prime (or integer), so I round it and find the next prime after the ideal q: which usually only requires changing the value of q by a few hundred. Since p and q are similar in size, a small change q only affects the least-sigifiant half of the product:

58174124 * 918491824 = 53432457262362176
(incrementing until the next prime...)
58174124 * 918491843 = 53432458367670532

As long as the message is embedded into the upper half of n, it's likely to survive undamaged. The original p and newly selected q can now be used to construct a functional RSA private key in the usual manner.

From here, it's really just a matter of getting a certificate aurthority to sign the key:

# Single domain
openssl req -new -key priv.pem -subj '/C=US/CN=example.com' > cert_request
certbot certonly --manual --csr cert_request

# Wildcard
cat > config<
[ req ]
req_extensions = req_ext

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = *.example.com
DNS.2 = example.com
EOF
openssl req -new -key priv.pem -config config -subj '/C=US/CN=example.com' > cert_request
certbot certonly --manual --csr cert_request

... although since base64 operates on groups of three byte, it is possible for the message to be misaligned and not readable. However, since the layout of the certificate is static, it is possible to adjust the message's placement until it works: this should take less than four attempts.

The result is a functional, trusted certificate with a longish message hidden in the public key. Renewal is done by resumbitting the CSR and repeating the ACME chalange, which can be automated.

Base64 is missing most punctuation, but it provides the full ASCII alphabet, and the ~150 (RSA-2048) or ~320 (RSA-4096) avalable charaters provides plenty of space for jokes. Another option would be to target the base16 displayed in most browser's certificate viewer: this would provide a lot more space (2 chars/byte instea of 0.75), but requires careful word choice.

As for security, this trick obviously reduces the entropy in the private key. I'm not aware of any factoring algorithms that could exploit key selection method, but I can't garantee they don't exist. The method may also produce a p and q that are close together, which makes it possible to easly factor n and recover the private key. A very small d value can also allow factorisation.

While I wouldn't trust these keys for anything important, they should be perfectly fine for serving a public website: modern TLS provides forward secrecy, so eavesdropping requires man-in-the-middle even if the private key is compromised.

https://tom7.org/httpv/httpv.pdf: [⭐ World's worst TLS server ]
/projects/badcert/gen.py: script to generate a vanity key

]]>

Bloggies '27 - Enter the Arena - AMONG CATS AND BOOKS

2026-11-07T18:20:09.720Z

Your blog is mine!

It's almost time for us mere bloggers to step into the arena again, break billiard cues in half, grab whatever improvised weapons we can find, and battle to the death. There can be only one. It's BLOGGIES time!

So celebrate with us! Find your favorite blog posts of the year. Read them again, share them, recommend them, caress them, love them. This is the time for everyone to stop what they're doing and read three random posts whenever the clock strikes the hour.

Following tradition, I've been ~~cursed~~ chosen to host this year's blogosphere tournament. Here's what you need to know:

Nominations are open NOW until December 31, 2026!

>>> NOMINATE YOUR FAVORITE POSTS HERE <<<

If you have no idea what I'm talking about, I'll just point you to Clayton's run from last year. He did a much better job explaining the whole thing than I will. There's also the archive if you want to dig into previous Bloggies.

Nominations are opening early to give you more time to find and submit your favorites, and me a fighting chance of sorting through everything before announcing the brackets in January. And to those of you who will forget and do it at the last minute, don't worry. I see you. I validate you as well.

No idea if this will work, but let's try it anyway.

HOW

There are 6 main categories this year, each with a tournament style bracket of 8 posts, or 16 if we've been particularly hard-working. We will crown the top 3 posts in each category.

First, you nominate the posts. That's where YOU come in. A community effort. See above. Once nominations close, I'll wiggle them down to a shortlist and make enemies along the way. Nomination counts will matter, but popularity alone won't decide who makes it.

I'll announce the brackets at least a month before voting so everyone has time to actually read the posts. Then all 6 categories will battle it out over the course of a week.

Yes, you can nominate yourself. Yes, you can tell others to vote for you. Even better, tell everyone about your favorite posts this year and promote each other.

You can nominate up to five posts per main category at a time and come back with more later. Just don't nominate the same post twice.

Any blog post published between January 1 and December 31, 2026, is eligible.

WHAT

This year the categories will be:

Theory. Tell me how games work and why we play them.
Gameable. Tell me something I can use in my game to torment players with.
Advice. Tell me what I'm doing wrong when running or playing games and how to do it better.
Critique. Tell me why books and games are good or bad.
Creative. Tell me about your sick worlds and show me your awesome art.
Meta. Tell me about the communities, drama and gossip.

The special bonus categories are still around and awarded separately:

Best Debut Blog. Tell me which new blog already has the coolest posts.
Best Series. Tell me about play reports and posts that got split into too many parts for their own good.

WHO

I'm hosting this year because you voted me into this position last year.

WHEN

Alright, here's my preliminary plan:

Nominations open. NOW
Nominations close. December 31, 2026
Nominees announced. Mid January (TBD)
Voting begins. Mid February (TBD)
Winners declared. Early March (TBD)

>>> NOMINATE YOUR FAVORITE POSTS HERE <<<

That's it for now!

Building a 32-bit EFI application on a 64-bit Linux system - Kevin Boone's website

2026-11-07T11:17:26.000Z

...and why you might want to.

Mostly indieweb builders - BlogFlock

Revisiting Leander v Sweden and Big Brother Watch - Bert Hubert's writings

Stickerbombed: Lenovo X1 Carbon Gen 14 Aura - マリウス

ARIN-prop-355: Clarification of Recipient Requirements for 8.3 Transfers - Home on American Registry for Internet Numbers

Problem Statement

Policy Statement

Ontology #2: wish you were here - lcamtuf’s thing

That which isn’t real

The logic of “maybe”

The abstractionist within

The Central Finite Curve

Using a Raspberry Pi Pico to control a large-scale model locomotive -- part 2 - Kevin Boone's website

Using a Raspberry Pi Pico to control a large-scale model locomotive - Kevin Boone's website

Veterans Day Closing Information - Home on American Registry for Internet Numbers

Build container images with a Forgejo runner and Docker-in-Docker - Solene'%

The race to secure record-like information for domains - Built on Shards of Silicon: Robert Alexander's Tech Blog

DNS and DNSSEC

DNSSEC is uncommon

The web approach

Case study: Email

The hostname mis-match problem

An insecure chain from the email address to the TLS certificate

A problem end-to-end encryption cannot solve

Non-analogous to the web

SMTP DANE

MTA-STS

MTA-STS challenges

Comparing MTA-STS and DANE

Improving MTA-STS

The race is on

Similar approaches

Complementary solutions

The DO's and Don'ts of Post-Quantum DNSSEC - Potaroo blog

First steps in bare-metal programming using UEFI -- part 6 - Kevin Boone's website

The web used to belong somewhere - Manuel Moreale — Everything Feed

Post on Josh Betz - Josh Betz

2026-11-08 Before Sunrise - Alex Schroeder’s Diary

2026-11-08 Before Sunrise

Nurture the Muse - Konfetti Explorations

Django and LLMs - Lily's Blog

Why I don’t use LLMs myself

Run a private container registry with zot - Solene'%

Horible public key tricks: - Maurycy's Blog

Related:

Bloggies '27 - Enter the Arena - AMONG CATS AND BOOKS

>>> NOMINATE YOUR FAVORITE POSTS HERE <<<

HOW

WHAT

WHO

WHEN

>>> NOMINATE YOUR FAVORITE POSTS HERE <<<

Building a 32-bit EFI application on a 64-bit Linux system - Kevin Boone's website