* 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
Ensures compatibility with the latest OpenTelemetry libraries,
potentially addressing security and stability improvements.
Prepares codebase for new features and bug fixes from upstream.
* 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
Previous version was v0.33.0, which was detected vulnerable to
GO-2025-3503.
This is unlikely to be a bug that causes significant security concerns,
but we fix that with this commit regardless.
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.
As we're trying to move away from gob for serialising data over the
wire, this commit adds the capability for Packer to pick dynamically
between gob or protobuf for the serialisation format to communicate with
plugins.
As it stands, if all the plugins discovered are compatible with
protobuf, and we have not forced gob usage, protobuf will be the
serialisation format picked.
If any plugin is not compatible with protobuf, gob will be used for
communicating with all the plugins that will be used over the course of
a command.
Since the version 0.6.0 of the plugin SDK was released yesterday, we
bump packer to use this version.
This change adds new functions to use within Packer regarding AWS
secretsmanager, along with changes to how plugins can communicate
over-the-wire (e.g. using protobuf/msgpack for serialising
configurations instead of gob).
Version 5.11.0 of the go-git library is vulnerable to two CVEs as
reported by our scanners.
Both are not impacting Packer since we only use go-git to read values
from a local Git repository, but still we upgrade our version to 5.13.0
so those reports don't apply to us.
The version of golang.org/x/net that we're using (v0.25.0) is vulnerable
to GO-2024-3333, a DoS vulnerability.
Packer is not particularly vulnerable to this, as we are not a hosted
service, but since security scanners report this, and the fix is rather
simple, we address it today.
The hcl2_upgrade command transforms a JSON template into an HCL2
template for use with Packer.
The command is quite fragile already, but given that this is the last
remaining fragment that causes Packer to depend on the AWS SDK directly,
we can do away with it.
This commit therefore imports the definitions for AWS access config, so
we can extract this information from the JSON template, and include it
in the definition of the output source for AWS, since we manage this one
differently from other sources.
This allows us to not depend on the AWS plugin directly, which in turn
makes Packer not need to link with the AWS plugin when compiling the
executable.
We are still depending on the AWS SDK for now since the SDK exposes a
aws_secretsmanager function that can be used for interpolation (legacy
JSON interpolation to be clear), so this cannot be removed from now, but
we should consider some form of remediation in the future.
The crypto experimental module that the SDK depends on was detected
vulnerable on v0.23.0 to an authentication bypass attack through the
ServerConfig for SSH.
This is only used for locally proxying SSH communications, typically for
use with Ansible to provide an SSH server with which to interact, in
order to provision an instance of an OS that uses a communicator other
than SSH, therefore the vulnerability does not necessarily impact us.
However, in order to resolve the automatic report of that vulnerability,
we bump the crypto module's version to 0.31.0, where that problem was
addressed.
Before change
```
~> govulncheck ./...
=== Symbol Results ===
Vulnerability #1: GO-2024-2947
Leak of sensitive information to log files in
github.com/hashicorp/go-retryablehttp
More info: https://pkg.go.dev/vuln/GO-2024-2947
Module: github.com/hashicorp/go-retryablehttp
Found in: github.com/hashicorp/[email protected]
Fixed in: github.com/hashicorp/[email protected]
Example traces found:
#1: hcl2template/function/vault.go:30:30: function.init calls template.Vault, which eventually calls retryablehttp.Client.Do
Your code is affected by 1 vulnerability from 1 module.
```
After Change
```
~> govulncheck ./...
No vulnerabilities found.
```
The SDK's Ui interface has had some additions recently for supporting
format-strings and their arguments as paramereters to Say, Ask and
Error.
These changes to the interface means that all the implementations of
that interface need to match the definition, so in this case the
implementations we had in packer/ui.go need to be updated to support
those functions.
This change addresses vulnerabilities reported by govulncheck
```
Vulnerability #1: GO-2024-2610
Errors returned from JSON marshaling may break template escaping in
html/template
More info: https://pkg.go.dev/vuln/GO-2024-2610
Standard library
Found in: html/[email protected]
Fixed in: html/[email protected].1
Example traces found:
#1: datasource/http/data.go:119:24: http.Datasource.Execute calls http.Client.Do, which eventually calls template.Template.Execute
#2: datasource/http/data.go:119:24: http.Datasource.Execute calls http.Client.Do, which eventually calls template.Template.ExecuteTemplate
Vulnerability #2: GO-2024-2600
Incorrect forwarding of sensitive headers and cookies on HTTP redirect in
net/http
More info: https://pkg.go.dev/vuln/GO-2024-2600
Standard library
Found in: net/[email protected]
Fixed in: net/[email protected].1
Example traces found:
#1: datasource/http/data.go:119:24: http.Datasource.Execute calls http.Client.Do
#2: hcl2template/function/aws_secretetkey.go:38:37: function.init calls template.GetAWSSecret, which eventually calls http.Client.Post
#3: hcl2template/function/aws_secretetkey.go:38:37: function.init calls template.GetAWSSecret, which eventually calls http.Client.PostForm
Vulnerability #3: GO-2024-2599
Memory exhaustion in multipart form parsing in net/textproto and net/http
More info: https://pkg.go.dev/vuln/GO-2024-2599
Standard library
Found in: net/[email protected]
Fixed in: net/[email protected].1
Example traces found:
#1: internal/hcp/api/service_build.go:81:48: api.Client.UpdateBuild calls packer_service.Client.PackerServiceUpdateBuild, which eventually calls textproto.Reader.ReadLine
#2: datasource/http/data.go:140:26: http.Datasource.Execute calls io.ReadAll, which eventually calls textproto.Reader.ReadMIMEHeader
Vulnerability #4: GO-2024-2598
Verify panics on certificates with an unknown public key algorithm in
crypto/x509
More info: https://pkg.go.dev/vuln/GO-2024-2598
Standard library
Found in: crypto/[email protected]
Fixed in: crypto/[email protected].1
Example traces found:
#1: datasource/http/data.go:140:26: http.Datasource.Execute calls io.ReadAll, which eventually calls x509.Certificate.Verify
```