hashicorp / hashicorp/packer

Sensitive variable value causes unrelated substrings (e.g. filenames) to be redacted in build output

Open
#13,659 5 comments 0 reactions 0 assignees View on GitHub
bug
Dominant language
Go
Stars
15.8k
Forks
3.3k
PR merge metrics
PR metrics pending

Description

#### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

#### Overview of the Issue

When a sensitive variable's value happens to also be a substring of unrelated, non-secret text elsewhere in the build output (for example, a filename), Packer's redaction logic replaces every occurrence of that substring with ``, regardless of context.

In my case, `ssh_username` is set to `"ubuntu"` and marked `sensitive = true`. Because "ubuntu" is also part of the ISO filename (`ubuntu-22.04.5-live-server-amd64.iso`), Packer redacts the filename too, even though it has nothing to do with the actual secret value. This is also true for the VM name and other unrelated strings.

This raises a question about intended behavior: should redaction be scoped to only the variable's own output context, rather than a blind substring replace across all log output? As implemented, a reader can often infer what the redacted substring must be from surrounding context (e.g. "this looks like it should say a known Ubuntu ISO filename, so the sensitive value must be 'ubuntu'"), which seems to undermine the purpose of marking the variable sensitive in the first place. Is this considered expected/working-as-intended behavior, or would a more context-aware redaction approach be welcomed as a fix?

#### Reproduction Steps

1. Define a sensitive variable whose value is a short, common substring that's also likely to appear elsewhere in build output (e.g. `"ubuntu"`).
2. Reference an ISO or any file whose name also happens to contain that same substring.
3. Run `packer build`.
4. Observe that the filename in the log output is partially redacted, even though it is not the sensitive value itself.

### Packer version

Packer v1.15.3

### Simplified Packer Template

```hcl
variable "iso_path" {
type = string
}

variable "iso_checksum" {
type = string
}

variable "ssh_username" {
type = string
default = "ubuntu"
sensitive = true
}

variable "ssh_password" {
type = string
sensitive = true
}

source "qemu" "ubuntu2204" {
iso_url = var.iso_path
iso_checksum = "sha256:${var.iso_checksum}"
ssh_username = var.ssh_username
ssh_password = var.ssh_password
format = "qcow2"
accelerator = "none"
}

build {
sources = ["source.qemu.ubuntu2204"]
}
```

### Operating system and Environment details

Build machine: Ubuntu Server (VM, no nested virtualization/KVM available)
Architecture: x86_64

### Log Fragments and crash.log files
```
qemu.2204: output will be in this color.

==> qemu.2204: Retrieving ISO
==> qemu.2204: Trying ../../artifacts/-22.04.5-live-server-amd64.iso
==> qemu.2204: Trying ../../artifacts/-22.04.5-live-server-amd64.iso?checksum=sha256%3A9bc6028870aef3f74f4e16b900008179e78b130e6b0b9a140635434a46aa98b0

```
Note that `ubuntu-22.04.5-live-server-amd64.iso` is a filename, not a secret — it is only being redacted because it contains the same substring as the sensitive `ssh_username` value (`"ubuntu"`)

Contributor guide

Open the contributing guide

Research direction

The issue provides a reproducible Packer build using a sensitive ssh_username value and shows the affected log fragments; start by running that reproduction and tracing the redaction path. Done means the sensitive value remains protected while unrelated filenames, VM names, and builder labels containing the same substring remain unchanged, with regression coverage for the demonstrated case.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
security, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.