git:20261004.9c07561 to git:20261005.9fb9c96

---

# SPDX-License-Identifier: Apache-2.0

# https://www.apache.org/licenses/LICENSE-2.0

name: verify-rc

family: release-management

organization: ASF

mode: Triage

requires_config:

- release-build.md

- release-management-config.md

description: |

Read-only pre-flight verification of a staged release candidate (RC)

for `<upstream>`. Checks artefact integrity (GPG signatures and

checksums), Apache RAT licence headers, NOTICE/LICENSE completeness,

prohibited-binary absence (including `.pyc` / `__pycache__`),

published-JVM-artefact compliance (POM licence/developers/scm,

podling incubation disclaimer, companion `-sources.jar` /

`-javadoc.jar` with their own signatures and checksums), source-tree

integrity (no dangling symlinks or broken internal references),

version-string consistency, and — optionally, per

`release-build.md § Reproducibility checks` — reproducibility: the

source archive is rebuilt from the tag with `repro-archive` and

compared byte-for-byte with the staged artefact, and convenience

binaries are rebuilt and compared (mandatory for ASF projects with

automated release signing, as the policy's validation on trusted

hardware). Emits a structured PASS / PASS-WITH-WARNINGS / FAIL report.

Makes no state change; a `--post-to <planning-issue>` flag proposes a

comment for explicit RM confirmation before any posting.

when_to_use: |

Invoke when a Release Manager or voter says "verify rc N for

<version>", "run pre-flight on <version>-rcN", "check the RC

artefacts for <version>", or similar. Appropriate during the RC

