Fix signature handling with additionalimagestore

[gursewak1997]

Copy images to local storage without signatures before bootc install to avoid signature invalidation errors. Falls back to original behavior if copy fails.

[gemini-code-assist]

Code Review

This pull request introduces a workaround to handle image signature invalidation errors by copying the image without signatures before installation. My review focuses on improving the robustness of the added shell script logic. I've suggested using trap for reliable temporary file cleanup and quoting variables to prevent potential shell injection or word-splitting issues.

[cgwalters]

It's going to be quite a UX hit to make a temporary deep copy of the input image just for this. I already feel the speed hit from having one copy, going to two would be painful.

I'm not opposed to a workaround but I think we should at least spend some time investigating better fixes - which would probably be in https://github.com/containers/container-libs/

See especially the conversation in containers/image#2590

I think we can reopen a related issue from that discussion or so?

---

In the short term maybe we can detect if the image has attached signatures and only do the fallback copy then?

[gursewak1997]

Images with signatures: Copy to local storage without signatures (fixes issue #126)
Images without signatures: Use original reference directly (no performance hit)
If signature check fails: Falls back to assuming no signatures (uses original reference)

[cgwalters]

It's not clear to me what the if is doing here. If skopeo fails due to being say out of disk space then we just...try to ignore that? That seems odd.

[cgwalters]

I don't think --storage-opt is necessary here, it gets inherited via the env var above right?

[cgwalters]

We're parsing JSON via grep which is pretty hacky; if e.g. one of the labels happens to contain the string "Signatures" we'll end up taking this code path incorrectly.

Also more importantly, does this even work? I don't see skopeo emitting that string when I run e.g. skopeo inspect -n containers-storage:registry.redhat.io/rhel9/rhel-bootc:9.6 |grep -i signatures

Also on that topic, it'd really help to have a regression test added for this too (though for that particular image it will need to be opt-in as it requires setting up RH pull secrets).

Hmm something a bit confusing to me here is actually...this I think isn't just "is the image signed" (because quay.io/centos-bootc/centos-bootc:stream10 is also signed) it's actually "does the container policy enforce signatures" and that's defined by the /etc/containers/policy.json in the target container image.

The RHEL image has

$ cat /etc/containers/policy.json 
{
    "default": [
        {
            "type": "insecureAcceptAnything"
        }
    ],
    "transports": {
        "docker": {
	    "registry.access.redhat.com": [
		{
		    "type": "signedBy",
		    "keyType": "GPGKeys",
		    "keyPaths": ["/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release", "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta"]
		}
	    ],
	    "registry.redhat.io": [
		{
		    "type": "signedBy",
		    "keyType": "GPGKeys",
		    "keyPaths": ["/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release", "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta"]
		}
	    ]
	},
        "docker-daemon": {
	    "": [
		{
		    "type": "insecureAcceptAnything"
		}
	    ]
	}
    }
}
$

(And centos-bootc has that exact thing too, but we're not enforcing it there)

So...if this is all true, one possible approach here is to just override /etc/containers/policy.json inside the to-disk flow instead.

[cgwalters]

We're parsing JSON via grep which is pretty hacky;

The real root problem here is writing nontrivial logic in shell script; I tried to minimize what we were doing here from the start. A possible approach to improve this is to move the logic to be executed from a systemd unit, then we just start and attach to that unit's output over ssh.

All the setup stuff can run before ssh even. I'll look at this.