i'm pretty sure this /etc/containers/policy.json is breaking some "normal" podman behavior 😦 speci

J

j0rge•7/23/23, 4:40 AM

so I will take every opportunity to talk to people on those teams, I just ain't got time for a bugzilla discussion, it needs to be a real convo

Bbsherman i'm pretty sure this /etc/containers/policy.json is breaking some "normal" podma...

G

Gerblesh•7/23/23, 4:41 AM

what's erroring?

G

Gerblesh•7/23/23, 4:42 AM

are you pulling from ghcr.io/ublue-os?

J

j0rge•7/23/23, 4:42 AM

and this feels like the evolution of my role here. Since I have to talk to these people for work related stuff anyway and I get to have those high bandwidth conversations then it's a no brainer to just apply that to what we do here

GGerblesh what's erroring?

B

bshermanOP•7/23/23, 4:43 AM

if i do a local

podman build -t Containerfile build-config

podman build -t Containerfile build-config

podman build -t Containerfile build-config

podman build -t Containerfile build-config

the build succeeds, and results in an image being created, but then,...

if I do

podman build -t Containerfile build-config2

podman build -t Containerfile build-config2

podman build -t Containerfile build-config2

podman build -t Containerfile build-config2

I get:

[2/2] COMMIT build-config2
Error: copying image "4f4d5f3b2f00971d1455bcbe0e5d4c86529bff0fc79f10fe2945d94e37251113": Source image rejected: Running image containers-storage:[overlay@/home/benjamin/.local/share/containers/storage+/run/user/10000/containers]@4f4d5f3b2f00971d1455bcbe0e5d4c86529bff0fc79f10fe2945d94e37251113 is rejected by policy.

[2/2] COMMIT build-config2
Error: copying image "4f4d5f3b2f00971d1455bcbe0e5d4c86529bff0fc79f10fe2945d94e37251113": Source image rejected: Running image containers-storage:[overlay@/home/benjamin/.local/share/containers/storage+/run/user/10000/containers]@4f4d5f3b2f00971d1455bcbe0e5d4c86529bff0fc79f10fe2945d94e37251113 is rejected by policy.

[2/2] COMMIT build-config2
Error: copying image "4f4d5f3b2f00971d1455bcbe0e5d4c86529bff0fc79f10fe2945d94e37251113": Source image rejected: Running image containers-storage:[overlay@/home/benjamin/.local/share/containers/storage+/run/user/10000/containers]@4f4d5f3b2f00971d1455bcbe0e5d4c86529bff0fc79f10fe2945d94e37251113 is rejected by policy.

[2/2] COMMIT build-config2
Error: copying image "4f4d5f3b2f00971d1455bcbe0e5d4c86529bff0fc79f10fe2945d94e37251113": Source image rejected: Running image containers-storage:[overlay@/home/benjamin/.local/share/containers/storage+/run/user/10000/containers]@4f4d5f3b2f00971d1455bcbe0e5d4c86529bff0fc79f10fe2945d94e37251113 is rejected by policy.

J

j0rge•7/23/23, 4:44 AM

like, I can attack the problem from a different angle when I can talk to someone who is a program manager or something. For example, container diffs would be a huge thing, and it can totally be implemented, we just need to be able to pitch the feature as a cloud native one. This will also save you a ton of money on your cloud bill. Everyone wins.

B

bshermanOP•7/23/23, 4:44 AM

i confirmed that reverting the default policy from

reject

reject

reject

reject to

insecureAcceptAnything

insecureAcceptAnything

insecureAcceptAnything

insecureAcceptAnything will fix it... so now i'm trying to figure out another way... maybe setting "localhost" to

insecureAcceptAnything

insecureAcceptAnything

insecureAcceptAnything

insecureAcceptAnything

Bbsherman if i do a local `podman build -t Containerfile build-config` the build succeeds...

G

Gerblesh•7/23/23, 4:45 AM

huh

