Meeting started at 2026-05-27 15:30:23 UTC

The Meeting name is 'fedora_coreos_meeting'

!hi

Hristo Marinov: Hristo Marinov (hricky) - he / him / his

!hi

Cade: Cade Jacobson (cadejacobson)

!hi

No Fedora Accounts users have the @peytonrobertson:matrix.org Matrix Account defined

Good morning/afternoon/evening. Let's wait a little bit longer for more folks to attend

!hi

dustymabe: Dusty Mabe (dustymabe) - he / him / his

!hi

jbtrystram: Jean-Baptiste Trystram (jbtrystram) - he / him / his

!hi

rapneset: Rolv Apneseth (rapneset)

!hi

Angel Cervera Roldan: Angel Cervera Roldan (acervera)

!hi

Timothée Ravier: Timothée Ravier (siosm) - he / him / his

There's not much to discuss with the F45 release schedule at the moment. We can move on to the main topics unless there's something specific to bring up.

Alright, let's move into the main topics. We have 4, so I'll go in the order the meeting label was added. Please stop me if something is more pressing!

Timothée Ravier: would you like to introduce this one?

sure

The idea is to switch to zstd by default for layer compression for the container images

That should reduce network bandwith required for update and potentially make them faster but I have not done benchmarks to confirm that.

Work would be to do those benchmarks and then do the switch

current compression is gzip ?

yes

!hi

Nemric: Emeric Chassagne (nemric)

Is the testing similar to what we did for initramfs?

Not exactly as this is for the container image not the initrd but it's a similar idea

It looks like the first step would be to run a benchmark to understand the speed and bandwidth improvements

yes

I don't think there is much more to talk about. We can do a vote that it's what we want to do and we'll get to it at some point?

!hi

spresti: Steven Presti (spresti)

+1 from my side. we can bundle that into `next` for some time because we are wanting to experiment with a few things there anyway

+1 from my side

+1

+1

If the same tools can be used as for benchmarking initramfs compression, I can try.

+1

https://github.com/coreos/fedora-coreos-tracker/issues/2152

expressed my concerns in the ticket there

Summary for this one is that if we want to keep up with vulnerabilities in the kernel, we'll likely have to start denylisting/blacklisting kernel modules for features likely 99% of Fedora CoreOS users never use

!hi

Clément Verna: Clement Verna (cverna) - he / him / his

One example from the recent Dirty Frag vulnerabilities is rxrpc sockets

This is needed for AFS support (Andrew File System) and this is mostly a datacenter filesystem

so you would definitely know if you needed this module

denylisting modules like that also does not prevent them from being loaded, it only makes it explicit

Hmm, so are we are looking at it from the stance reducing security boundary footprint?

It's quite an opinionated move to make, but I see where you're coming from. I don't really have strong opinions.

I would vote to stick with whatever is fedora default.

yes, the less modules can be loaded by unprivileged users, the smaller the attack surface and thus the less work we have to do to push updates urgently

Naive question, could we run into the circumstance, where we ship a kernal that does not have modules enabled but a user enables said module? resulting in our priority not being to patch said issue and user fall into not knowing about that issue?

I'm not sure I understand your question. We would only deny modules available in the Fedora kernel

(and that would only apply to feature modules, not hardware support ones)

Could we run into a situation where a user manually enables a denylisted module leaving them exposed to vulnerabilities without realizing it (since we wouldn't try to patch it).

I think there is a lot of value we derive from just accepting whatever the fedora kernel maintainer's assessment of the security implications of a CVE is.

If we start being much different, that value starts to go away and we need our own dedicated team for that stuff

Thank you marmijo for re-wording that

yes, users that would enable a module that we deny would accept the risk associate with it.

Note that this is not replacing the assesment from the Fedora's kernel maintainer

they can only patch bugs so fast

and we can not realistically realease updates daily

ok, thank you. I agree it makes sense to reduce the attack surface where possible

I would be curious to explore the release updates daily, maybe rethinking the stream we have.

1. extra maintenance over time

2. different kernel configuration than fedora ships

I just think anything that adds to our load here has risks:

3. are we going to do the same thing downstream? If so then now we are differing from RHEL. If not then our upstream and downstream act different too

I feel this is the general model towards patching CVEs

Releasing daily is not realistic with auto updates enabled for every one

I also think it makes sense - specially given that it is not hard for a user to enable them in ignition.

I don't uderstand why you're saying "different kernel configuration" Dusty

And for 3 I would say that yes we should push that as well

I don't think everyone has auto updates enabled, at least from the countme stats we have

"different kernel configuration" == "Fedora CoreOS isn't affected by CVE XYZ, but Fedora Cloud is"

But I am side tracking the conversation :)

