Failed to run encrypt script at coco-key-provider image

[GabyCT]

Describe the bug

Following the documentation at https://github.com/confidential-containers/guest-components/tree/main/attestation-agent/coco_keyprovider#docker

When I do $ docker pull ghcr.io/confidential-containers/coco-keyprovider And then $ docker run ghcr.io/confidential-containers/coco-keyprovider /encrypt.sh -h

I got the following error

docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/encrypt.sh": stat /encrypt.sh: no such file or directory: unknown.

I even entered the container and I can confirm that the script is not there

How to reproduce

``

CoCo version information

guest components

What TEE are you seeing the problem on

None

Failing command and relevant log output

No response

[portersrc]

It looks like the image at ghcr is a bit stale. The documentation may need an update, but more importantly, it seems the CI job to rebuild and push this on release has been failing.

  > pushing ghcr.io/confidential-containers/coco-keyprovider:v0.9.0 with docker:
------
ERROR: denied: permission_denied: write_package

I'm not sure of the exact steps, but I think we need a little admin management on the coco packages here. We probably need to create that package and enable it for writing. Then double-check that the CI action works for future releases.

[Xynnn007]

Oh, yes. The document has been updated recently in https://github.com/confidential-containers/guest-components/pull/673 as the original coco-keyprovider has not been updated for more than 1 year. But the GHA has not been triggered yet.

https://github.com/confidential-containers/guest-components/blob/main/.github/workflows/aa_release.yml

We need to trigger this manually asap.

[Xynnn007]

some ways

1. modify the image pushing for every merging
2. cut a 0.9.1 release to trigger this
3. wait for 0.10.0 release to trigger this

btw @GabyCT as a workaround, you could use the guide to build an image locally to fulfill.

[portersrc]

Hi, I think we can close this?

When Ding cut guest-components v0.10.0, the CI for v0.10.0 ran correctly. Here's the updated coco-keyprovider package. (As mentioned above, we don't want to use the old, archived one here).

My only question is: Do we care about having a v0.10.0 tag on the coco-keyprovider package? It just has the sha and "latest" tags right now.