The syft library has a transitive dependency on containerd, which includes
platform-specific code that doesn't compile on NetBSD, OpenBSD, and Solaris.
This change adds build constraints to exclude the syft import on these
platforms. The hcp-sbom provisioner functionality is unaffected since it
downloads and executes pre-built syft binaries at runtime rather than
using the Go library directly. The import exists solely for dependency
tracking in license and security scanning tools.
* add configuration fields to SBOMInternalProvisioner
* add os detection
* move implementation to hcp-sbom
* upload scanner binary and execute
* use latest syft version always
* reduce duplicate code
* rename config fields appropriately
* default to cyclonedx
* add syft dependency
* add support for elevated user for windows
* add retry for download
* add syft dependency
Updates go version
* optimization for windows
* improve docs
* update config usage rules
* add unit tests
* update golang version, fix linter issues
* refactor and improvements
* simplify few lines
* refactor retry for scanner download
* resolved conflicts
* resolve conflicts from main
* stick to syft v1 for compatibility
* fix lint issues
* stricter version check for syft
* fix version eg
* update go version to 1.25.7
* go mod changes
* bump golang.org/x/crypto to 0.43.0
CVE-2025-47913 GO-2025-4116
* fixed go.sum
* fixed multiple warnings that prevented test runs
* make generate
* fix lint errors, update linter version
* fix go vet issues
* WIP Testing Approach
* WIP Testing Approach
* WIP Testing Approach Work
* WIP Testing Approach
* adding acceptance test for windows Amazon EBS.
* modify wrapper string to use Set-Variable
* fixing unit tests
* cleanup
* updated approach to use -file instead of inline powershell execution.
* adding more scenarios for acceptance test.
* using writeString for file directly.
* changing variable name
* updating test case. cleanup.
* updating test case
* updating test case
* updating test case - nested try catch
* adding unit test for None Execution Policy
* adding unit test for None Execution Policy
* fix test case
Since the protos for uploading an SBOM for a build have been changed to
use an enumeration instead of a plain string with the latest revisions
to the HCP Packer SBOM support feature, we update how we reference those
values for the SBOM format to use that enum instead.
The hcp-sbom provisioner is a provisioner that acts essentially like a
download-only file provisioner, which also verifies the file downloaded
is a SPDX/CycloneDX JSON-encoded SBOM file, and sets up its upload to
HCP Packer later on.
In a couple places in the codebase we didn't check the errors from
functions we execute.
In some cases this is harmless (or at least ignorable), but others may
need to log what went wrong, so for all the reported occurrences we
either ignore explicitly or handle the error with a log.
Since the enumer implementation we used hadn't been updated for 5+
years, this didn't work with recent linux/go versions, and enumer
crashed while attempting to parse/analyse the source files.
There's another alternative on Github, forked from the one we used,
which seems more maintained now, and does produce the expected files in
Packer.
* Updating the license from MPL to Business Source License
Going forward, this project will be licensed under the Business Source License v1.1. Please see our blog post for more details at https://hashi.co/bsl-blog, FAQ at https://hashi.co/license-faq, and details of the license at www.hashicorp.com/bsl.
* Update copyright file headers to BUSL-1.1
---------
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
* provisioner/shell: add support for Env variables
As mentioned in issue #11670, the Shell provider did not support Env
variable declarations in the HCL templates.
This commit adds the capability to the code.
* provisioner/powershell: add support for Env vars
* provisioner/windows-shell: support Env variables
* allowing to set shell env vars from a key/value map.
* tests
This new map will work alongside the `environment_vars` but it allows using a
datasource value seamlessly. At validation, and because `environment_vars` was
an array of strings containing `KEY=value`, using datsources would not work,
because these values are not known yet and would evaluate to `<unknown>`. With
this, the value and the key can be unknown and will validate correctly for
datasources.