basically it requires more scrutiny each time a security issue happens

If we move to daily updates then this pratically guarentees that people will disable auto updates

We already need to do that?

do decide if we need to fasttrack something or do a release early

and while Timothée Ravier and rapneset are doing a good job of analyzing security issues now (@bgilbert used to help with this in the past). I'm not entirely confident we'll always have someone super well versed in security in this team and able to maintain the "list of modules that aren't supporting Fedora CoreOS use cases"

FWIW it'd be interesting to collaborate on a list with the Cloud variants, or as a general opt-in "I want to harden my install" package?

Jeremy Cline happy to start something that works accross server variants at least

yeah. basically I want this list to be determined by someone who is an expert in "insert use case here"

I don't think this group (coreos) is well enough versed to maintain it

the kernel surface area is vast

and trying to play that game is not something we should enter into lightly

note that the kernel surface is mostly drivers, and we would not look at that here, only features

I understand you concerns Dusty but I don't think they are warranted

Disabling a kernel module being built is a big hammer and will forever break someone's spacebar-heating workflow or whatever, but there's probably a good selection of "you likely don't need this for most use cases" that dropin configs to denylist would be nice for

I don't know

for example we still have the [kernel mitigations things](https://github.com/coreos/fedora-coreos-config/blob/0c62bd9d22a1f469729a9514d5064781db5f1a07/image-base.yaml#L12).. do we even still need them?

from memory yes

Jeremy Cline: why couldn't we just make them modules that aren't loaded by default in the main kernel rpm (not something specific to a variant)?

the kernel package is common to all Fedora variants so you would have to create a list that works for all potential use cases of Fedora so essentially the list is empty as otherwise we would not have the module in the kernel in the first place

Sure, if you want a more centralized list I don't think that's a problem either, and I have no strong opinion on where the list(s) are maintained. Obviously different variants have different targets and it's really a matter of who you want to wrap up in the specifics.

IMO Fedora kernel team likely doesn't want to be interested in all the specifics so keeping a list there is harder than elsewhere

!hi

Jonathan Lebon: None (jlebon)

We don't need to decide this today. I'll work with Jeremy to get this started and give it a try on the Atomic Desktops and we can revisit that later. This will likely be a change request for the Atomic Desktops.

reading the scrollback; this has some similarities to systemd presets where there's global lists and per-edition additions. one way to structure this is similarly a global list and a shared "workstation" and "server" sublist

basically I think having a "desktop use case" and "server use case" profile should suffice. and would allow sharing amongst the working groups

agree.

right

i will say though i think part of the motivation here is actually rooted in the fact that our release process is too manual

and so that's another place where pain could be alleviated

While I agree that we can always improve the release process to be less manual, I disagree that it's the motivation for this. Releasing faster would not help.

On the contrary, I want us to be able to release less often

I didn't say faster

(in the sense of releasing at a higher cadence)

Looks like we're wrapped up here pretty well. Should we do a proposed on this for now, or want me to just add a discussion summary to the issue?

a summary is fine for me

unless folks want to vote

I'm not sure we'll have enough time for our other 2 topics. jbtrystram are these topics pressing for today?

Not really :)

okay, they'll be first on the list for next week!

https://github.com/coreos/afterburn/pull/1264

Just plugging this PR again briefly! I've gone back and forth on some of the dependencies, but I think I've finally been able to keep the crates FIPS/OpenSSL compliant while completing the logic for password hashing:

Awesome, thank you for working on that, I will try and take a look today or tomorrow

Thanks, all, for joining today and thanks for the lively discussion on the topics!