Files
Packer-Cn/post-processor/provenance
9408d6d0ad Release Packer version 1.16.1 (#13708)
* hcl2template: pass user variable values to plugins as packer_user_variables (#13686)

HCL2 builds do not send the packer_user_variables config key to the
builder, provisioner and post-processor plugins. Legacy JSON builds
send this key (through CoreBuild.packerConfig()). Without the key, the
plugin SDK keeps interpolate.Context.UserVariables nil. Then the
template function {{ user "name" }} fails with 'error calling user:
test'. This failure occurs in each string that a plugin interpolates at
run time, for example the contents of the vagrant post-processor's
vagrantfile_template.

Add the function PackerConfig.userVariableValues(). This function
converts the input variable values to strings, equivalent to the legacy
user variables. The core sends the map at each plugin handoff point:
builder, provisioner, post-processor, and enforced provisioner.

The map does not contain the sensitive variables. A sensitive value
goes to a plugin only if the template refers to it explicitly. The map
does not contain values that are not primitive (lists, maps, objects).
Legacy user variables were always strings.

Co-authored-by: Claude Fable 5 <[email protected]>

* Dependency upgrade (#13689)

* go.mod version upgrade

* actions upgrade

* plugin-getter: install plugins from non-GitHub HTTP sources (#13691)

Packer can only install plugins from github.com, with
releases.hashicorp.com consulted first for HashiCorp-published plugins.
This has been a long-standing gap for air-gapped and policy-restricted
environments (#11164): the source address parser already accepts any
hostname, but both existing getters reject non-github.com sources at
install time.

Add a remote plugin getter that installs plugins from the host named in
a required_plugins source address. The host serves the directory
structure of releases.hashicorp.com under the source's path: an
index.json listing versions, and per version a SHA256SUMS file, the
zips it lists, and - when the zip names carry no plugin protocol
version - the version's manifest.json. A plugin published on
releases.hashicorp.com is therefore mirrored as a verbatim copy of its
tree, with every checksum file and signature upstream-authored. A
plugin published as GitHub release assets is mirrored by copying each
release's assets into a version directory, renaming their SHA256SUMS
file to the unprefixed convention with content unchanged, and writing
an index.json listing the versions. Both kinds of content can be
served side by side by one host.

Getter selection happens per source address: github.com sources keep
the release and github getters unchanged, while any other host is
served by the remote getter over HTTPS. Sources with three or more
components are supported, up to the existing 16-component limit, so
nested artifact-repository paths and hosts that embed the upstream
origin in their path all resolve.

Version discovery, constraint solving, checksum verification, and the
binary naming rules match the existing getters. The installed filename
is rebuilt from validated checksum-file fields and never taken from the
server's response, checksum entries matching neither known naming shape
are rejected rather than guessed at, and nothing the remote metadata
supplies is used to fetch from another origin or path. index.json
parsing is covered by fixtures captured from the live releases API, so
a format change there fails tests rather than user installs.

Closes #11164

* fix: update link to CONTRIBUTING.md for consistency with main branch

* Merge pull request #13701 from hashicorp/sanya-hashicorp/fix-vuln

Module Dependency update

* build(deps): bump google.golang.org/grpc (#13704)

Bumps [google.golang.org/grpc](https://github.com/grpc/grpc-go) from 1.83.1 to 1.83.2.
- [Release notes](https://github.com/grpc/grpc-go/releases)
- [Commits](https://github.com/grpc/grpc-go/compare/v1.83.1...v1.83.2)

---
updated-dependencies:
- dependency-name: google.golang.org/grpc
  dependency-version: 1.83.2
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* [COMPLIANCE] Add/Update Copyright Headers (#13699)

* [COMPLIANCE] Add/Update Copyright Headers

* make generate update

* make generate

---------

Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
Co-authored-by: sanya <[email protected]>
Co-authored-by: Sanya <[email protected]>

* Packer release 1.16.1 (#13705)

* Module upgrade (#13707)

---------

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: Erik Berg <[email protected]>
Co-authored-by: Claude Fable 5 <[email protected]>
Co-authored-by: Benjamin Holmes <[email protected]>
Co-authored-by: elomito <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
2026-09-15 22:08:23 +05:30
..

Provenance Post-Processor

The provenance post-processor writes in-toto attestations for the incoming artifact.

It supports:

  • SLSA provenance statements enriched with source-control and CI metadata.
  • SBOM sidecars plus SBOM attestations.
  • Optional DSSE signing with a configurable signer and verifier.

Signing defaults to none, which writes the unsigned JSON statement.

Source detection

The provenance statement records the build's source repository as a resolved dependency. Packer detects this from the Git repository containing the current working directory (the directory Packer runs in). Set source_uri to override the detected value, for example when the build runs outside the source checkout or the remote URL should be normalized.

Signing modes:

  • key signs with a PEM private key and verifies with either the signer's derived public key or an explicit verifier PEM.
  • kms signs with a KMS or Vault URI such as awskms://..., gcpkms://..., azurekms://..., or hashivault://.... Verification uses the fetched KMS public key or an explicit verifier PEM.
  • keyless signs with an ephemeral keypair and a Fulcio-issued certificate. It requires an ambient OIDC token, such as SIGSTORE_ID_TOKEN, or a CI provider token that can be exchanged for a Sigstore identity. When using the built-in verifier path, also configure the expected signing identity and OIDC issuer. Set an optional trusted-root JSON path to pin verification to a specific Sigstore root; otherwise the public Sigstore trusted root is fetched. Keyless signing can also emit a Sigstore bundle sidecar and upload to Rekor.

Example:

post-processor "provenance" {
  build_type = "https://packer.io/buildtypes/hcl2/v1"
  template   = "ubuntu.pkr.hcl"
  only_builds = ["qemu.ubuntu"]
  user_variables = {
    region = "us-east-1"
  }
  sbom = true
}

Signed example:

post-processor "provenance" {
  signing_mode = "key"
  signer       = "keys/provenance-signing.pem"
  verifier     = "keys/provenance-signing.pub.pem"
  sbom         = true
}

KMS example:

post-processor "provenance" {
  signing_mode = "kms"
  signer       = "awskms://alias/packer-provenance"
  sbom         = true
}

Keyless example:

post-processor "provenance" {
  signing_mode        = "keyless"
  fulcio_url          = "https://fulcio.sigstore.dev"
  rekor_url           = "https://rekor.sigstore.dev"
  upload_tlog         = true
  keyless_identity    = "https://github.com/hashicorp/packer/.github/workflows/build.yml@refs/heads/main"
  keyless_oidc_issuer = "https://token.actions.githubusercontent.com"
  trusted_root_path   = "sigstore-trusted-root.json"
}

With keyless signing, Packer writes an additional *.sigstore.json sidecar next to each signed attestation. When upload_tlog = true, that bundle includes Rekor-backed transparency evidence for packer verify-attestation -bundle ....

During a build, keyless verification enforces the Fulcio certificate chain and the configured identity policy. For Rekor-backed verification, run packer verify-attestation with the generated Sigstore bundle and the -require-rekor and/or -require-timestamp flags.

SLSA levels and CI

SLSA Build levels are mostly properties of the build platform, not the build tool. Packer is a tool, so its reach is:

SLSA Build level Requirement Packer's role What Packer provides
L1 Provenance exists and is distributed Fully in Packer Provenance generation
L2 Provenance signed by a hosted platform Packer signs via CI OIDC identity Keyless signing in CI
L3 Hardened platform; build steps cannot reach the signing key Platform property; Packer is compatible Delegated-signing pattern
L4 Not defined in SLSA v1.0

Packer generates SLSA Provenance v1 and reaches Build L1, and L2 when run on a hosted CI with keyless signing. L3 is a property of the build platform: it requires the signing key to be unreachable by the build steps. Packer does not confer L3 on its own, but the delegated-signing pattern is compatible with an L3 platform.

Reference GitHub Actions workflows for both the L2 keyless pattern and the L3-compatible delegated-signing pattern live under examples/ci/.