Problem

CI never verifies that the channel authenticates. guix git authenticate appears nowhere under .github/.

As a result, main stopped authenticating on 2026-08-08 and it went unnoticed until 2026-08-23 — two weeks in which any guix time-machine pinned at or after the bad commit would fail outright. This is not a degraded mode: authentication is a hard gate (channels.scm:480), so the channel aborts before computing any derivation.

What broke, and why it was invisible

Two commits, both the result of entirely ordinary actions:

4cbdcf21 — a one-line README edit made through the GitHub web UI. GitHub signs web-UI commits with its own web-flow key (B5690EEEBB952194), which is not in the channel keyring. It was marked [skip ci], so nothing ran regardless.
25c88f2a — a commit signed with an SSH key (sk-ssh-ed25519). Guix channel authentication is OpenPGP-only; commit-signing-key parses the gpgsig header with string->openpgp-packet, which cannot represent an SSH signature.

Neither is flagged anywhere in normal workflow. GitHub displays both as "Verified". git log shows the first as st=U, which is easy to miss and means something different from what it looks like.

The failure mode is hostile

Guix does not emit a clean diagnostic — it crashes with a backtrace:

guix/openpgp.scm:267  (openpgp-format-fingerprint 13071995811931693460)
In procedure bytevector-u16-ref: Wrong type argument in position 1
  (expecting bytevector): 13071995811931693460

This is an upstream bug: the missing-key error path in git-authenticate.scm:163 passes an integer key ID to openpgp-format-fingerprint, which expects a bytevector. The underlying condition is correct (unknown signing key) but it cannot report it. The integer decodes to 0xB5690EEEBB952194.

Anyone hitting this sees a Guile stack trace with no indication that the real problem is an unauthorized commit.

Proposed check

Add a job that runs on push and PR:

- uses: actions/checkout@v4
  with:
    fetch-depth: 0          # authentication walks from the introduction commit

- name: Fetch keyring branch
  run: git fetch origin keyring:keyring

- name: Authenticate channel
  run: |
    guix git authenticate \
      06e8707cac44731b16bfc46b3fb5c34427fc5efe \
      "E39D 2B3D 0564 BA43 7BD9  2756 C38A E0EC CAB7 D5C8"

Implementation notes

fetch-depth: 0 is required. Every existing checkout in .github/workflows/ is shallow (the actions/checkout default), and authentication needs the full history back to the introduction commit.
The keyring branch must be fetched explicitly. actions/checkout only fetches the target ref, and load-keyring-from-reference resolves the keyring from a branch ref.
The command exits non-zero on failure and is fast — it authenticates ~12 new commits in seconds, and caches results in ~/.cache/guix/authentication/.
It could live in its own lightweight workflow rather than being bolted onto the existing build jobs, so it still runs when a change is [skip ci]-adjacent or touches no packages.

Also worth considering

Branch protection on main to prevent web-UI commits, which is what produced 4cbdcf21. The CI check catches it after the fact; protection prevents it.
The local pre-push hook. guix git authenticate installs pre-push and post-merge hooks in the working clone on first run. That already caught one bad push during this cleanup, but it only protects clones where the command has been run at least once — it is not a substitute for a CI check.
Nine other remote branches still carry the unauthenticatable commits (v0.10.2-rc1-signed, v0.10.2-rc1-signed-fix-tag, boot1-lite, sbellem-patch-1, and others). They are off main and harmless, but any of them would fail authentication if pinned. A check that runs on all branches would surface this.

Context

Fixed on main by rewriting 4cbdcf21..main with re-signed commits; main now authenticates cleanly (exit 0). This issue is about preventing a recurrence, which is currently entirely reliant on the committer remembering.

Activity

No activity yet.