AIt would be a lot better
ABut I don’t know how to use it and looks like there’s no documentation short of asking to fedora people 
AYeah
GFedora people are scary lol
GI would feel very bad for hounding them about lorax
Gis there any examples of how fedora uses lorax?
AThe script you posted earlier
AGhuh
Galr i'll try loading up my fedora VM and start messing around
Bhmmm
Bi'm seeing a weird error doing podman builds locally and it's... and it's referencing invalid policy
Jyeah when you said you were some of it was over your head, that's why I call people in here explorers, we're the first ones trying to use existing stuff in a new way and running into the classic onboarding problem
Jand fixing problems like that interest me.
Bi'm pretty sure this /etc/containers/policy.json is breaking some "normal" podman behavior 
specifically the default reject
specifically the default reject
Jso 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
Gwhat's erroring?
Gare you pulling from ghcr.io/ublue-os?
Jand 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
Bif i do a local
the build succeeds, and results in an image being created, but then,...
if I do
I get:
podman build -t Containerfile build-configthe build succeeds, and results in an image being created, but then,...
if I do
podman build -t Containerfile build-config2I get:
Jlike, 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.
Bi confirmed that reverting the default policy from
reject to insecureAcceptAnything will fix it... so now i'm trying to figure out another way... maybe setting "localhost" to insecureAcceptAnythingBdoesn't work just adding
Bif 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 ?
was that your understanding @j0rge ?
Bi fixed it!
Burgent PR 
GI'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)
BBGitHub
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
Incidentally fixes typos in dates on spec files which were found during testing.
closes #82
GGitHub
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.
Gbasically making it rely on the upstream signing configs
Bthe 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
so the policy file needs to be managed by downstream user builds and have their own bits injected
Gbasically 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
Git's just 3 sed commands
Band 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
Goh true
Ghm
Gis it possible to use jq to wrirte to it
Bi 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
so I'm happy to defer to others for the direction of that repo/image
just pointing out the concern I see there
Gno yeah I was thinking about that as well
Git makes sense if a user would want to rebase back to a uBlue image
Gso maybe jq/yq?
Bi wonder if we could add some dummy stanzas to the files in startingpoint
eg, in policy.json add
and also add something similar to
eg, in policy.json add
and also add something similar to
cosign.yamlGi'd still want to keep in line with the upstream signing configs
Bbut if i was maintaing startingpoint, i'd want to use the files from
ublue-os/config and mutate them at build time, yeahGyeah
Gthe registries.d is easy because I can just copy the file
Bi'm not thrilled with the naming of 
it's a bit generic
pki/containers/cosign.pub it's a bit genericBi think it should be
ublue-os.pub to match the registry... but i don't know if registries.d/cosign.yaml needs to match that or how it all works... i'm a bit new to this area