No private key leaves the build #14

Merged
marcos-mendez merged 3 commits from fix/no-shared-keys into 19.x 2026-09-29 01:33:23 -03:00
marcos-mendez commented 2026-09-29 01:10:08 -03:00 (Migrated from github.com)

Problem

keel-core#8: every published layer carries the SSH host keys openssh-server makes at install, the turnkey-ssl certificate and key (in /usr/share/turnkey-ssl and, through its postinst, in /etc/ssl/private where the services read them) and Webmin's unused miniserv.pem; lapp and postgresql add ssl-cert's snakeoil pair. Every machine built from a layer shares them. BRIEF section 5.3.

Fix

  • removelists-final/turnkey removes all of them as the last step of every build, after units and product conf scripts, so a child layer that installs a key generating package loses it too. ~ globs, so a layer without Webmin or ssl-cert passes over those lines.
  • overlays/turnkey.d/no-shared-keys: a dpkg path-exclude keeps a turnkey-ssl upgrade or reinstall from putting its key back. Measured with dpkg 1.22 in a scratch root: the file stays absent across a reinstall and dpkg --verify reports it missing with status 0, as it does for what localepurge removes.

Evidence

The test of this list is Keel-Linux/buildtasks' new layer_audit_keys, which scans the real tree at the end of every build and refuses a layer with any private key not in its inert list.

Deploying the three together

This is one of three pull requests for keel-core#8: Keel-Linux/inithooks (generate on the machine), Keel-Linux/common (remove from the build), Keel-Linux/buildtasks (refuse at export). Merging deploys nothing: the build host checkouts are updated by hand. The order that matters is deployment:

  1. Publish inithooks 2.3.6+keel6 to the archive (attended, signing). Until then a layer without keys would boot with no TLS certificate until 15regen-sslcert, which only restarts services already running.
  2. Update /turnkey/fab-keel/common and /turnkey/buildtasks-keel on the build host in the same sitting: the audit without the removals refuses every layer.
  3. Rebuild the chain and publish (attended). Images published before this still carry the keys; keel-host-keys replaces them on any machine made from one.
## Problem keel-core#8: every published layer carries the SSH host keys openssh-server makes at install, the turnkey-ssl certificate and key (in `/usr/share/turnkey-ssl` and, through its postinst, in `/etc/ssl/private` where the services read them) and Webmin's unused `miniserv.pem`; lapp and postgresql add ssl-cert's snakeoil pair. Every machine built from a layer shares them. BRIEF section 5.3. ## Fix - `removelists-final/turnkey` removes all of them as the last step of every build, after units and product conf scripts, so a child layer that installs a key generating package loses it too. `~` globs, so a layer without Webmin or ssl-cert passes over those lines. - `overlays/turnkey.d/no-shared-keys`: a dpkg `path-exclude` keeps a turnkey-ssl upgrade or reinstall from putting its key back. Measured with dpkg 1.22 in a scratch root: the file stays absent across a reinstall and `dpkg --verify` reports it `missing` with status 0, as it does for what localepurge removes. ## Evidence The test of this list is Keel-Linux/buildtasks' new `layer_audit_keys`, which scans the real tree at the end of every build and refuses a layer with any private key not in its inert list. ## Deploying the three together This is one of three pull requests for keel-core#8: Keel-Linux/inithooks (generate on the machine), Keel-Linux/common (remove from the build), Keel-Linux/buildtasks (refuse at export). Merging deploys nothing: the build host checkouts are updated by hand. The order that matters is deployment: 1. Publish `inithooks 2.3.6+keel6` to the archive (attended, signing). Until then a layer without keys would boot with no TLS certificate until `15regen-sslcert`, which only restarts services already running. 2. Update `/turnkey/fab-keel/common` and `/turnkey/buildtasks-keel` on the build host in the same sitting: the audit without the removals refuses every layer. 3. Rebuild the chain and publish (attended). Images published before this still carry the keys; `keel-host-keys` replaces them on any machine made from one.
Sign in to join this conversation.
No description provided.