The appliance still resolves apt, security and its vendor through TurnKey #6

New issue

Closed

opened 2026-09-28 00:39:05 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 00:39:05 -03:00

(Migrated from github.com)

Measured on the wordpress-demo container, 2026-09-28. Four ways a Keel
appliance still depends on, or reports to, TurnKey's infrastructure.

1. Three enabled apt suites over plain HTTP, and one of them is security

/etc/apt/sources.list.d/sources.sources:

Types: deb
URIs: http://archive.turnkeylinux.org/debian
Suites: trixie
Signed-By: /usr/share/keyrings/tkl-archive-keyring.gpg

Types: deb
URIs: http://deb.debian.org/debian
Suites: trixie

/etc/apt/sources.list.d/security.sources.sources has the same shape for
trixie-security, with TurnKey's entry before security.debian.org. A
third file, turnkey-testing.sources, enables trixie-testing.

All three are plain http, all three are signed by TurnKey's key, and in both
files TurnKey's entry precedes Debian's. Security updates for an appliance this
project calls sovereign are resolved through a third party.

Note the filenames: sources.sources and security.sources.sources. The
doubled suffix looks like a defect in whatever generates them; worth checking
while here.

2. apt announces the exact appliance to every archive it contacts

/etc/apt/apt.conf.d/01turnkey:

Acquire::http::User-Agent "TurnKey APT-HTTP/1.3 (turnkey-wordpress-19.0-trixie-amd64)";

Written by mk/turnkey.mk beside /etc/turnkey_version. Every archive the
machine talks to learns the appliance and the version. That is a Keel appliance
identifying itself as someone else's product and leaking its own inventory.

3. The dpkg vendor is TurnKey

/etc/dpkg/origins/ holds TurnKey, debian and default, with default
resolving to TurnKey. Bug reporting tools therefore point at TurnKey's tracker.

Order, which matters

Removing the archive sources is the last step, not the first. Everything
those suites provide has to come from our own pool first, or the appliance stops
building. Items 2 and 3 can go now: they cost nothing and neither is load
bearing.

I could not determine which installed packages actually resolve to the TurnKey
archive — apt-cache policy on that container reported only
/var/lib/dpkg/status, so its apt lists were not populated at the time.
Establishing that list is the first task here, and it decides how much work
item 1 really is.

What closes this

The appliance's apt configuration names Keel, not TurnKey, and leaks no
appliance identity in a User-Agent.
dpkg-vendor answers Keel, and bug reporting points at our tracker.
A measured list of what the TurnKey suites still provide, and a plan per
package: in our pool, replaced, or dropped.
Anything still fetched from a third party is fetched over https.

Org-wide context: Keel-Linux/tracker#15.

Measured on the `wordpress-demo` container, 2026-09-28. Four ways a Keel appliance still depends on, or reports to, TurnKey's infrastructure. ## 1. Three enabled apt suites over plain HTTP, and one of them is security `/etc/apt/sources.list.d/sources.sources`: Types: deb URIs: http://archive.turnkeylinux.org/debian Suites: trixie Signed-By: /usr/share/keyrings/tkl-archive-keyring.gpg Types: deb URIs: http://deb.debian.org/debian Suites: trixie `/etc/apt/sources.list.d/security.sources.sources` has the same shape for `trixie-security`, with TurnKey's entry **before** `security.debian.org`. A third file, `turnkey-testing.sources`, enables `trixie-testing`. All three are plain `http`, all three are signed by TurnKey's key, and in both files TurnKey's entry precedes Debian's. Security updates for an appliance this project calls sovereign are resolved through a third party. Note the filenames: `sources.sources` and `security.sources.sources`. The doubled suffix looks like a defect in whatever generates them; worth checking while here. ## 2. apt announces the exact appliance to every archive it contacts `/etc/apt/apt.conf.d/01turnkey`: Acquire::http::User-Agent "TurnKey APT-HTTP/1.3 (turnkey-wordpress-19.0-trixie-amd64)"; Written by `mk/turnkey.mk` beside `/etc/turnkey_version`. Every archive the machine talks to learns the appliance and the version. That is a Keel appliance identifying itself as someone else's product and leaking its own inventory. ## 3. The dpkg vendor is TurnKey `/etc/dpkg/origins/` holds `TurnKey`, `debian` and `default`, with `default` resolving to TurnKey. Bug reporting tools therefore point at TurnKey's tracker. ## Order, which matters **Removing the archive sources is the last step, not the first.** Everything those suites provide has to come from our own pool first, or the appliance stops building. Items 2 and 3 can go now: they cost nothing and neither is load bearing. I could not determine which installed packages actually resolve to the TurnKey archive — `apt-cache policy` on that container reported only `/var/lib/dpkg/status`, so its apt lists were not populated at the time. Establishing that list is the first task here, and it decides how much work item 1 really is. ## What closes this - The appliance's apt configuration names Keel, not TurnKey, and leaks no appliance identity in a User-Agent. - `dpkg-vendor` answers Keel, and bug reporting points at our tracker. - A measured list of what the TurnKey suites still provide, and a plan per package: in our pool, replaced, or dropped. - Anything still fetched from a third party is fetched over https. Org-wide context: Keel-Linux/tracker#15.