Builder no longer trusted when using --trust-builder with Pack 0.35.0

[edmorley]

Summary

In Pack v0.35.0 (which includes 16f4932, the fix for #2221), the untrusted builder workflow is now used even when the user explicitly requests that the builder be treated as trusted using --trust-builder.

This impacts our CNB integration test framework, which runs tests using pack build --builder <...> --buildpack <local_dev_buildpack> --trust-builder, as it:

1. Causes multi-line build log output string assertions to fail (used for testing rendering of buildpack log output: example), due to the [builder] log line prefixes now added in untrusted mode.
2. Makes tests slower (eg due to pulling of buildpacksio/lifecycle plus running the build flow in separate containers).

It seems this change may have been unintentional, since the security issue mentioned in #2221 doesn't apply to --trust-builder, where the user has explicitly requested that the builder be trusted.

---

Reproduction

Steps

1. pack build --trust-builder --builder heroku/builder:24 --buildpack packaged/aarch64-unknown-linux-musl/debug/heroku_python --path tests/fixtures/python_3.12/ test-app --verbose
   (or any similar command with a local buildpack passed via --buildpack)

Current behavior

$ pack build --trust-builder --builder heroku/builder:24 --buildpack packaged/aarch64-unknown-linux-musl/debug/heroku_python --path tests/fixtures/python_3.12/ test-app --verbose
Builder heroku/builder:24 is trusted
Pulling image index.docker.io/heroku/builder:24
24: Pulling from heroku/builder
Digest: sha256:111d41f1a43ae69e9835c55cf7c185d5f08b010a08bac72529caab983a24e2ac
Status: Image is up to date for heroku/builder:24
CheckReadAccess succeeded for the run image heroku/heroku:24
Selected run image heroku/heroku:24
Pulling image heroku/heroku:24 with platform linux/arm64
24: Pulling from heroku/heroku
Digest: sha256:36e92b6b4e2a980a02363b9f1ddce582c32f38e236b778a6570dedf3d52ab733
Status: Image is up to date for heroku/heroku:24
Downloading buildpack from URI: file:///Users/emorley/src/buildpacks-python/packaged/aarch64-unknown-linux-musl/debug/heroku_python
Warning: Builder is trusted but additional modules were added; using the untrusted (5 phases) build flow
Pulling image buildpacksio/lifecycle:0.20.0 with platform linux/arm64
0.20.0: Pulling from buildpacksio/lifecycle
...

Expected behavior

To not see:

Warning: Builder is trusted but additional modules were added; using the untrusted (5 phases) build flow

...and for the build to proceed in trusted mode.

---

Environment

pack info

$ pack report
Pack:
  Version:  0.35.0+git-f6b450f.build-6065
  OS/Arch:  darwin/arm64

Default Lifecycle Version:  0.19.6

Supported Platform APIs:  0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12, 0.13

Config:
  default-builder-image = "[REDACTED]"

docker info

N/A

[natalieparellano]

@edmorley I think this behavior is expected, as #2221 does apply to trusted builders (pack build <trusted-builder> --buildpack <untrusted-buildpack> though perhaps we should've been explicit and also said pack build <any-builder> --buildpack <untrusted-buildpack> --trust-builder).

I get what you're saying here, it is annoying that there isn't any way to get the old behavior. Perhaps we need something like pack build --trusted-buildpack <foo>? WDYT?

[edmorley]

I guess in my mental model I was thinking:

1. --builder <trusted> --buildpack <untrusted> = <ephemeral untrusted builder>
2. And --trusted-builder would then apply to <ephemeral untrusted builder>, making it <trusted ephemeral builder>?

[edmorley]

Perhaps we need something like pack build --trusted-buildpack <foo>? WDYT?

Yeah that would work.

It seems like there might be use-cases where someone might want to pass only one of --trust-builder or --trust-buildpack (rather than both of them), and so perhaps having two CLI args here would make sense?

[natalieparellano]

@edmorley would you want pack build --trusted-buildpack bp1 --trusted-buildpack bp2 or pack build --buildpack bp1 --buildpack bp2 --trust-buildpacks? I guess we could support both? There's no use case for mixing trusted & untrusted buildpacks, so maybe the latter as simpler and easier?

[edmorley]

A single --trust-buildpacks sounds good to me.