Decision note 0016: mirror layout, channels and rollback #7

Closed
opened 2026-09-28 00:24:12 -03:00 by marcos-mendez · 0 comments
marcos-mendez commented 2026-09-28 00:24:12 -03:00 (Migrated from github.com)

Record the mirror layout and update policy as a decision note, numbered
0016 — 0014 and 0015 are being written concurrently, so do not take "the
next free number" at write time.

What it must state: blobs content addressed and never overwritten or deleted;
releases immutable, identified by release and revision; channels the only
mutable object, signed and carrying a timestamp and an expiry; rollback is
moving a pointer; an expired channel is an error at the client.

The reasoning that belongs in the note rather than in a commit message: why
versioning by release alone is insufficient (two publications of the same
release overwrite each other) and why a signed pointer with an expiry is not
optional (a stale or hostile mirror can freeze a client on a vulnerable release
simply by not updating, and without a timestamped signature the client cannot
tell that apart from "nothing new").

State also what happens to main: it stays the trunk and is always the latest,
release branches are cut only when the next Debian opens, and the forks keep
master so they remain mergeable upstream.

Implementation: Keel-Linux/apt and Keel-Linux/keel.

Record the mirror layout and update policy as a decision note, numbered **0016** — 0014 and 0015 are being written concurrently, so do not take "the next free number" at write time. What it must state: blobs content addressed and never overwritten or deleted; releases immutable, identified by release and revision; channels the only mutable object, signed and carrying a timestamp and an expiry; rollback is moving a pointer; an expired channel is an error at the client. The reasoning that belongs in the note rather than in a commit message: why versioning by release alone is insufficient (two publications of the same release overwrite each other) and why a signed pointer with an expiry is not optional (a stale or hostile mirror can freeze a client on a vulnerable release simply by not updating, and without a timestamped signature the client cannot tell that apart from "nothing new"). State also what happens to `main`: it stays the trunk and is always the latest, release branches are cut only when the next Debian opens, and the forks keep `master` so they remain mergeable upstream. Implementation: Keel-Linux/apt and Keel-Linux/keel.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Keel-Linux/handbook#7
No description provided.