Complete neutral security fixtures

These are the exact retained neutral Security recipes for arm64 and amd64, with independent host policies, portable bindings, material receipts, raw upstream indexes, and the previously inspected final-image identity. Both cover all three operation families. The production qualification records 887/888 checks. No binary material or secrets are included. The public owner approval reference describes this historical fixture; another host must independently accept its policy and availability before use.

Canonical recipe SHA256: arm64 fb7e99c8334a93c57d9dd626a92c6851cf8e044af5e332355e28b8f2b2719c4f; amd64 a3a809007eba3feadf626712c75bfe89543d451d228d6c27225a07516b3fbd83. Recipe files are the exact canonical serializer output. Binding path changes do not alter identity. target-platform.json is a retained observation, never an expected ID for a fresh build; the sample resolves the actual new local image itself.

Acquire the exact materials

Work from the repository root. The sample resolves each relative localPath against the directory containing bindings.json. The receipt path fields use the same base. The preparer runs from the repository root and prefixes each declared destination with that platform fixture directory. After resolution, task-owned captures remain under .gstack/tmp/issue-887-neutral/arm64/ or amd64/, named by material ID. Never commit that binary directory. Every filename, exact byte length and SHA256 is in the platform's materials.json.

1. Copy the checked-in raw source-index.json, runtime-index.json and frontend-index.json into the corresponding task-owned paths without reserializing them. Their bytes hash to the original index digests. The neutral text theme is already checked in at shared/theme.properties; preserve its exact 19 bytes and no BOM. The signed keyring is captured from /usr/share/keyrings/ubuntu-archive-keyring.gpg in the retained Temurin graph and must hash to 80a36b0a6de2f69f49d2df75ef473ccde121e9e190b9ea01d20a4f63778d5c31 (3,607 bytes). Never discover/trust a replacement key from a live server.
2. Obtain the exact source-oci, runtime-oci, and frontend-oci archive objects from the consumer material owner's retained store, verify each materials.json hash/length, and preserve them unchanged. Their upstream registry authorities are quay.io/keycloak/keycloak, docker.io/library/eclipse-temurin, and docker.io/docker/dockerfile; exact indexes/manifests/configs/diff IDs are in recipe.json. The frontend selected manifest is arm64 in both retained recipes. Pulling a tag or running docker save anew is not a way to reproduce the exact tar hash. If retained bytes are unavailable, stop and apply the rebuild-availability policy. A newly captured graph/archive requires explicit reviewed material/policy/recipe identities and fresh proof.
3. Acquire every non-host material from its exact HTTPS URI in materials.json to its material-ID path. Verify SHA256 and byte length before capture. The table below lists the arm64 URLs; amd64 uses its complete receipt for its platform-specific package index and three Debian URLs. Do not follow an unapproved redirect, use a moved snapshot, or substitute a Maven mirror. The SDK repeats provenance and signed-index verification even for local cache bindings.
4. Verify all 41 bound material IDs are present, their lengths do not exceed maxBytes, and every digest matches. All 41 local bindings intentionally remain in CapturedHostInputs; only materials explicitly marked capturedHostInput: true omit HTTPS URI. Downloaded/cached materials still require the policy's exact origin/namespace authorization. Never mark an unavailable downloadable material as host-captured to bypass authorization.

No retained store URL is invented here: distribution is host-owned and availability is an explicit prerequisite. The receipt supplies exact authorities and bytes, while the owner supplies restricted storage access privately. This fixture makes a missing capture actionable; it does not promise upstream indefinite retention or a one-command download of private archive objects.

Execute and reject a wrong identity

Use the complete commands in the example README. They use fresh task-owned snapshots/context/evidence paths. Choose a supported host/frontend combination and platform explicitly; the target platform alone is not a host compatibility promise. --wrong-identity uses a fresh capture directory, changes only the actual resolved config identity and must reject without evidence. Compare evidence by exact immutable identity and operation checks, never by the local tag or a fresh build's equality to target-platform.json.

Prepare portable bindings without changing the recipe

The optional prepare.sh uses POSIX shell plus sha256sum (Linux) or shasum -a 256 (macOS); it needs no Python, jq or SDK build. The host first places each exact retained/downloaded non-index object in its private digest store under its lowercase SHA256 filename. Index JSON and the text theme come from this checkout. The script verifies exact length and hash before copying, checks copied bytes, preserves existing mismatched destinations, and checks the canonical recipe digest before and after preparation. A failed preparation may leave earlier verified cache objects, but creates no accepted SDK snapshot or passing evidence. Retry only after classifying any partial owned copy.

sh examples/auth-keycloak-security-recipes/fixtures/prepare.sh arm64 /owned/digest-store

/owned/digest-store is the host's private storage argument, not a checked-in path or a supplied distribution endpoint. Run this from the repository root and use the same working directory for the sample commands. Every destination is the platform fixture directory joined with the relative path in bindings.json; for example ../../../../.gstack/tmp/issue-887-neutral/arm64/source-oci resolves to the repository-root cache, and ../shared/theme.properties resolves to the checked-in theme. Run the preparer and documented sample commands from the repository root; changing their working directory would break command-line project/JSON paths even though binding paths remain relative to their JSON file. For amd64 select amd64. The arm64 preparer and portable path layout have now passed actual execution: all 41 bound materials matched their declared lengths and hashes, and the canonical recipe remained unchanged. The compiled sample then passed the complete build/resolve/inspect/evidence flow with 887 checks; its wrong-identity control rejected without forbidden passing evidence. See the integrated v3 qualification for the retained receipt, 16 stage events and actual Docker/buildx observations. This seeded material-store run is not a cold-cache or human novice measurement; the amd64 portable preparer is not claimed executed by this arm64 proof.