PolicyContext: add new `SetRejectInsecure` method #355

jlebon · 2025-09-24T14:59:30Z

In bootc, we want the ability to assert that signature verification is enforced, but there are no mechanisms for this in the library.

Add a new SetRejectInsecure method on the PolicyContext object which would allow this.

Since this only changes the behaviour of the insecureAcceptAnything policy requirement, rather than extending the policy requirement interface, I went with a filtering approach directly in IsRunningImageAllowed().

Test generation was Assisted-by: Claude Code v1.0.120.

Part of containers/skopeo#1829.

jlebon · 2025-09-24T15:00:50Z

rather than extending the policy requirement interface

I initially went that way so have code for this as well if we want to compare.

Keeping it in draft for now until there's agreement on the approach.

mtrmac

Thanks!

Just a very quick drive-by, looking at the implementation. The much more important part is designing the semantics of the new option, and I don’t have an opinion on that yet.

image/signature/policy_eval.go

cgwalters · 2025-09-26T15:53:33Z

Thanks for starting this! I think in the general case what we also want here is something like podman pull --require-signature or so.

jlebon · 2025-09-26T16:10:23Z

Thanks for starting this! I think in the general case what we also want here is something like podman pull --require-signature or so.

I did briefly look at that. Worth noting that e.g. skopeo today has an --insecure-policy but podman does not. Not sure if that was on purpose or an oversight. But yeah, I would agree.

mtrmac · 2025-10-01T13:57:32Z

There’s a degree of implementation difficulty for Podman: Skopeo has the policy configuration centralized, as a top-level option; AFAIK Podman does not, really. So, an option would have to be added to each subcommand individually, or the policy setup would need to be fairly significantly refactored.

(Complicating this even more, for Podman, is the “remote” mode where the CLI is an API client to a server on a different VM / machine. Even if we did centralize the CLI handling, we would still need to add the “reject insecure” field (and the pre-existing “signature policy path”) to every single API operation individually. That’s one of the reasons the podman pull --signature-policy flag is entirely unavailable in remote mode — I suppose it would be viable to do the same here, and just not implement the feature for remote.)

In bootc, we want the ability to assert that signature verification is enforced, but there are no mechanisms for this in the library. Add a new `SetRejectInsecure` method on the `PolicyContext` object which would allow this. Add a new `isInsecure` method on the `PolicyRequirement` interface which then allows `IsRunningImageAllowed` to detect if at least one secure requirement was present. Test generation was `Assisted-by: Claude Code v1.0.120`. Part of containers/skopeo#1829. Signed-off-by: Jonathan Lebon <[email protected]>

podmanbot · 2025-10-05T11:47:27Z

✅ A new PR has been created in buildah to vendor these changes: containers/buildah#6409

mtrmac · 2025-10-06T13:37:41Z

image/signature/policy_eval_baselayer.go

 }
+
+func (pr *prSignedBaseLayer) isInsecure() bool {
+	return false


Deciding whether “signed base layer” is “secure” is … a weird question. Not really an interesting question, given that this is an unusable stub…

Yeah, I guess I should probably just flip this to true for now and add a FIXME here too to reconsider once it's implemented. It definitely stresses the binary secure vs insecure logic, so it might have to be reworked a bit at that point based on what semantics we want.

Reading #355 (comment) , if the semantics is “we authenticated the image at least once”, prSignedBaseLayer does not meaningfully do that — a child layer on top of the signed ones can change the image in unrestricted ways.

So I think this should just be true, and no FIXME necessary.

image/signature/policy_eval.go

aguidirh

LGTM, I left only a nit.

aguidirh · 2025-10-17T15:28:27Z

image/signature/policy_eval.go

+		return false, PolicyRequirementError(fmt.Sprintf("No secure policy found for image %s.", transports.ImageName(image.Reference())))
+	}
+
 	// We have tested that len(reqs) != 0, so at least one req must have explicitly allowed this image.


nit: Is it needed to update this comment? It seems that having at least one req allowed is not enough to get to R312, since R299 will do a early return if at least one req is not allowed.

(Either way, I don’t think this PR changes the situation.)

The comment is trying to say “if we get to this point, len(reqs) > 0 and there was at least one req where allowed == true”, not “if len(reqs) > 0 and there was at least one req where allowed == true, we always get to this point”.

mtrmac

A full review now.

mtrmac · 2025-10-20T16:03:56Z

