The direct answer
Bind release evidence to the exact signed annotated tag object and its intended direct commit target, rather than carrying approval forward by tag name. Evaluate the signer against an independently trusted release policy, then preserve that immutable association into the separate code-review boundary. A valid tag signature authorizes no execution or deployment.
A release label is not the whole evidence record
A fictional assistant will explain changes in one already-owned release of a small internal text-formatting library. An operator supplies a familiar release name and says that its tag is signed. Before source enters review, the service needs to identify which signed object and which intended commit that statement concerns.
This worksheet selects one annotated tag directly targeting a commit in an independently admitted complete local store. It excludes lightweight or unsigned tags, nested tag targets, alternate signing schemes, caller-selected revision expressions, checkout, fetch, build and deployment. No repository, key, signature, object or candidate Git command is inspected or exercised here.
The artifact guide requires independent provenance. The diff guide still controls comparison generation. This earlier release-association sheet replaces neither.
Distinguish a reference from an annotated object
The Git tag manual distinguishes a lightweight reference directly naming an object from an annotated tag object with metadata and an optional signature. Signed tags create annotated objects; annotation alone does not imply signing. The tagged target is usually a commit, but can be another object.
The same manual discusses replacing published tags: people can hold different objects under the same release name. Therefore our proposed release record preserves label R-A separately from full admitted tag-object identity TAG-A and direct target COMMIT-A. These labels are invented references, not actual object identifiers or calculated hashes.
A later name lookup is not allowed to overwrite TAG-A silently. A changed association requires a new review. This is an application rule, not a claim that Git automatically updates every consumer or that a displayed tag name supplies immutable identity.
Keep displayed contents separate from validated evidence
git-verify-tag validates the GPG signature in the listed tag objects. Its verbose option prints contents before validation; raw mode emits GPG status on standard error. Neither a displayed annotation nor a pleasant output prefix establishes successful verification.
Select only the OpenPGP branch for this worksheet. The actual executable, configuration, key material, verifier behavior, bounded output capture and complete result interpretation need independent review. These manuals do not supply this application’s raw-status decoder, exit-status mapping or signer-authority registry. Unknown evidence holds the release; no parser for status text is provided here.
Record signature disposition and accepted-signer disposition separately. The latter must come from a protected policy naming the allowed release authority and relevant key evidence, not a tagger display name or a model’s explanation. A signature accepted under an unrelated key cannot satisfy that policy. Current trust changes still need the declared operating response; this worksheet does not validate anyone’s real identity or establish key ownership.
Require the actual direct target, not a convenient conversion
git-cat-file can report an object’s type and contents. Its explicit type argument can also permit trivial dereferencing. Requesting content as a commit-shaped target is therefore insufficient evidence of the original object type.
The proposed inspector must separately establish that TAG-A is the admitted annotated object, inspect its complete direct target association through a supported object reader, require that target to be a commit, and compare its full identity with independently approved COMMIT-A. Verification and inspection must concern the same TAG-A, not two separate resolutions of R-A.
The complete reader, object validation, trusted configuration and immutable association are unimplemented prerequisites. No tag-header grammar, peeling algorithm, revision parser or command recipe is supplied here. A missing target, another tag or an unsupported type stays outside this direct-complete-commit profile. Do not repair it by fetching or substituting another object.
Walk eight inert signed-release cards
| Card | Proposed condition | Decision |
|---|---|---|
| 1. Ordinary release | Exact TAG-A, accepted signer policy and direct approved COMMIT-A match; all prerequisites established. | Conditionally select that commit for separate bounded code-review admission. |
| 2. Name drift | R-A now names another annotated object. | Hold the changed association; prior evidence does not follow the name. |
| 3. Wrong tag kind | Lightweight or unsigned annotated tag offered. | Reject the claimed signed-annotated evidence under this profile. |
| 4. Unaccepted signer | Signature validates under a key outside the protected release policy. | No trusted-release admission; keep cryptographic and authority decisions separate. |
| 5. Different commit | Verified TAG-A directly targets COMMIT-B. | Hold despite a matching human-readable release label. |
| 6. Unsupported target | Another tag, another type or missing object is encountered. | Outside scope; no automatic peeling or repair fetch. |
| 7. Partial evidence | Contents appear but verifier result, actual type or complete capture is unknown. | Preserve unverified status; output visibility is insufficient. |
| 8. Unsafe next action | Provenance matches, but code, dependencies, current rights or intended operation fail review. | Deny that separate step; a tag signature supplies no override. |
Preserve the selected commit into the next review
The useful positive is a small admitted text-library change whose exact signed-release association is established. A trusted handoff must retain TAG-A, COMMIT-A, signer-policy revision, evidence disposition and intended review scope. It must not ask a later stage to resolve only R-A again. Actual store integrity, configuration, verifier/result mapping and handoff remain unknown here and block real admission.
The maintained pages show Git 2.56.0 as the latest manual profile; tag and verify-tag list earlier last-change versions. No installed Git or GPG was inspected. Matching provenance does not establish harmless code, signed historical commits, complete dependency approval, licensing suitability or permission to run, commit, push or deploy anything.
All cards are unrun. No Git, object, signature, key, cryptographic verifier, fixture or model operation occurred. Boundary remains prelaunch with planned request-path checks, not a shipped Git release-verification or deployment-approval service.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.