if i do a local `podman build -t Containerfile build-config` the build succeeds, and results in an

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.

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.

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

i confirmed that reverting the default policy from rejectreject to insecureAcceptAnythinginsecureAcceptAnything will fix it... so now i'm trying to figure out another way... maybe setting "localhost" to insecureAcceptAnythinginsecureAcceptAnything

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

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

huh

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

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

doesn't work just adding

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

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

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 ?

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

i fixed it!

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

urgent PR

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)

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

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

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

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.

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

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'...

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

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

it's just 3 sed commands

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

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

oh true

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

is it possible to use jq to wrirte to it

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...

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

no yeah I was thinking about that as well

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

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

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

so maybe jq/yq?

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"
                    }

and also add something similar to cosign.yamlcosign.yaml

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

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

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

but if i was maintaing startingpoint, i'd want to use the files from ublue-os/configublue-os/config and mutate them at build time, yeah

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

yeah

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

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

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

i'm not thrilled with the naming of pki/containers/cosign.pubpki/containers/cosign.pub

it's a bit generic

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

i think it should be ublue-os.pubublue-os.pub to match the registry... but i don't know if registries.d/cosign.yamlregistries.d/cosign.yaml needs to match that or how it all works... i'm a bit new to this area

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

i'll tinker with renaming that for a distinct PR

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)

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.

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

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

which would hopefully aid in supporting downstream images like startingpoint

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

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

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

i was misreading

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

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

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

yay for small happy wins

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

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

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

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

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

now you're on a signed image

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.rpmublue-os-signing.noarch.rpm for users to install with rpm-ostree install -A ublue-os-signing.noarch.rpmrpm-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

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

huh

Bbsherman right, the only way to improve that is 1) have an installer which provides this ...

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

shout out to @xkrith for that one

j0rge•7/23/23, 3:10 PM

@bsherman nices fixes this morning thank you, main's done and I kicked off nvidia

j0rge•7/23/23, 3:11 PM

<-- must have these improvements lol