The build verifies the staging archive instead of reading it unverified

[marcos-mendez]

Closes part of Keel-Linux/tracker#7 for this recipe.

The defect

The staging distribution was given its own signing key so that a nightly could
sign itself and so appliance recipes could stop reading it through
[trusted=yes], which switches verification off. Signing landed; verification
did not, so a layer build printed

W: OpenPGP signature verification failed: file:/srv/keel-apt/repo
   trixie-staging InRelease: Missing key
   8CFD1A4841448B2227341CEB202CACBD0E97090A

and carried on, installing the project's own packages unverified.

How the build verifies now

• the public half of the staging key is installed into the build tree as
  /etc/apt/keyrings/keel-staging-keyring.asc, taken from
  /srv/keel-apt/keys/keel-staging-keyring.asc, where bin/publish of
  Keel-Linux/apt now leaves the keyring of whichever distribution it signed;
• the source entry names it through signed-by and no longer says
  trusted=yes, which no file in any of the four recipes does any more;
• apt-get update runs with --error-on=any, so a warning is an error;
• bin/keel-archive-check makes the same checks itself, with gpgv, because
  the tree that is about to be configured is checked at a step where no
  apt-get update runs: the copied index is the live one, the entry names the
  keyring and the distribution, nothing in the tree says trusted=yes, and the
  signature on the copied InRelease verifies against the named fingerprint.

How it fails

Measured against the real archive on the build host, in a scratch apt root:

tree	apt
[trusted=yes], no keyring	W: ... Missing key, exit 0, packages installed
signed-by, no keyring	E: The repository ... is not signed, exit 100
signed-by, the wrong key	E: The repository ... is not signed, exit 100
signed-by, the staging key	Get:1 ... InRelease, exit 0

bin/keel-archive-check exits 1 with a FATAL [archive-check <step>] line in
each of those failures, before a package is installed.

The keyring does not reach the image

The conf script removes it with the source entry and the copy of the archive,
and Keel-Linux/common#4 adds all three to common/removelists-final/turnkey,
which is the arrangement that holds whether or not a recipe remembers.

Also here

conf.d/zzz-keel-archive refuses to enable the appliance own source while the
build time keyring is still in the image, and the boot test reads the assembled
rootfs and fails when the archive copy, the source entry or the staging keyring
is there. That is the only place that looks at a finished image and says so,
which is what "not in the image" has to mean.

Test plan

• COVERAGE_THRESHOLD=97 tests/coverage.sh: 99.07 percent (533/538) over
  194 bats tests. bin/keel-archive-check 100 (52/52),
  zz-project-packages 100 (31/31), zzz-keel-archive 100 (26/26),
  boot-test-lib.sh 98.95 (282/285)
• shellcheck -S warning bin/keel-archive-check clean
• appliance / build-and-boot against the rebuilt layer

[marcos-mendez]

Pushed a second commit: the trusted=yes the check refuses is one on the project archive, not one on every apt source in the build tree. The captured pool of decision 0012 sets Trusted: yes on purpose for a file: index generated on the build host, so the wider rule would have failed every pinned build. Same change as keel-mariadb#13, keel-postgresql#9 and keel-nodebb#12. bin/keel-archive-check is 100 percent (54/54) over 27 bats tests; the repository total is 99.07 percent (535/540) over 196 tests.

appliance / build-and-boot cannot go green here until the published chain is whole again: wordpress.manifest records parent_sha256 0adca434 and the published mariadb is 974fa6bb, so keel verify refuses the chain, which is what the rebuild this pull request is part of fixes. It is re-run once both layers are published.