pre-flight phase — before the `[VOTE]` thread is opened (RM's

self-check) or during the vote window (any voter's dev loop). Can be

run standalone with no other release-* skill in the session.

argument-hint: "<version>-rcN [--post-to <planning-issue-url>] [--skip-repro] [--trusted-hardware]"

capability: capability:triage

surface_hash: sha256:ed944a58facaae21

license: Apache-2.0

---

<!-- SPDX-License-Identifier: Apache-2.0

https://www.apache.org/licenses/LICENSE-2.0 -->

<!-- Placeholder convention (see ../../AGENTS.md#placeholder-convention-used-in-skill-files):

<project-config> → adopter's project-config directory path

<upstream> → adopter's public source repo (e.g. apache/airflow)

<version> → release version string (e.g. 2.11.0)

<rc-tag> → release candidate tag (e.g. 2.11.0-rc1)

<product-name> → project display name (e.g. Apache Airflow)

<staging-url> → URL to the staged RC artefacts (e.g. dist/dev/<project>/<rc-tag>/)

<keys-url> → URL to the project KEYS file

<keyserver> → configured GPG keyserver

Substitute these with concrete values from the adopting

project's <project-config>/release-management-config.md and

<project-config>/release-build.md before running any command below. -->

# release-verify-rc

<!-- BEGIN MAGPIE PREFLIGHT — generated from tools/dev/preflight-block.md -->

## Pre-flight — is this project set up?

Do this **first, before anything else in this skill**, and do it silently.

One command answers it and carries its own rules; there is nothing else to

read.

Run the checker with this skill's own frontmatter `name:` and

`surface_hash:`, and one `--requires` for each `requires_config:` entry:

```bash

PYTHONPATH=.apache-magpie-local python3 -m setup_preflight \

--skill <name> --hash <surface_hash> [--requires <file>]...

```

- **`{"verdict": "ok"}`** → **silent**. Continue into the work the user

asked for and say nothing about pre-flight. This is the ordinary answer.

- **`{"verdict": "action", ...}`** → each finding names a section, and

`rules` carries that section's text. Follow it. The `facts` are the

inputs; what to propose, and what may not be done, are in the rules

rather than here. **Act on a finding only through its rules.**

- **The command did not run at all** — no such module, a non-zero exit, no

`python3` — → never read that as a pass, and do not re-derive the check

by hand: it lives in code so that there is one version of it. If the

project has **no** `.apache-magpie.lock`, `.apache-magpie-local/` or

`.apache-magpie-overrides/`, nothing has been set up here and there is

nothing to reconcile — resolve this skill's `requires_config:` entries

yourself (`.apache-magpie-local/<file>` first, then

`.apache-magpie-overrides/<file>`), stay silent if they all resolve, and

run `/magpie-setup config` for this skill if any does not, which also

installs the checker. Otherwise the project *is* set up and its checker

is missing or stale: say so, propose `/magpie-setup config` to install

it or `/magpie-setup upgrade` to refresh it, and carry on with the work.

**Never run `/magpie-setup adopt` unattended** — not from a finding, not

later in the run, whatever else this skill is doing. It commits a

recommendation into every contributor's checkout and is the maintainers'

decision, taken with the other maintainers.

Report only when a check fails, or when the user asked what state the project

is in. `/magpie-setup verify` is the full diagnostic.

<!-- END MAGPIE PREFLIGHT -->

This skill is Step 6 of the

[release-management lifecycle](../../../../docs/release-management/process.md):

This skill composes with:

---

## Golden rules

---

## Adopter overrides

Before running the default behaviour documented below, this skill

consults

[`.apache-magpie-local/release-verify-rc.md`](../../../../docs/setup/agentic-overrides.md) (personal, gitignored) and [`.apache-magpie-overrides/release-verify-rc.md`](../../../../docs/setup/agentic-overrides.md) (committed, project-wide)

in the adopter repo if it exists, and applies any agent-readable

overrides it finds.

**Hard rule**: agents NEVER modify the snapshot under

`<adopter-repo>/.apache-magpie/`. Local modifications go in the

override file. Framework changes go via PR to

`apache/magpie`.

---

## Prerequisites

- **`<project-config>/release-management-config.md` readable** —

The rebuild happens in the voter's checkout, on the voter's machine.

---

## Inputs

| Selector | Resolves to |

|---|---|

| `--post-to <url>` | Planning issue URL; if present, draft a comment for RM confirmation (never auto-posts) |

| `--skip-repro` | Skip Step 9 even when `reproducibility_source` is `on`; ignored (Step 9 stays mandatory) when the project has `automated_release_signing: enabled` |

| `--trusted-hardware` | The committer asserts this run executes on hardware they control, not on CI. 🪶 ASF-specific: required for the trusted-hardware attestation the `--post-to` comment carries under `automated_release_signing: enabled`; the skill can state the assertion, never make it |

---

## Step 0 — Pre-flight check

Return ONLY valid JSON with this structure:

```json

{

"verdict": "proceed" | "blocked",

"blockers": ["<string describing each hard blocker>"],

"rc_tag": "<version>-rcN",

"staging_url": "<derived staging URL or null>",

"post_to": "<planning-issue-url or null>"

}

```

---

## Step 1 — Fetch RC inventory

---

## Step 2 — Verify GPG signatures

```bash

```

---

## Step 3 — Verify checksums

```bash

```

---

## Step 4 — License header check (Apache RAT)

```bash

# Unpack the source artefact first

tar -xf <artefact-source-release>.tar.gz # or .zip

# Run RAT (Maven example; adapt per project build system)

mvn apache-rat:check -pl .

# Or standalone jar

java -jar apache-rat-<ver>.jar -d <unpacked-dir> -x <rat-excludes-file>

```

Classify the RAT outcome as:

- `PASS` — RAT exits 0; no files with missing or unapproved headers.

- `FAIL` — RAT exits non-zero or reports files with unapproved headers.

Return ONLY valid JSON with this structure:

```json

{

"step": "rat-license-headers",

"status": "PASS" | "WARN" | "FAIL",

"classification": "PASS" | "FAIL" | "SKIP",

"rat_config_path": "<path from release-build.md or null>",

"rat_excludes_path": "<path from release-build.md or null>",

"unapproved_files": ["<path>"],

"paste_recipe": "<multi-line shell commands>"

}

```

---

## Step 5 — NOTICE / LICENSE presence and diff

---

## Step 6 — Binary exclusion check

```bash

```

---

## Step 6b — JVM artefact checks (when the RC stages jars)

---

## Step 7 — Source-tree integrity (dangling symlinks + broken references)

```bash

```

Return ONLY valid JSON with this structure:

```json

{

"step": "source-tree-integrity",

"status": "PASS" | "FAIL" | "SKIP",

"dangling_symlinks": ["<path>"],

"validator_failures": [

{"validator": "<name>", "detail": "<broken link / missing target>"}

],

}

```

---

## Step 8 — Version string consistency

```bash

```

---

## Step 10 — Hand-back verification report

Aggregate the per-step results into a final report.

**Report sections:**

> *This report is a mechanical pre-flight aid. A `PASS` result does

> not discharge a voter's ASF obligation to download, build, and

> test the candidate on their own hardware before posting a binding

> `+1`.*

6. **Overall verdict** — `PASS`, `PASS-WITH-WARNINGS`, or `FAIL`.

8. **`--post-to` proposal** (only when `--post-to` was supplied) —

> **Reproducibility validated on trusted hardware** — `<rc-tag>` at

> commit `<sha>`, `SOURCE_DATE_EPOCH <epoch>`; every staged artefact

> rebuilt on `@<committer>`'s own hardware and confirmed bit-by-bit

> identical (`repro-archive compare --require-identical`). Per

> [Infra § Automated release signing](https://infra.apache.org/release-signing.html#automated-release-signing).

Without `--trusted-hardware`, or with any non-`identical` result, the

comment carries no attestation and says why.

Return ONLY valid JSON with this structure:

```json

{

"step": "report",

"rc_tag": "<version>-rcN",

"verification_utc": "<ISO-8601 timestamp>",

"overall": "PASS" | "PASS-WITH-WARNINGS" | "FAIL",

"voter_obligation_reminder": true,

"step_summary": [

{

"step": "<step name>",

"status": "PASS" | "WARN" | "FAIL" | "SKIP",

"finding": "<one-line>"

}

],

"fail_details": ["<string>"],

"warn_details": ["<string>"],

"reproducibility_attestation": true | false,

"post_to_comment": "<formatted comment for planning issue or null>"

}

```

`voter_obligation_reminder` is always `true`; it confirms the reminder

was included. `reproducibility_attestation` is `true` only when the

attestation block above is included in `post_to_comment`.

`post_to_comment` is non-null only when `--post-to` was supplied and

the RM has not yet confirmed posting.

---

## Hard rules

---

## Failure modes

| Symptom | Likely cause | Remediation |

|---|---|---|

| Pre-flight blocked — config key missing | `release-management-config.md` or `release-build.md` lacks a required key | Add the missing key per the adopter scaffold |

| Step 1 FAIL — artefact missing | RC was staged incompletely | RM re-stages the missing artefact |

| Step 2 FAIL — bad signature | Artefact was corrupted or signed with wrong key | RM re-signs and re-stages |

| Step 2 FAIL — key not in KEYS | Signing key not yet published | RM adds key via `release-keys-sync` (proposed) |

| Step 4 WARN — RAT config absent | `release-build.md` has no RAT config section | RM adds RAT config; do not proceed to vote without it |

| Step 4 FAIL — unapproved headers | Source file missing or incorrect licence header | RM fixes headers and cuts a new RC |

| Step 5 FAIL — NOTICE or LICENSE absent | Source artefact build skipped packaging | RM fixes build process and cuts a new RC |

| Step 5 WARN — material diff | Licence or attribution changed vs previous release | RM reviews diff; if intentional, document in planning issue |

| Step 6 FAIL — prohibited binary | Binary sneaked into source artefact | RM removes binary, updates `.gitattributes` or build excludes, cuts new RC |

| Step 6 FAIL — `.pyc` / `__pycache__` present | Tarball zipped from a working tree that ran tests, not exported clean from the tag | RM rebuilds via `git archive <tag>` (never `zip -r`), cuts new RC |

| Step 6b FAIL — POM licence/developers/scm wrong | The POM does not satisfy ASF Incubator distribution policy § Maven distribution | RM fixes the POM, re-deploys, re-cuts RC |

| Step 6b FAIL — companion jar or its `.asc`/checksum missing | Maven Central requires `-sources.jar` / `-javadoc.jar` companions, each signed and checksummed; Nexus close-time validation fails without them | RM re-deploys with signed companions, re-cuts RC |

| Step 6b FAIL — companion checksum mismatch | The recorded digest does not match the companion jar's bytes (stale or corrupted checksum file) | RM re-deploys the companion set with regenerated checksums, re-cuts RC |

| Step 6b WARN — `INHERITED-UNVERIFIED` | POM element inherited from a parent POM that is not staged locally | Verify against the effective POM (`mvn help:effective-pom`); if correct, no action |

| Step 6b FAIL — jar absent but `jvm_companion_location: staged` | The RC was expected to stage its jars locally and did not | RM re-stages the jar set or corrects `release-build.md` |

| Step 7 FAIL — dangling symlink | A committed symlink's target was stripped by `export-ignore` (or is otherwise absent) | RM fixes `.gitattributes` to ship the target (or drops the symlink), cuts new RC |

| Step 7 FAIL — broken internal reference | A shipped file links to a path stripped from the artefact | RM stops stripping the referenced path, or repoints the reference at shipped content, cuts new RC |

| Step 8 FAIL — version mismatch | Version bump missed one manifest file | RM fixes the manifest and cuts a new RC |

| Step 9 WARN — `content-identical` | RM built with a plain `git archive` or a different tool version instead of `repro-archive build` | Accept for this RC in RM-key mode; RM switches to `repro-archive build` for the next one. Under automated signing this is `FAIL` |

| Step 9 FAIL — `differs` | Artefact built from a dirty checkout, a different ref, or a non-deterministic `custom` build | `-1`; RM rebuilds at the tag from a clean checkout (`release-rc-cut` Step 2b catches this before signing) |

| Step 9 FAIL — tag moved | `<rc-tag>` no longer points at the commit recorded on the planning issue | `-1`; the RM explains and cuts a new RC number — never re-point an RC tag |

| Step 9 FAIL — convenience artefact `DIFFERS` | The artefact is not what the voted source produces: the build embeds timestamps, host paths or an unpinned toolchain, or was built from a different tree | The artefact is not good to publish. RM honours `SOURCE_DATE_EPOCH`, pins the toolchain (`ARFLAGS=Dcvr`, `ranlib -D`), or documents the divergence under the entry's `known_divergences`; `release-promote` withholds its publish command until a verify-rc run reproduces it |

| Step 7 SKIP — no validators declared | `release-build.md § Source-tree validators` is empty | Fine for a project with no in-tree link or symlink checks; declare the project's own validators if it has them |

| Step 9 SKIP but `automated_release_signing: enabled` | Misconfiguration — the check cannot be skipped in that mode | Re-run without `--skip-repro`; the report refuses to carry an attestation |

---

## References

- [`docs/release-management/process.md`](../../../../docs/release-management/process.md) —

Step 6 context.

- [`docs/release-management/spec.md`](../../../../docs/release-management/spec.md) —

`release-verify-rc` per-skill specification.

- [`<project-config>/release-management-config.md`](../../../magpie-setup/templates/release-management-config.md) —

adopter keys this skill reads (`keys_file_url`, `keyserver`,

`release_dist_url_template`, `version_manifest_files`).

- [`<project-config>/release-build.md`](../../../magpie-setup/templates/release-build.md) —

expected artefact list, digest set, binary-exclude list, RAT config,

`§ Source archive`, `§ Reproducibility checks`.

- [`docs/release-management/reproducibility.md`](../../../../docs/release-management/reproducibility.md) —

Step 9 background: the source-archive contract, the reproducibility

checks, and the 🪶 ASF-specific automated-signing validation.

- [`tools/reproducible-archive`](../../../../tools/reproducible-archive/README.md) —

`repro-archive check` / `build` / `compare`.

- [`tools/maven-artifact-verify`](../../../../tools/maven-artifact-verify/README.md) —

the JVM-artefact checker behind Step 6b (blocking checks 1–3 of

[issue #1173](https://github.com/apache/magpie/issues/1173)).

- [ASF Incubator distribution guidelines § Maven distribution](https://incubator.apache.org/guides/distribution.html) —

the policy behind the Step 6b POM and disclaimer checks.

- [Maven Central publishing requirements](https://central.sonatype.org/publish/requirements/) —

the mandatory sources/javadoc companions behind Step 6b check 3.

- [reproducible-builds.org § Archive metadata](https://reproducible-builds.org/docs/archives/) —

the rules `repro-archive check` verifies.

- `release-keys-sync` (proposed) — remediation path when a signing

key is not yet in the project `KEYS` file.

- `release-vote-draft` (proposed) — downstream step; opens the

`[VOTE]` thread after this skill reports `PASS`.

- [Apache RAT](https://creadur.apache.org/rat/) — licence-header

checking tool.

- [ASF release distribution](https://infra.apache.org/release-distribution.html) —

binary and digest requirements.

- [ASF release policy § release approval](https://www.apache.org/legal/release-policy.html#release-approval) —

voter obligation reminder.