a release the iso could have taken down with it

The ISO was built before the publish step, so a live session that failed
to reach a desktop would have failed the job before the release existed
and taken the binary down with it. The comment on the attach step says
the opposite in as many words: an ISO that failed to attach should not
take the binary's release down with it. The build now runs after the
release exists, and is an addition to something that has already
happened.

The switch that turns it on could not reach the trigger that matters. A
tag is a push event and the inputs context is empty for those, so
defaults declared under workflow_dispatch and workflow_call never
materialise, and the comment telling you to flip the default described
something that could not affect a release. One ATTACH_ISO at job level
now: the push path reads a literal, every other trigger reads its input.

And the ISO would have been attached unsigned. SECURITY.md says every
release asset is signed with Sigstore, and that has to stay true of the
asset that becomes a bootable machine; a checksum beside it is served
from the same page, so anything that can replace one can replace the
other. It gets a cosign bundle like the binary.

Also: the runner disk it reclaims was a shorter list than the CI job
that proves the same build, which is the wrong way round for the path
with less headroom.

Separately, a __pycache__ entry, and the .pyc that was committed for want
of one. It is invalidated by any fresh clone, so nothing would have run
it, but a binary nobody can read does not belong in a repository whose
case rests on being auditable.

Author: Letdown2491

.github/workflows/release.yml

@@ -41,6 +41,17 @@ env:
 jobs:
   release:
     runs-on: ubuntu-latest
+    env:
+      # Whether a release carries the live ISO, decided in one place.
+      #
+      # A tag is a `push` event, and the `inputs` context is empty for
+      # those: defaults declared under workflow_dispatch and
+      # workflow_call never materialise on a push. So the tag path — the
+      # only trigger that actually cuts a release — reads the literal
+      # below, and every other trigger reads its input verbatim. Flip
+      # 'false' to 'true' to start attaching the ISO; the steps at the
+      # end of this job say why it is off.
+      ATTACH_ISO: ${{ github.event_name == 'push' && 'false' || inputs.attach_iso }}
     steps:
       - uses: actions/checkout@v7
 
@@ -214,32 +225,6 @@ jobs:
             function flush() { if (buf != "") { print buf; buf = "" } }
           ' section.md > reflowed.md && mv reflowed.md section.md
 
-      # Off by default, and deliberately so. ci.yml builds and boots this
-      # ISO on every push, which is where its failures should be found;
-      # attaching it to a tag means a 1.8 GB asset whose first real
-      # exercise happens during a release. Turn this on once that job has
-      # a run history, by dispatching with attach_iso or flipping the
-      # default. Until then a release carries the binary, as it always
-      # has, and the ISO is a workflow artifact.
-      - uses: ./.github/actions/kvm
-        if: inputs.attach_iso && steps.what.outputs.publish == 'true'
-
-      - name: live ISO
-        id: iso
-        if: inputs.attach_iso && steps.what.outputs.publish == 'true'
-        env:
-          QEMU_VGA: virtio-vga
-          QEMU_DISPLAY: none
-        run: |
-          set -euo pipefail
-          sudo rm -rf /usr/share/dotnet /usr/local/lib/android /opt/ghc || true
-          cargo build --locked
-          ./scripts/smoke.sh --iso --keep niri
-          name="kuma-${{ steps.what.outputs.tag }}-x86_64.iso"
-          mv vm-smoke/niri-iso/KUMA.iso "$name"
-          sha256sum "$name" > "$name.sha256"
-          echo "name=$name" >> "$GITHUB_OUTPUT"
-
       - name: publish
         if: steps.what.outputs.publish == 'true'
         run: |
@@ -274,15 +259,68 @@ jobs:
         env:
           GH_TOKEN: ${{ github.token }}
 
