Sensitive variable value causes unrelated substrings (e.g. filenames) to be redacted in build output
- 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
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