16:31:15 <dustymabe> #startmeeting fedora_coreos_meeting
16:31:15 <zodbot> Meeting started Wed Oct  4 16:31:15 2023 UTC.
16:31:15 <zodbot> This meeting is logged and archived in a public location.
16:31:15 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:31:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:31:15 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:31:21 <dustymabe> #topic roll call
16:31:23 <dustymabe> .hi
16:31:24 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:40 <marmijo> .hello marmijo
16:31:42 <zodbot> marmijo: marmijo 'Michael Armijo' <marmijo@redhat.com>
16:32:03 <travier> .hello siosù
16:32:04 <zodbot> travier: Sorry, but user 'siosù' does not exist
16:32:05 <travier> .hello siosm
16:32:07 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:32:31 <mnguyen> .hello mnguyen
16:32:32 <zodbot> mnguyen: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:32:39 <aaradhak> .hello aaradhak
16:32:40 <zodbot> aaradhak: aaradhak 'Aashish Radhakrishnan' <aaradhak@redhat.com>
16:33:06 <dustymabe> #chair marmijo travier mnguyen aaradhak
16:33:06 <zodbot> Current chairs: aaradhak dustymabe marmijo mnguyen travier
16:33:21 <lorbus> .hi
16:33:22 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:33:32 <lorbus> it's been a while o/
16:33:33 <dustymabe> #chair lorbus
16:33:33 <zodbot> Current chairs: aaradhak dustymabe lorbus marmijo mnguyen travier
16:33:36 <dustymabe> \o
16:34:03 <dustymabe> note if you want to bring something up today please add the `meeting` label to the ticket
16:36:10 <dustymabe> #topic Action items from last meeting
16:36:17 <dustymabe> #info there were no action items from last meeting
16:36:53 <dustymabe> looks like we only have one topic today
16:37:03 <dustymabe> #topic Handling of default users/groups
16:37:07 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/155
16:37:17 <jlebon> .hello2
16:37:18 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:37:26 <travier> I can introduce
16:37:29 <dustymabe> travier++
16:37:29 <zodbot> dustymabe: Karma for siosm changed to 1 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
16:37:48 <travier> The context is summarized in https://github.com/coreos/fedora-coreos-tracker/issues/155#issuecomment-1688447446
16:37:55 <travier> as long as the proposal
16:38:28 <travier> Rpm-ostree based systems currently split the user and group definition in two parts, one coming from the image as part of /usr/lib/(passwd|group), which is read only, and one copied into /etc/(passwd|group) from /usr/etc/(passwd|group) to make it writable for system administrators.
16:38:37 <travier> To "merge" those two sources, we use nss-altfiles (nss module configured in /etc/nsswitch.conf) to lookup users in both places.
16:38:44 <travier> nss-altfiles adds complexity to the user/group lookup process and user/group creations on rpm-ostree systems and creates user experience issues.
16:39:04 <travier> The ideal future is that we are not using nss-altfiles anymore and instead all (system) users and groups are defined by systemd sysusers configuration files and read from /etc/(passwd|group).
16:39:44 <lorbus> travier++
16:39:44 <zodbot> lorbus: Karma for siosm changed to 2 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
16:39:57 <fifofonix> .hi
16:39:58 <zodbot> fifofonix: fifofonix 'Fifo Phonics' <fifofonix@gmail.com>
16:39:58 <ravanelli> .hi
16:40:01 <zodbot> ravanelli: ravanelli 'Renata Ravanelli' <renata.ravanelli@gmail.com>
16:40:20 <lorbus> I continue to find RPMs that don't ship a proper sysusers config, hopefully we have them all converted soon..
16:40:29 <travier> lorbus++
16:40:29 <zodbot> travier: Karma for lorbus changed to 1 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
16:40:45 <dustymabe> #chair fifofonix ravanelli
16:40:45 <zodbot> Current chairs: aaradhak dustymabe fifofonix lorbus marmijo mnguyen ravanelli travier
16:40:53 <dustymabe> #chair jlebon
16:40:53 <zodbot> Current chairs: aaradhak dustymabe fifofonix jlebon lorbus marmijo mnguyen ravanelli travier
16:40:56 <travier> We're getting close to the point where sysusers is used in all packages in FCOS
16:41:10 <travier> polkit landed recently
16:41:19 <lorbus> :)
16:41:46 <travier> For new systems, the migration will be "easy". The trick is for existing systems.
16:42:26 <travier> I have not fully checked yet but we might be able to rely on grpck & pwck utils to do the actual migration for us
16:43:08 <travier> So the goal of raising this here is to discuss if we want to do this, the timeline, potential blockers, opinions, etc.
16:43:41 * dustymabe has never used grpck or pwck
16:43:49 <jlebon> ahh neat, hadn't encountered those before either
16:44:31 <dustymabe> definitely think the "migration" part needs to be done with care here
16:45:05 <travier> yes
16:45:06 <jlebon> proposal looks sane overall!
16:45:20 <travier> it might be something for F40, maybe with a change request?
16:45:30 <dustymabe> so ignition would now write out sysusers fragments when a user requests a new group get added?
16:45:51 <travier> only for system users/groups
16:46:09 <dustymabe> how does one know if a user/group is system versus non-system?
16:46:11 <travier> otherwise it can call useradd/groupadd like it does today AFAIK
16:46:43 <travier> the convention is UID < 1000 & nologin shell or `--system` option passed to useradd
16:46:54 <jlebon> and the Ignition spec has a knob for it
16:47:21 <dustymabe> ok
16:47:30 <dustymabe> SGTM
16:47:39 <travier> system (boolean): whether or not this account should be a system account. This only has an effect if the account doesn’t exist yet.
16:47:42 <jlebon> yeah, i don't think ignition strictly needs to change
16:47:44 <travier> https://coreos.github.io/ignition/configuration-v3_4/ indeed
16:47:59 <dustymabe> i will certainly be happy to get away from altfiles and all the little corner case problems we've had because of it
16:48:12 <jlebon> but it does fit the model better if it just emits sysusers dropins
16:48:51 <travier> note that with this change we'll make passwd & group files local state for all systems where right now only the diff was
16:49:31 <travier> but we haven't been able to make it a consistent / better experience so far
16:49:54 <dustymabe> travier: yes, but any new system users will get delivered by RPMs via sysusers fragments.. so that should be OK?
16:50:02 <travier> yes
16:50:09 <dustymabe> #proposed The proposal to drop the use of nss-altfiles and replace with systemd-sysuers usage has no opposition.
16:50:17 <travier> I'll likely make a change as I want to do this for Silverblue at the same time.
16:50:22 <jlebon> yeah, i don't think that matters too much. as soon as it's touched, it's stuck in local state mode anyway
16:50:36 <dustymabe> +1 - would IoT want to do the same?
16:50:41 <travier> probably
16:51:05 <dustymabe> which means we probably need to think less about our CoreOS facilities and more about how to implement the migration across the board
16:51:42 <dustymabe> #action travier to create a change proposal for F40 for switching away from nss-altfiles for OSTree based systems
16:52:04 <dustymabe> or I can switch the AI to someone else
16:52:16 <dustymabe> anybody opposed to the #proposed? Want to vote?
16:52:22 <jlebon> travier: thanks for looking at this!
16:52:29 <jlebon> +1
16:52:40 <lorbus> +1
16:52:44 <travier> let's vote before I create a change?
16:52:44 <mnguyen> +1
16:52:45 <fifofonix> +1
16:52:52 <travier> (Im' +1 since I'm porposing)
16:53:05 <travier> (I'm +1 since I'm proposing)*
16:53:25 <dustymabe> #agreed The proposal to drop the use of nss-altfiles and replace with systemd-sysuers usage has no opposition.
16:53:29 <dustymabe> +1 from me too
16:53:57 * dustymabe checks tickets with meeting label one more time
16:54:06 <dustymabe> nothing else for now
16:54:09 <dustymabe> #topic open floor
16:54:17 <jlebon> woah, really?
16:54:43 <dustymabe> #info we had a great test week! thanks ravanelli for running the test week!
16:54:46 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1565#issuecomment-1743269024
16:54:53 <mnguyen> ravanelli++
16:54:53 <zodbot> mnguyen: Karma for ravanelli changed to 1 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
16:54:54 <dustymabe> jlebon: yeah the other two were stale
16:54:55 <ravanelli> =)
16:55:09 <fifofonix> apologies for not completing the test case i said i would
16:55:22 <dustymabe> fifofonix: please do anyway :)
16:55:25 <travier> ravanelli++
16:55:25 <zodbot> travier: Karma for ravanelli changed to 2 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
16:55:30 <jlebon> it's never too late :)
16:55:30 <dustymabe> i think you can still fill out the form
16:55:35 <lorbus> ravanelli++
16:55:38 <zodbot> lorbus: Karma for ravanelli changed to 3 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
16:55:49 <fifofonix> will do
16:55:56 <dustymabe> so we do have releases going out later today (sorry we're a bit behind this week)
16:56:14 <jlebon> dustymabe: did you want to talk about that glibc CVE?
16:56:31 <dustymabe> but my attention got drawn earlier to https://bodhi.fedoraproject.org/updates/FEDORA-2023-2b8c11ee75 which just went "stable" an hour ago
16:57:19 <dustymabe> anybody want to weigh in on if we should take action there?
16:59:20 <jlebon> so, we're on 2.38-4 in next-devel and this is 2.38-6
17:00:08 <jlebon> there aren't a lot of changes apart from those CVE fixes
17:00:17 <travier> If we could get it in today's testing release that would be nice
17:00:19 <dustymabe> for f38 the fix is in glibc-2.37-10.fc38
17:00:28 <dustymabe> for f39 the fix is in glibc-2.38-6.fc39
17:01:01 <jlebon> let me check the diff on f38
17:01:05 <dustymabe> yeah, just more #work
17:01:05 <travier> It's not critical for us normally as it's a local SUID privilege escalation and things should be running inside of containers so not capable of getting to that
17:01:46 <travier> If we don't get this in today's releases, then it doesn't land in stable until 4 weeks
17:01:50 <travier> which is not great
17:01:53 <dustymabe> travier: correct
17:02:15 <travier> I expect exploits to appear really soon given the low complexity
17:02:22 <dustymabe> we will be switching to weekly releases of `next` now that we are in freeze, but `testing` and `stable` are still at a two week cadence
17:02:36 <jlebon> a bit larger diff on testing (we're on -5.fc38), but still not much
17:03:36 <dustymabe> marmijo: this means we'd need to do a new spin of `testing` and `next`
17:03:53 <marmijo> Okay, sounds good. I can get started on that
17:03:54 <dustymabe> we probably wouldn't be able to start shipping the updates until tomorrow morning
17:04:07 <dustymabe> i really wish our ppc64le builder wasn't being slow
17:04:49 <marmijo> I can monitor the builds throughout the rest of the day/night to ensure we get it out by today/tomorrow
17:04:55 <dustymabe> so it's settled then?
17:05:06 <jlebon> yeah, looking at this, i think the probability of regression here is quite low
17:05:23 <jlebon> so if it's not too late to add it for this week's triple, i'd vote for adding it
17:05:45 <dustymabe> "not too late" - we haven't run the release job(s) yet, but we were at that point
17:05:50 <dustymabe> all tests had passed, etc..
17:06:01 <jlebon> ahhh
17:06:27 <dustymabe> should we go ahead and ship stable today?
17:06:41 <dustymabe> since it's ready to go and our changes here wouldn't affect that?
17:07:36 <dustymabe> while we are at it let's get the crun-wasm changes into `next` too
17:07:38 <jlebon> i think we need more info on that first CVE. hard to tell how easily exploitable that actually is
17:08:09 <dustymabe> even so. would probably prefer some soak time in `testing` and then ship an ad-hoc if we did want to get it in stable
17:08:16 <jlebon> https://access.redhat.com/security/cve/cve-2023-4911
17:08:31 <travier> I'm suggesting only rebuilding testing & next with the fix, not stable
17:08:41 <dustymabe> we already will be doing a `next` release next week (weekly next releases now) so we could just have the person do a stable one too
17:09:03 <travier> According to me this is OK if this waits a week or two before landing in stable
17:09:12 <dustymabe> +1
17:09:19 <travier> Everyone that needs it right now can override replace
17:09:33 <dustymabe> we should create a tracker issue (for paperwork purposes)
17:09:58 <dustymabe> marmijo: grab me in matrix coreos channel and we can coordinate
17:10:39 <dustymabe> any other topics for open floor?
17:10:56 <marmijo> dustymabe: SGTM
17:11:52 <dustymabe> will close out the meeting soon
17:12:02 <fifofonix> just a comment: f39 for me has been a lot smoother than f38 (so far). so i'm happy.
17:12:11 <dustymabe> fifofonix: nice
17:12:21 <jlebon> https://blog.qualys.com/vulnerabilities-threat-research/2023/10/03/cve-2023-4911-looney-tunables-local-privilege-escalation-in-the-glibcs-ld-so has more useful info
17:12:47 <jlebon> > Our successful exploitation, leading to full root privileges on major distributions like Fedora, Ubuntu, and Debian, highlights this vulnerability’s severity and widespread nature.
17:13:31 <jlebon> i agree though we should let it bake in testing first, but should we consider an ad-hoc stable release ?
17:13:45 <dustymabe> right. let's just plan to do it along with the `next` next week
17:14:18 <jlebon> yeah, let's do that +1
17:14:46 <dustymabe> #endmeeting