kandev/docs/decisions/2026-08-01-bitbucket-initial-release-remains-unsigned.md

ADR-2026-08-01-bitbucket-initial-release-remains-unsigned: Bitbucket Initial Release Remains Unsigned

Status: accepted Date: 2026-08-01 Area: infra, workflow, security

Context

Kandev currently verifies every plugin package's generated internal checksums.txt, but it does not verify checksums.txt.sig; installed packages are therefore reported as unsigned. The Bitbucket implementation plan had made a signed release a publication gate even though no host trust policy, verifier, approved key, or key-rotation process exists. Producing a signature that the host cannot authenticate would add ceremony without adding enforceable trust.

Decision

The initial official kandev-plugin-bitbucket release may use the current unsigned marketplace contract. Its package must contain the generated internal checksums.txt, its public GitHub Release may include the standard advisory release-level checksum asset, and its source remains public and subject to the official catalog's maintainer review. Kandev will report the installed package as unsigned, and neither repository may claim that the release is signed or that its publisher provenance is cryptographically verified.

Signing is not a Bitbucket release gate. Enforceable plugin signing remains future host-wide work and requires a superseding decision covering signature verification, trusted-key or identity distribution, rotation and revocation, and fail-closed policy before official plugins can rely on it.

Consequences

• Bitbucket follows the trust posture already implemented for other plugins instead of inventing an integration-specific signing ceremony.
• Package checksums detect extraction corruption and unexpected file changes, but they do not authenticate who produced an archive. Trust still rests on the public source and release repository, curated catalog review, and the operator's explicit install/update action.
• The signing decision no longer blocks Bitbucket publication; host compatibility, live provider behavior, packaged-host, and credential-broker evidence remain independent release gates.
• A future signing rollout must deliberately supersede this decision and may require republishing or reattesting the plugin.

Alternatives Considered

• Block Bitbucket until signing exists. Rejected because no shipped verifier or trust-root policy exists, while the marketplace explicitly supports unsigned packages.
• Generate an ad hoc Ed25519 signature for Bitbucket. Rejected because the host could not authenticate it and no approved distribution, rotation, or revocation process exists.
• Require Sigstore provenance for this plugin alone. Rejected as a useful future direction that first needs a host-wide verification and policy design.