image/signature/policy_eval.go

 	// layers. Users must validate that the layers match their expected digests.
 	isRunningImageAllowed(ctx context.Context, image private.UnparsedImage) (bool, error)
+
+	// isInsecure returns true if the requirement allows images without any signatures.


“allows images with unauthenticated contents”, per #355 (comment) ?

(A possible hypothetical to think about is a PolicyRequirement that “the input reference is a digested reference” — in that case the contents of the image would be authenticated, but by the caller-provided input, not cryptographically. “allows images with unsigned contents”, maybe? Which of the two?)

mtrmac · 2025-10-20T16:05:18Z

image/signature/policy_eval.go

+// SetRejectInsecure modifies insecure policy requirement handling. If
+// passed `true`, policy checking by IsRunningImageAllowed will ignore the
+// "insecureAcceptAnything" policy type.
+func (pc *PolicyContext) SetRejectInsecure(val bool) {


The description (and name?) will need updating per the “authenticated contents”/“signed contents” discussion elsewhere.

(Choose the semantics that bootc needs; we can always add one more option with some other semantics in the future if it turned out to be necessary for other users.)

mtrmac · 2025-10-20T16:11:43Z

image/signature/policy_eval.go

 	}
+
+	if pc.rejectInsecure && !wasSecure {
+		return false, PolicyRequirementError(fmt.Sprintf("No secure policy found for image %s.", transports.ImageName(image.Reference())))


policyIdentityLogName would be a bit more appropriate, it would more directly point at the relevant policy.json scope.

mtrmac · 2025-10-20T16:15:37Z

image/signature/policy_eval.go

+// SetRejectInsecure modifies insecure policy requirement handling. If
+// passed `true`, policy checking by IsRunningImageAllowed will ignore the
+// "insecureAcceptAnything" policy type.
+func (pc *PolicyContext) SetRejectInsecure(val bool) {


(Thinking whether this should reject repeated calls, as an indication of a confused caller … we’d have to add an error return, and all callers would need to check it for all of this to make a difference — that wouldn’t really work, let’s not do that.)

mtrmac · 2025-10-20T16:19:19Z

image/signature/policy_eval_test.go

+	// insecureAcceptAnything only: should be rejected (leaves no secure requirements)
+	img = pcImageMock(t, "fixtures/dir-img-valid", "testing/manifest:insecureOnly")
+	res, err = pc.IsRunningImageAllowed(context.Background(), img)
+	assert.Equal(t, false, res)


assertRunningRejectedPolicyRequirement please, in both of the “error” situations.

github-actions bot added the image Related to "image" package label Sep 24, 2025

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Sep 24, 2025

dnm: Vendor changes from containers/container-libs#355

b92e606

jlebon mentioned this pull request Sep 24, 2025

skopeo: add --reject-insecure-policy containers/skopeo#2714

Draft

mtrmac reviewed Sep 24, 2025

View reviewed changes

image/signature/policy_eval.go Show resolved Hide resolved

mtrmac added the enhancement New feature or request label Oct 3, 2025

jlebon force-pushed the pr/policy-eval branch from 11c5783 to ef7b873 Compare October 5, 2025 11:46

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 5, 2025

dnm: Vendor changes from containers/container-libs#355

59897b2

podmanbot mentioned this pull request Oct 5, 2025

Sync: PolicyContext: add new SetRejectInsecure method containers/buildah#6409

Closed

mtrmac reviewed Oct 6, 2025

View reviewed changes

jlebon marked this pull request as ready for review October 6, 2025 15:22

aguidirh reviewed Oct 17, 2025

View reviewed changes

mtrmac reviewed Oct 20, 2025

View reviewed changes

PolicyContext: add new SetRejectInsecure method #355

Are you sure you want to change the base?

PolicyContext: add new SetRejectInsecure method #355

Uh oh!

Conversation

jlebon commented Sep 24, 2025

Uh oh!

jlebon commented Sep 24, 2025

Uh oh!

mtrmac left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cgwalters commented Sep 26, 2025

Uh oh!

jlebon commented Sep 26, 2025

Uh oh!

mtrmac commented Oct 1, 2025

Uh oh!

podmanbot commented Oct 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

aguidirh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mtrmac Oct 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mtrmac left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

PolicyContext: add new `SetRejectInsecure` method #355

PolicyContext: add new `SetRejectInsecure` method #355

mtrmac Oct 20, 2025 •

edited

Loading