Releases · Lantern

Each version of the text is released on the repository by a tag spec-v<version> (spec-v0.6), from draft 0.6 on (the specification, § 3.6). The maintainer makes the tag; the repository's release workflow builds the files from it, attests them and publishes them, a prerelease while the text is a draft. The releases, on GitHub.

What a release holds

SPEC.md and openapi.yaml, as they are at the tag;
lantern-schemas-0.6.zip, lantern-examples-0.6.zip, lantern-vectors-0.6.zip and lantern-conformance-0.6.zip: the schemas, their examples, the test vectors and the conformance suite;
lantern-0.6.zip: all of them in one, with the licences;
SHA256SUMS: the SHA-256 of each file.

The zips are reproducible: the same tagged tree gives the same bytes. Each file carries a build provenance attestation (SLSA, signed through Sigstore): GitHub's word that it was built from that tag by this repository's release workflow, and not changed since.

Verify a release

With the GitHub CLI, download the release, check the attestation of each file you use, then their sums:

gh release download spec-v0.6 --repo JigSawFr/lantern
gh attestation verify lantern-0.6.zip --repo JigSawFr/lantern
sha256sum --check --ignore-missing SHA256SUMS

gh attestation verify fails when the file was not built by a workflow of JigSawFr/lantern, or was changed after. To also require the release workflow itself:

gh attestation verify lantern-0.6.zip --repo JigSawFr/lantern \
  --signer-workflow JigSawFr/lantern/.github/workflows/release.yml

An implementation names the version it follows, and the conformance suite of that release checks it (conformance levels).

The schemas at their address

Each schema's $id is its stable address, where this site serves it as it is in the repository: https://lantern.boreale.dev/schemas/v1/apps.json, https://lantern.boreale.dev/schemas/v1/common.json… The address of a schema of /v1/ never changes, and each release carries the same files (§ 3.2).