Random thought.... are there any plans for a hyprland build of ublue?
Random thought.... are there any plans for a hyprland build of ublue?
XThere are a lot of community images but not "official" ones. It would need a maintainer who uses the image and is willing to support others using it. Could be basically any community member, though.
BWith hypr now beibg available for install direct from dnf in fedora 39, I know I could just rpm- ostree install it at build, but was just curious
BWould someone with 0 experience be able to be a community maintainer?
XWell, you'd have to be willing to learn of course.
BLearning is a favorite hobby
BJust trying to figure if I could commit to it with work plus my 2 kids
XI think other high-level maintainers here have similar situations, and the community is here to help.
XIt's just needed that some person does the effort to kickstart it and commits to at least looking after the issues and PRs.
X
EThe public signatures for our hwcompat images don't align. I think I should regenerate the key pairs for all of them:
https://github.com/ublue-os/bazzite/pull/615
https://github.com/ublue-os/bazzite/pull/615
Jkey looks the same in bazzite? which one doesn't match?
EThe keys for ASUS, Surface, and Framework base images (Kinoite and Silverblue). I wrote a test for Bazzites CI to verify the sigs before building the image
Joh I hadn't noticed that?
EI hadn't either because they successfully sign. It's very odd
JI think we just put the previous cosign.pub in those repos and use the org-wide secret?
EYeah
JI hadn't even noticed that, good catch!
EI figured we might as well add these tests to our downstream images. Establishes some form of verification. I wish the ci-test images were signed too
EWe can even do this for the Chainguard images Bluefin DX pulls from
Jci-test has been around a year longer than I anticipated
Jfeels like the upstream of silverblue/kinoite are getting a ton of attention now but the fedora parts are less maintained than they were before. 
Jthe fedora one didn't build for 10 days!
Jthis verification is a great idea!
EThank you! I was brainstorming over this yesterday after looking over a lot of the images Chainguard has and going through their documentation. Then this morning I put two and two together
EAh, that's exactly it. Our public keys for these don't align. Will update them
Jseems like an obvious check once you see it, that's amazing.
Jthat's a legit real improvement in our supply chain security, nice!
EI'm pretty happy about it :). I'll get all of our downstream stuff PRd with the test today
Jyou can also file an issue with a help wanted if people want an easy fix to learn how to PR
Jaka you don't have to do every repo, heh
EHa. That's a great idea
Jthen when people PR it'll be a checklist too
RThought: Can't we create a few GitHub Actions such as sign-image and verify-image, and use them across all repos? That way there will be no signing logic in each repo, and they are all controlled in main or similar
Since all images use the same signing keys, the custom action could have the main/cosign.pub location hard-coded
Since all images use the same signing keys, the custom action could have the main/cosign.pub location hard-coded
RThe action would incude "setup-cosign" and "verify-image" steps, so each repo will need a single line in the GHA workflow
EWe very well could. I really like that idea
Jyeah there's a few places where we could start to move to centralized actions
EThough I'd make it so that we could pass whatever public key we wanted versus hard coding it to main so that's useful downstream too
RYeah, maybe hard-code the default value to ublue, but make it an input so other images can change it if required
Jthen the maintenance on the repos would go from "copy and pasting improvements" to just dependabot bumping the version for us. That would be a huge win for long term maintenance and sustainability
REven downstream would need to verify the base image against the ublue org, so defaulting to ublue values makes sense.
EVery true. I can piece this together. It'd be rather simple too 
Jsig store folks would dig that too, it's a great idea/story
RHere's my current sign-image action if it helps. I hadn't thought about verifying the images before using them though, but i like it!
https://github.com/rsturla/eternal-main/blob/main/.github/actions/sign-image/action.yml
https://github.com/rsturla/eternal-main/blob/main/.github/actions/sign-image/action.yml
GitHub
The base configuration for the Eternal Linux project. All Eternal images inherit the configuration defined here. - rsturla/eternal-main
Jyeah verifying first is so clutch!
RI am still wondering how we can verify the third-party images before using them though... They are set in the Dockerfile as
COPY --from=<image>, so would we need to keep an up-to-date list of external images in the GHA workflow, or is there some integration we can do during builds?Jwe need to ask fedora to sign their images
RSorry, I'm mainly thinking about the chainguard ones. Should have mentioned that
JI'm reasonably certain they will do this, they just seem to be behind on the infra parts of pushing oci images in general
Joh
RChainguard images should already be signed, but I just don't know if there's a way to automatically verify them before using it, or if we will need another step to verify an array of images in GHA
