From f9bba193745de8cfa3c5e7e6d38541277f0342f5 Mon Sep 17 00:00:00 2001 From: navigator Date: Sat, 3 Oct 2026 12:29:42 +0000 Subject: [PATCH] docs: progress of 2 and 3 October 2026, signed testing images and the first mesh nodes The home page gains a progress section and a status that names the current testing pre-releases (Keel Core 19.0-8, Keel Web 19.0-3). The security page records the withdrawn images as fixed, the key scan on every layer and image, the Debian-plus-Keel package sources and the two archive tracks. The cloud page says where the mesh stands, and the roadmap carries dated progress notes, Phase 5 as current, and MongoDB and CouchDB as deferred. HTML only, so the asset versions are unchanged. --- cloud.html | 8 ++++++-- index.html | 56 +++++++++++++++++++++++++++++++++++++++++++-------- roadmap.html | 9 +++++++-- security.html | 12 +++++++---- 4 files changed, 69 insertions(+), 16 deletions(-) diff --git a/cloud.html b/cloud.html index af09550..9fcee36 100644 --- a/cloud.html +++ b/cloud.html @@ -125,7 +125,7 @@

Cloud advanced

The mesh is the base, not an extra

-

WireGuard in Core; the rest decided, 0024

+

Two nodes joined, in testing WireGuard in Core; the rest decided, 0024

+
+ Where it stands, 3 October 2026 +

Phase 5 has started. Two Keel Web nodes in different locations are joined over a WireGuard overlay, declared in each node's instance spec and confirmed through the network safety window. Next is a one-command join, keel mesh invite on a node of the mesh then keel mesh join on the new one (decision 0048, in review), and etcd forms when the third node joins.

+

Open: the successor to HubDNS for nodes behind NAT whose IPv6 prefix changes. A PowerDNS overlay fed from etcd is the likely shape, not yet decided.

@@ -185,7 +189,7 @@

Directory replication

Backup and object storage

Decided, 0037 and 0038; Phase 7

+

Progress. The layers and images that carried shared keys were withdrawn on 2 October, and signed rebuilds replaced them on the testing channel: Keel Core 19.0-8 and Keel Web 19.0-3.

Done when the manifest schema is reviewed with WordPress, Odoo and Mastodon examples, the WordPress test image passes the maintainer's test, and no published layer carries a shared key.

@@ -123,6 +124,7 @@

Phase 1: Keel Core

  • Overlays shipped as .deb from the Keel repository (0036, 0039)
  • Simple and advanced mode screen (0028)
    • +

    Progress. Keel Core is in testing as a signed pre-release, built from Debian and the Keel archive only. First boot asks for the FQDN, runs unattended without hanging, and installs security updates without blocking the boot.

    Done when a Core image boots in simple installation, emits a YAML that re-applies as a no-op, runs no etcd and no active CrowdSec, and upgrades one overlay with apt upgrade on the testing track.

    @@ -157,6 +159,7 @@

    Phase 3: Keel Web

  • Anubis packaged in the Keel repository
  • nginx overlay and the Keel Web recipe; Coraza and Anubis disabled in simple
    • +

    Progress. Keel Web is in testing as a signed pre-release. In simple mode it serves HTTPS with the machine's own certificate; cloud mode adds Coraza and Anubis.

    Done when Keel Web in advanced mode blocks a Core Rule Set test payload, challenges a browser through Anubis, lets exempt crawlers through, and in simple mode is plain Nginx.

    @@ -177,7 +180,7 @@

    Phase 4: runtimes, and WordPress on Keel PHP

    -
  • +
  • @@ -193,6 +196,7 @@

    Phase 5: mesh control plane

  • Syncthing overlay, send-only and receive-only flipped on promotion (0032)
  • Monit summary to etcd, mesh alerting by watch (0040)
    • +

    Progress. Under way. Two Keel Web nodes in different locations are joined over a WireGuard overlay, declared in each node's instance spec. Next: a one-command join, keel mesh invite and keel mesh join (decision 0048, in review), and etcd at the third node.

    Done when a three-container gate installs the second and third node by discovery, fails over automatically, moves the service address, flips the Syncthing folders, fails back after catch-up, and reports each node's Monit summary through etcd.

    @@ -239,6 +243,7 @@

    Open architecture items

    diff --git a/security.html b/security.html index f6414d3..0777e9b 100644 --- a/security.html +++ b/security.html @@ -97,15 +97,16 @@

    On this page

    Keys and identity: none in the image

    -

    An image that carries a private key hands that key to everyone who downloads it. Keel removes them in three places, so that none depends on another being remembered. Built; test layers to be republished

    +

    An image that carries a private key hands that key to everyone who downloads it. Keel removes them in three places, so that none depends on another being remembered. In the current testing images

    • The build removes them. SSH host keys, the TLS key and certificate, Webmin's key and the snakeoil pair are removed before a layer is exported, and every layer is exported with an empty machine-id.
    • The export refuses them. The layer export audits the tree and refuses one that still holds a private key.
      • +
    • A scan checks every layer and image. It verifies that none carries SSH host keys, TLS private keys, a Webmin certificate or snakeoil keys, on every build.
    • Every boot replaces them. A unit that runs before SSH, Webmin, the web servers and PostgreSQL generates what is missing and replaces any key on the list of published ones.
    -
    - Not done yet -

    The test layers on the mirror were built before the fix, and an attended release replaces them (Phase 0 of the roadmap). Until then the boot unit is what protects a machine made from one. ISO and VM images still ship the build's machine-id (tracker#24).

    +
    + Fixed +

    The test images and layers published before the fix carried keys made at build time. They were withdrawn on 2 October 2026 and replaced by signed rebuilds that pass the scan; the notice on the mirror says how to give a machine made from an old one its own keys. The ISO build now leaves the machine-id empty too (tracker#24).

    @@ -155,6 +156,7 @@

    What each installation mode enables

    An operator can depart from a default on one machine, in the spec. A disabled overlay is still installed, so turning it on is a change to the spec, not a new image.

    +

    In the current testing image, Keel Web in simple mode serves HTTPS out of the box with the machine's own certificate, a Keel placeholder page and Keel error pages. Let's Encrypt is set up from the console, prefilled from the instance spec. In testing

    @@ -202,6 +204,8 @@

    Secrets are references, never values

    Where packages come from

    Every image rebuilds from the project's own archive: a dated, pinned pool, verified by the build before it is read. What Debian 13 does not carry, Keel builds from source and signs in the same repository: Coraza's Nginx connector, Anubis and Garage. Anubis and Garage have packaging in progress in Debian, and Keel coordinates with those efforts rather than packaging in parallel. Decided, 0039

    +

    The testing images are built from Debian and the Keel archive only, with no TurnKey archive. The TurnKey tools Keel still uses, turnkey-ssl, netinfo, conffile, sysinfo, version, tkl-installer and the dhcpcd glue, are Keel forks published there, and turnkey-ssl no longer ships a key. In testing

    +

    The archive, archive.keellinux.org, has two tracks: trixie-testing, where everything lands first, and trixie, the stable track. Promotion to stable is a maintainer's act. Images and the archive are signed, and the keyring is at archive.keellinux.org/keel-archive-keyring.asc.