+      # Everything below runs *after* the release exists, and that
+      # ordering is the point: building the ISO means a full image build
+      # and a QEMU boot with a serial-console assertion, so putting it
+      # ahead of `publish` meant a live session that failed to reach a
+      # desktop took the binary's release down with it. The ISO is an
+      # addition to a release that has already happened.
+      #
+      # Off by default, and deliberately so. ci.yml builds and boots this
+      # ISO on every push, which is where its failures should be found;
+      # attaching it to a tag means a 1.8 GB asset whose first real
+      # exercise happens during a release. Turn it on by flipping the
+      # `|| false` below to `|| true`, once that job has a run history.
+      #
+      # Read through `env` rather than `inputs.attach_iso` directly
+      # because a tag is a `push` event, and the `inputs` context is empty
+      # for those: defaults declared under workflow_dispatch and
+      # workflow_call never materialise there. Testing the input alone
+      # meant the documented way to switch this on could not affect the
+      # only trigger that actually cuts a release.
+      - uses: ./.github/actions/kvm
+        if: env.ATTACH_ISO == 'true' && steps.what.outputs.publish == 'true'
+
+      - name: live ISO
+        id: iso
+        if: env.ATTACH_ISO == 'true' && steps.what.outputs.publish == 'true'
+        env:
+          QEMU_VGA: virtio-vga
+          QEMU_DISPLAY: none
+        run: |
+          set -euo pipefail
+          sudo rm -rf /usr/share/dotnet /usr/local/lib/android /opt/ghc \
+                      /usr/local/share/boost "$AGENT_TOOLSDIRECTORY" || true
+          cargo build --locked
+          ./scripts/smoke.sh --iso --keep niri
+          name="kuma-${{ steps.what.outputs.tag }}-x86_64.iso"
+          mv vm-smoke/niri-iso/KUMA.iso "$name"
+          sha256sum "$name" > "$name.sha256"
+          echo "name=$name" >> "$GITHUB_OUTPUT"
+
+      # SECURITY.md says every release asset is signed with Sigstore, and
+      # that has to stay true of the asset that becomes a bootable
+      # machine. A checksum beside the file is not a substitute: it is
+      # served from the same page, so anything that can replace one can
+      # replace the other.
+      - name: sign the live ISO
+        if: env.ATTACH_ISO == 'true' && steps.what.outputs.publish == 'true'
+        run: |
+          set -euo pipefail
+          cosign sign-blob --yes \
+            --bundle '${{ steps.iso.outputs.name }}.bundle' \
+            '${{ steps.iso.outputs.name }}'
+
       # Uploaded separately rather than templated into the file list
       # above, so the release exists either way: an ISO that failed to
       # attach should not take the binary's release down with it.
       - name: attach the live ISO
-        if: inputs.attach_iso && steps.what.outputs.publish == 'true'
+        if: env.ATTACH_ISO == 'true' && steps.what.outputs.publish == 'true'
         run: |
           set -euo pipefail
           gh release upload '${{ steps.what.outputs.tag }}' \
             '${{ steps.iso.outputs.name }}' \
-            '${{ steps.iso.outputs.name }}.sha256'
+            '${{ steps.iso.outputs.name }}.sha256' \
+            '${{ steps.iso.outputs.name }}.bundle'
         env:
           GH_TOKEN: ${{ github.token }}

.gitignore

@@ -1,5 +1,10 @@
 /target
 /Containerfile
+# CPython writes these beside any script it imports or compiles, and the
+# name carries the interpreter version, so one ran on a laptop and got
+# committed. A binary nobody reads has no business in a repository whose
+# case rests on being auditable.
+__pycache__/
 # vm, vm-cosmic, vm-smoke, and any future disk directories
 /vm*
 /.claude

CHANGELOG.md

@@ -28,7 +28,9 @@ by building against it rather than by reading its release notes.
   installer media has no disk to inspect and its account has no password for
   ssh to use. Attaching the ISO to a release is wired but off by default,
   waiting on this job having a run history rather than on a tag being the
-  first real test.
+  first real test. When it is turned on the ISO is signed like every other
+  release asset and the build runs after the release exists, so a live
+  session that fails to come up cannot take the binary's release with it.
 - Every image now refuses an unsigned kuma update. Images carry kuma's
   signing key at `/etc/pki/containers/kuma.pub` and a
   `/etc/containers/policy.json` requiring a valid signature for
@@ -48,9 +50,12 @@ by building against it rather than by reading its release notes.
   answer, which left a stranger whose machine did not boot with nothing
   useful to paste. `user.password_hash` is removed, by parsing rather than by
   rewriting lines, because the value can be quoted four ways and a report is
-  pasted by somebody who will not read it first. A declaration kuma cannot
-  parse is omitted rather than pasted raw: not being able to redact a file is
-  not a reason to publish it.
+  pasted by somebody who will not read it first. The same goes for anything
+  else on a short list of secret-bearing key names, wherever in the file it
+  sits, and a secret that survives the redaction costs the report its
+  declaration rather than getting published. A declaration kuma cannot parse
+  is omitted rather than pasted raw: not being able to redact a file is not a
+  reason to publish it.
 - Fedora 45 bases are named Callisto, after the nymph Zeus placed in the sky
   as Ursa Major. Bear names follow the alphabet where a letter has a name
   worth using.