Bbsherman i confirmed that reverting the default policy from `reject` to `insecureAcceptAn...

B

bshermanOP•7/23/23, 4:46 AM

doesn't work just adding

            "localhost": [
                {
                    "type": "insecureAcceptAnything"
                }
            ],

            "localhost": [
                {
                    "type": "insecureAcceptAnything"
                }
            ],

            "localhost": [
                {
                    "type": "insecureAcceptAnything"
                }
            ],

            "localhost": [
                {
                    "type": "insecureAcceptAnything"
                }
            ],

B

bshermanOP•7/23/23, 4:49 AM

if i'm correctly reading the skopeo/rpm-ostree bugs which necessitated the current complex config, hopefully those bugfixes will allow us to go back to a simple config...

was that your understanding @j0rge ?

B

bshermanOP•7/23/23, 4:54 AM

i fixed it!

B

bshermanOP•7/23/23, 4:54 AM

urgent PR

G

Gerblesh•7/23/23, 4:59 AM

I'm gonna try to PR some changes to the image signing in startingpoint, I realized that the configs are already there if one has ublue-os-signing installed (make it easier so one doesn't have to manually update the signing configs)

B

bshermanOP•7/23/23, 5:02 AM

https://github.com/ublue-os/config/issues/82

B

bshermanOP•7/23/23, 5:08 AM

https://github.com/ublue-os/config/pull/83

GitHub

fix: allow podman to use containers-storage transport locally by bs...

Fixes the bug by adding to the containers/policy.json.
Incidentally fixes typos in dates on spec files which were found during testing.
closes #82

G

Gerblesh•7/23/23, 5:11 AM

to fix this in startingpoint as well:
https://github.com/ublue-os/startingpoint/pull/117

GitHub

refactor: clean up image signing to line up more with upstream by g...

We can assume that the image signing configs are already installed from the config layer, so all we need is a couple of sed commands to change them to work with the user's repo.

G

Gerblesh•7/23/23, 5:12 AM

basically making it rely on the upstream signing configs

GGerblesh basically making it rely on the upstream signing configs

B

bshermanOP•7/23/23, 5:14 AM

the trick here is that startingpoint itself is signed with ublue-os key, but it's meant for users to make their own (eg, my own image is signed with a personal key)...

so the policy file needs to be managed by downstream user builds and have their own bits injected

Bbsherman the trick here is that startingpoint itself is signed with ublue-os key, but it'...

G

Gerblesh•7/23/23, 5:15 AM

basically I just replace the instances of ghcr.io/ublue-os with the user's repo eg: ghcr.io/gerblesh, replace ublue-os.pub with cosign.pub, you get the idea

G

Gerblesh•7/23/23, 5:15 AM

it's just 3 sed commands

B

bshermanOP•7/23/23, 5:16 AM

and probably we don't want to remove (sed replace) the ublue-os info since doing so would prevent those users from rebasing back to a signed ublue-os image

G

Gerblesh•7/23/23, 5:16 AM

oh true

G

Gerblesh•7/23/23, 5:16 AM

hm

G

Gerblesh•7/23/23, 5:16 AM

is it possible to use jq to wrirte to it

B

bshermanOP•7/23/23, 5:16 AM

i mean, i don't normally contribute to startingpoint

so I'm happy to defer to others for the direction of that repo/image

just pointing out the concern I see there

Bbsherman i mean, i don't normally contribute to startingpoint 🙂 so I'm happy to defer to...

G

Gerblesh•7/23/23, 5:17 AM

no yeah I was thinking about that as well

G

Gerblesh•7/23/23, 5:17 AM

it makes sense if a user would want to rebase back to a uBlue image

G

Gerblesh•7/23/23, 5:18 AM

so maybe jq/yq?

B

bshermanOP•7/23/23, 5:20 AM

i wonder if we could add some dummy stanzas to the files in startingpoint

eg, in policy.json add

            "ghcr.io/IMAGE_REGISTRY": [
                {
                    "type": "sigstoreSigned",
                    "keyPath": "/usr/etc/pki/containers/IMAGE_REGISTRY.pub",
                    "signedIdentity": {
                        "type": "matchRepository"
                    }

            "ghcr.io/IMAGE_REGISTRY": [
                {
                    "type": "sigstoreSigned",
                    "keyPath": "/usr/etc/pki/containers/IMAGE_REGISTRY.pub",
                    "signedIdentity": {
                        "type": "matchRepository"
                    }

            "ghcr.io/IMAGE_REGISTRY": [
                {
                    "type": "sigstoreSigned",
                    "keyPath": "/usr/etc/pki/containers/IMAGE_REGISTRY.pub",
                    "signedIdentity": {
                        "type": "matchRepository"
                    }

            "ghcr.io/IMAGE_REGISTRY": [
                {
                    "type": "sigstoreSigned",
                    "keyPath": "/usr/etc/pki/containers/IMAGE_REGISTRY.pub",
                    "signedIdentity": {
                        "type": "matchRepository"
                    }

and also add something similar to

cosign.yaml

cosign.yaml

cosign.yaml

cosign.yaml

G

Gerblesh•7/23/23, 5:20 AM

i'd still want to keep in line with the upstream signing configs

B

bshermanOP•7/23/23, 5:20 AM

but if i was maintaing startingpoint, i'd want to use the files from

ublue-os/config

ublue-os/config

ublue-os/config

ublue-os/config and mutate them at build time, yeah

G

Gerblesh•7/23/23, 5:21 AM

yeah

G

Gerblesh•7/23/23, 5:21 AM

the registries.d is easy because I can just copy the file

B

bshermanOP•7/23/23, 5:22 AM

i'm not thrilled with the naming of

pki/containers/cosign.pub

pki/containers/cosign.pub

pki/containers/cosign.pub

pki/containers/cosign.pub

it's a bit generic

B

bshermanOP•7/23/23, 5:22 AM

i think it should be

ublue-os.pub

ublue-os.pub

ublue-os.pub

ublue-os.pub to match the registry... but i don't know if

registries.d/cosign.yaml

registries.d/cosign.yaml

registries.d/cosign.yaml

registries.d/cosign.yaml needs to match that or how it all works... i'm a bit new to this area

B

bshermanOP•7/23/23, 5:24 AM

i'll tinker with renaming that for a distinct PR

G

Gerblesh•7/23/23, 5:24 AM

idk I just was sticking with what was there before (cosign.pub in the root of the repo)

B

bshermanOP•7/23/23, 5:24 AM

right, i'm only suggesting that our ublue-os/config RPM could probably have improved, more specific naming.

G

Gerblesh•7/23/23, 5:24 AM

I'm honestly horrible with naming and I don't understand a lot of these configs so I probably shouldn't be touching much of it

B

bshermanOP•7/23/23, 5:24 AM

which would hopefully aid in supporting downstream images like startingpoint

B

bshermanOP•7/23/23, 5:30 AM

oh, ublue-os already has the better naming i'd hoped for

B

bshermanOP•7/23/23, 5:31 AM

i was misreading

K

Kyle Gospo•7/23/23, 5:31 AM

only downside is that rebasing from a stock image is a pain in the ass

B

bshermanOP•7/23/23, 5:31 AM

yay for small happy wins

K

Kyle Gospo•7/23/23, 5:31 AM

but it's as clean as we can make it imo

K

Kyle Gospo•7/23/23, 5:31 AM

podman pull ghcr.io/ublue-os/config && rpm-ostree install --assumeyes --apply-live --force-replacefiles $(find ~/.local/share/containers -name ublue-os-signing.noarch.rpm 2>/dev/null) && rpm-ostree rebase --uninstall $(rpm -q ublue-os-signing-* --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{Arch}') ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:latest

podman pull ghcr.io/ublue-os/config && rpm-ostree install --assumeyes --apply-live --force-replacefiles $(find ~/.local/share/containers -name ublue-os-signing.noarch.rpm 2>/dev/null) && rpm-ostree rebase --uninstall $(rpm -q ublue-os-signing-* --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{Arch}') ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:latest

podman pull ghcr.io/ublue-os/config && rpm-ostree install --assumeyes --apply-live --force-replacefiles $(find ~/.local/share/containers -name ublue-os-signing.noarch.rpm 2>/dev/null) && rpm-ostree rebase --uninstall $(rpm -q ublue-os-signing-* --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{Arch}') ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:latest

podman pull ghcr.io/ublue-os/config && rpm-ostree install --assumeyes --apply-live --force-replacefiles $(find ~/.local/share/containers -name ublue-os-signing.noarch.rpm 2>/dev/null) && rpm-ostree rebase --uninstall $(rpm -q ublue-os-signing-* --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{Arch}') ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:latest

K

Kyle Gospo•7/23/23, 5:32 AM

pull the rpm containing the keys, install it (with no reboot needed), then uninstall it and rebase at the same time

K

Kyle Gospo•7/23/23, 5:32 AM

now you're on a signed image

B

bshermanOP•7/23/23, 5:33 AM

right, the only way to improve that is 1) have an installer which provides this by default... or 2) provide the

ublue-os-signing.noarch.rpm

ublue-os-signing.noarch.rpm

for users to install with

rpm-ostree install -A ublue-os-signing.noarch.rpm

rpm-ostree install -A ublue-os-signing.noarch.rpm

then the rebase command should work...

well, that's what your one liner does

just it's scary to the average user

G

Gerblesh•7/23/23, 5:34 AM

huh

i'm pretty sure this /etc/containers/policy.json is breaking some "normal" podman behavior 😦 speci

Similar Threads

Similar Threads

Similar Threads