16:29:01 <lucab_> #startmeeting fedora_coreos_meeting
16:29:01 <zodbot> Meeting started Wed Aug  3 16:29:01 2022 UTC.
16:29:01 <zodbot> This meeting is logged and archived in a public location.
16:29:01 <zodbot> The chair is lucab_. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:29:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:29:01 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:29:14 <lucab_> .hello lucab
16:29:15 <zodbot> lucab_: lucab 'Luca BRUNO' <lucab@redhat.com>
16:29:45 <lucab_> #topic roll call
16:29:52 <jlebon> .hello2
16:29:53 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:30:09 <dustymabe> .hi
16:30:10 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:31 <lucab_> #chair jlebon dustymabe
16:30:31 <zodbot> Current chairs: dustymabe jlebon lucab_
16:31:10 <travier> .hello siosm
16:31:11 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:31:49 <mnguyen> .hello mnguyen
16:31:50 <zodbot> mnguyen: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:32:39 <gursewak> .hi
16:32:40 <zodbot> gursewak: gursewak 'Gursewak Singh' <gurssing@redhat.com>
16:33:12 <lucab_> #chair travier mnguyen gursewak
16:33:12 <zodbot> Current chairs: dustymabe gursewak jlebon lucab_ mnguyen travier
16:35:05 <lucab_> I'll start now, other folks may join later
16:35:17 <lucab_> #topic Action items from last meeting
16:35:35 <lucab_> jlebon to reach out to OpenStack experts to see if we can detect when the platform is expecting machines to do IPV6 network configuration via SLAAC (to get eui64 based IPv6 addresses)
16:35:52 <lucab_> #link https://github.com/coreos/fedora-coreos-tracker/issues/907#issuecomment-1197279537
16:36:03 <jlebon> sigh, i haven't done that yet. can you re-action it?
16:36:09 <lucab_> ack
16:36:16 <dustymabe> lucab_: and also ignore the `meeting` ticket that's related
16:36:23 <lucab_> #action jlebon to reach out to OpenStack experts to see if we can detect when the platform is expecting machines to do IPV6 network configuration via SLAAC (to get eui64 based IPv6 addresses)
16:36:44 <lucab_> ack, dropped the label
16:36:47 <aaradhak> .hi
16:36:48 <zodbot> aaradhak: aaradhak 'Aashish Radhakrishnan' <aaradhak@redhat.com>
16:37:37 <lucab_> there is also the mstflint ticket from last time, is that a spurious label too?
16:38:22 <dustymabe> i think for that one we were waiting for discussion in the ticket to die down (it was a brand new ticket)
16:38:30 <dustymabe> but there hasn't been any further discussion in the ticket
16:38:57 <dustymabe> IOW I don't know if any future stimulus is coming in - we might as well re-discuss and try to make a decision
16:39:14 <lucab_> #topic New Package Request: mstflint
16:39:26 <lucab_> #link https://github.com/coreos/fedora-coreos-tracker/issues/1264
16:40:02 <dustymabe> summary from last meeting in https://github.com/coreos/fedora-coreos-tracker/issues/1264#issuecomment-1197265175
16:40:04 <lucab_> Do we want to get some further feedback from the reporter?
16:40:34 <jlebon> i think we should give them a bit more time to respond before carrying out a decision
16:40:49 <lucab_> it looks like there were some pros & cons, but overall the room temperature wasn't much in favour
16:40:53 <dustymabe> jlebon: should we ask them a question directly? I'm not sure they know they need to respond
16:41:20 <lucab_> in any case, it likely needs a package split
16:41:30 <bgilbert> .hi
16:41:31 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:41:32 <jlebon> dustymabe: yeah, let's do that
16:41:37 <lucab_> do we want to push the reporter in that direction as a starting point?
16:41:53 <lucab_> #chair aaradhak bgilbert
16:41:53 <zodbot> Current chairs: aaradhak bgilbert dustymabe gursewak jlebon lucab_ mnguyen travier
16:41:54 <dustymabe> yeah, but I don't really want to ask them to split the package if it's unlikely we'll include it
16:42:07 <jlebon> +1 agreed
16:42:18 <lucab_> there is a chance of that outcome, yes
16:42:20 <dustymabe> I'd kind of operate along the lines of "if the package were split properly, then what action would we take"
16:42:40 <lucab_> OTOH it would help a container image size diet too
16:42:42 <dustymabe> and work backwards from there
16:43:28 <dustymabe> agree. I just want to manage expectations up front
16:44:26 <lucab_> I'll re-ping the reporter. Let's then wait for further async discussion there.
16:44:55 <dustymabe> ack
16:45:23 <lucab_> #topic tracker: Fedora 37 changes considerations
16:45:30 <lucab_> #link https://github.com/coreos/fedora-coreos-tracker/issues/1222
16:45:45 <dustymabe> a few new ones at the very bottom
16:46:18 <lucab_> dustymabe: thanks for keep pushing updates there!
16:46:34 <travier> The LXQt should not impact us
16:46:34 <dustymabe> :) - thanks lucab_
16:46:45 <dustymabe> travier: correct
16:47:00 <travier> The support for RPi 4 is nice but does not impact us either?
16:47:11 <jlebon> dustymabe: i think there were new ones since the last refresh
16:47:16 <dustymabe> and Officially Support RPi4 I think is mostly just a "FYI" that most all drivers for hardware are now in our kernel
16:47:26 <dustymabe> jlebon: probably, I need to run the script again
16:47:34 <dustymabe> if you all want to wait a few minutes I can sync
16:47:35 <lucab_> jlebon: I think there is one from you too, right?
16:48:11 <jlebon> mostly in name only, but yes :)
16:48:45 <dustymabe> please hold...
16:49:17 <lucab_> #link https://pagure.io/fesco/issues?status=Closed&milestone=Fedora+Linux+37
16:51:05 <dustymabe> ok
16:51:08 <lucab_> there should be a BIND-9.18 which shouldn't affect us
16:51:23 <dustymabe> subtopic 220. Preset All Systemd Units on First Boot
16:51:37 <dustymabe> refresh page to see updated list
16:52:20 <lucab_> that's the one with jlebon name, yes
16:52:26 <dustymabe> yep
16:53:06 <lucab_> jlebon: any expected breakage for FCOS from that?
16:53:08 <travier> this one is "from us"
16:53:23 <jlebon> this will allow us to eventually remove the workaround in Ignition, but it's not tied to the f37 rebase
16:53:49 <jlebon> lucab_: i need to do a final test once the change is made in Fedora, but there shouldn't be
16:54:17 <jlebon> i'm planning to file an Ignition ticket to track removal
16:54:39 <dustymabe> jlebon: do we have any tracker issue tickets related to the work there? should we create one/
16:54:57 <lucab_> I think we had one (or more), but I can't find it
16:55:27 <lucab_> #link https://fedoraproject.org/wiki/Changes/Preset_All_Systemd_Units_on_First_Boot
16:55:35 <jlebon> dustymabe: i don't think so. there's no work to do just yet in FCOS. so the Ignition issue should suffice.
16:55:49 <dustymabe> but there is an ignition issue?
16:56:02 <dustymabe> can you share?
16:56:03 <jlebon> there will be :)
16:56:23 <dustymabe> ahh ok. Let's link to that from this changes issue so we can follow that work when it's created
16:57:02 <dustymabe> subtopic 221. Public release of the Anaconda Web UI preview image
16:57:13 <dustymabe> Nothing to do. We don't ship/use anaconda.
16:57:13 <lucab_> #action jlebon to ensure there are FCOS/Ignition to track the preset changes
16:57:33 <dustymabe> subtopic 222. BIND 9.18
16:57:48 <travier> we don't ship bind?
16:57:54 <dustymabe> not that I'm aware of
16:58:05 <lucab_> same, we maybe ship bind-utils but it shouldn't be a concern
16:58:23 <dustymabe> Nothing to do. We may ship bind-utils, but it shouldn't be a concern.
16:58:33 <dustymabe> subtopic 223. ibus-libpinyin 1.13
16:58:58 <travier> we don't ship ibus
16:58:58 <dustymabe> "Nothing to do. We don't ship it." ?
16:59:01 <dustymabe> +1
16:59:18 <dustymabe> subtopic 224. SELinux Parallel Autorelabel
16:59:25 <travier> We donet support auto-relabel
16:59:29 <travier> don't*
16:59:34 <dustymabe> yeah I didn't think so..
16:59:39 <lucab_> #link https://fedoraproject.org/wiki/Changes/SELinux_Parallel_Autorelabel
16:59:47 <dustymabe> actually do we disable it today, though?
16:59:58 <dustymabe> i.e. if someone tries, what happens?
17:00:03 <travier> you can not enable it as it needs a writable /
17:00:11 <lucab_> it mentions `restorecon` too, there may be some easy gains there
17:00:45 <travier> it should not impact us
17:01:01 <dustymabe> hmm
17:01:32 <walters> (rpm-ostree has multithreaded relabeling of imported packages for a long time)
17:01:41 <travier> :D
17:01:44 <dustymabe> it seems as if a relabel can be triggered by more than one thing
17:01:55 <dustymabe> After a system's SELinux mode is switched from disabled to enabled, or after an administrator runs fixfiles onboot
17:02:05 <dustymabe> in addition to the manual `touch /.autorelabel`
17:02:11 <travier> It all ends up writting a file like /.autorelabel
17:02:21 <travier> all the commands to that internaly
17:02:24 <walters> only thing we should support relabeling is /etc and /var
17:02:38 <dustymabe> travier: I'm wondering about the mechanics of that
17:02:39 <walters> well supporting switching selinux disabled to enabled is going to mess with a lot of ostree parts
17:02:40 <travier> and we don't support that as / is marked immutable
17:03:14 <dustymabe> i.e. if i have a karg set to enforning=0 and then set it to enforcing=1 - how does /.autorelabel get created ?
17:03:22 <lucab_> we may start passing '-T 0' in a few initramfs places to 'restorecon', I checked the patch and the default is 1
17:03:26 <travier> it does not get created
17:03:28 <lucab_> *may want
17:03:42 <travier> lucab_: +1
17:04:07 <walters> enforcing=0 is different from selinux=0
17:04:16 <dustymabe> walters: good point
17:04:18 <walters> you generally don't need to relabel when going from enforcing=0 to enforcing=1
17:04:21 <dustymabe> selinux=0 to selinux=1
17:04:28 <jlebon> dustymabe: there's a systemd service that touches /.autorelabel when !selinux
17:04:29 <dustymabe> that's what I meant
17:04:52 <dustymabe> jlebon: ahh, so that file will just exist forever in case selinux gets set back to 1?
17:05:18 <lucab_> #action lucab to check if/where we want to start using 'restorecon -T 0' in our initramfs logic
17:05:18 <jlebon> i presume autorelabeling deletes it
17:05:23 <dustymabe> yep
17:05:26 <dustymabe> ok that makes sense
17:05:34 <jlebon> anyway, i think in theory we could support this as long as we make sure it only touches /etc and /var
17:05:48 <dustymabe> at the same time.. we theoretically have a service that should fail if selinux is disabled (because it can't write to /.autorelabel
17:05:54 <jlebon> but i wouldn't be surprised today if it'd barf on the readonly bits
17:05:57 <travier> but the service won't be able to create it
17:06:19 <jlebon> dustymabe: we don't support selinux disabled :)
17:06:31 <dustymabe> but we do support it permissive?
17:06:40 <jlebon> we do, but it's not created in that case
17:06:47 <jlebon> IIUC
17:06:59 <travier> do we really support permissive? I'd ay we don't
17:07:02 <travier> say*
17:07:25 <dustymabe> hmm
17:07:29 <jlebon> it's useful to debug things and shouldn't really break anything. whereas selinux=0 has a high likelihood of breaking things
17:07:32 <lucab_> depends on the definition of "support" :)
17:07:56 <dustymabe> yeah I mean if a user is having a ton of trouble with their 'bespoke' application and selinux is getting in the way i'm not going to debug it all for them
17:07:57 <lucab_> I wouldn't expect things to break, and I wouldn't expect prod nodes to really run that way
17:07:59 <travier> for debug, definitely. for general support I don't think s
17:08:01 <travier> so
17:08:02 <jlebon> for reference, the service is: https://src.fedoraproject.org/rpms/policycoreutils/blob/rawhide/f/selinux-autorelabel-mark.service
17:08:14 <dustymabe> i'm just going to say well you can debug it this way or you could just set selinux to permissive
17:08:41 <travier> In general it's better to run with selinux=0 than permissive, as permissive can break things in really weird ways
17:08:59 <jlebon> travier: did you mean the opposite?
17:09:02 <lucab_> I think this selinux rabbit hole could be very long, let's maybe cut it here?
17:09:15 <dustymabe> jlebon: yeah, my understanding is the opposite
17:09:20 <dustymabe> lucab_: that's fair :)
17:09:21 <travier> no, permissive is really complex and it creates weird issues
17:09:33 <travier> selinux=0 simply disables all selinux
17:09:52 <travier> if you don't want selinux, it's the way, not permissive
17:10:05 <lucab_> I'll move to the last ticket
17:10:15 <walters> I do think we should break off "ostree/fcos and selinux" to a distinct discussion that should probably be resolved with a PR to the docs
17:10:17 <lucab_> #topic Fedora process change: Require review for all new SetUID/SetGID introduced into editions default installations
17:10:27 <dustymabe> walters: +1
17:11:06 <lucab_> #undo
17:11:06 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fe2d6afce10>
17:11:49 <lucab_> #action travier to split off selinux and ostree/fcos concerns to a new ticket/PR, mainly for docs purposes
17:11:59 <jlebon> travier: ack gotcha. as a stable configuration on traditional systems, agreed
17:12:01 <travier> Independently of wether or not we support selinux, this change should be ok for us
17:12:10 <travier> jlebon: yes
17:12:22 <travier> for debug of course you can use anything you need
17:12:48 <lucab_> travier: hope you don't mind voicing all of that into a GH ticket
17:12:55 <travier> do we really need an action? is anyone asking that we support non selinux?
17:13:14 <dustymabe> i think it would be useful to discuss and clarify our position
17:13:28 <travier> ok
17:13:33 <dustymabe> because obviously we aren't all on the same page - so how could our users be?
17:13:40 <lucab_> I don't think so. At the same time I'm starting to feel that I don't really understand the implications of 'permissive'
17:14:14 <travier> ok i'll make a ticket to make things clearer
17:14:15 <lucab_> at least braindump/brainsync would be useful
17:14:30 <lucab_> really moving now
17:14:33 <lucab_> #topic Fedora process change: Require review for all new SetUID/SetGID introduced into editions default installations
17:14:42 <lucab_> #link https://github.com/coreos/fedora-coreos-tracker/issues/1270
17:14:44 <jlebon> dustymabe: hmm, i think we mostly are.  but would be good to discuss anyway whether we should neuter the autorelabel stuff more strongly
17:14:53 <travier> This issue was triggered by a discussion around a new SetGID binary that was added transitively by a new package on s390x
17:15:02 <dustymabe> travier++
17:15:31 <lucab_> #link https://github.com/coreos/fedora-coreos-tracker/issues/1253
17:16:05 <lucab_> that's the ticket where we spot the new setgid binary
17:16:19 <travier> The general idea is that we don't want binaries with special privileges to sneak in without a review.
17:16:53 <travier> So the plan is to work in Fedora to make sure we have a process to discuss that or find one that already exists and revive it
17:17:11 <dustymabe> yes.
17:17:17 <travier> I vaguely remember that there are checks in CI in Fedora somwhere but they are not blocking AFAIK
17:17:46 <dustymabe> the goal here is to make FCOS passively inherit the components from Fedora
17:17:48 <jlebon> this could also be part of "run FCOS tests in Fedora CI" as a way to enforce this
17:18:12 <dustymabe> jlebon: yes, I'm worried less about the enforcement part.. I want to make sure we have the policy established higher up
17:18:24 <jlebon> yup, indeed
17:18:25 <travier> My position is that it's better for us to slightly diverge from Fedora until this is fixed than to ship potential security issue in the system
17:19:00 <travier> but for that to work we need a process in Fedora
17:19:15 <travier> to make sure we do not diverge for too long
17:20:00 <lucab_> it's a bit of a fuzzy process though
17:20:15 <lucab_> even this specific binary, it really depends on the context
17:20:23 <jlebon> concretely, i think this would be a packaging guidelines change?
17:20:39 <dustymabe> jlebon: I don't even know if it's a packaging guidelines change
17:20:41 <jlebon> or is there a "Fedora process change"?
17:20:49 <dustymabe> I think, as lucab suggested, it's more on the context
17:20:58 <lucab_> in our context it doesn't make sense, but in different mail-related context it may be useful
17:20:59 <dustymabe> so for example, I could see it being focused to the deliverable
17:21:30 <dustymabe> i.e. Fedora Server ships with XYZ approved setgid/setuid binaries
17:21:38 <jlebon> the guidelines could be that one can opt out of it by requiring more subpackaging
17:21:53 <lucab_> doing some Fedora-wide sysusers work, I realized there are quite a few setgid binary
17:22:26 <dustymabe> lucab_: so the goal may be hard to achieve?
17:22:41 <lucab_> maybe a better guideline could be, make sure they are weak opt-in into their own subpackage
17:22:59 <jlebon> maybe better to start a devel thread on this and see what the best way forward is there
17:23:33 <dustymabe> I think my position is.. I don't care what we end up doing as long as the same restrictions apply to say Fedora Server (or RHEL)
17:23:37 <lucab_> dustymabe: it's a small but non-empty set, at least with the current dependencies
17:23:53 <dustymabe> we can't police packages and rip things out of them - it's not sustainable over time
17:24:34 <dustymabe> if say RHEL server or Fedora Server can ship with that setgid binary, then we should be able to too
17:24:51 <travier> The goal is not t remove existing binaries that we already have but to make sure that new ones are trully needed
17:25:07 <dustymabe> travier: I understand that, the same argument applies
17:25:07 <lucab_> dustymabe: agreed, just this case smelled bad as I saw an unexpected 'mail' group
17:25:12 <travier> This will apply to server & RHEL too
17:25:53 <travier> I don't think server admins want set* binaries sneaked into their default installs either
17:26:10 <travier> It's just that we test for it actively so we're the first one to see it now
17:26:25 <jlebon> dustymabe: are you saying the risk assessment should be the same regardless of the variant/distro?
17:26:28 <dustymabe> +1 - and if we can get the rest of Fedora to adopt a policy here then we all improve
17:26:35 <travier> +1
17:26:56 <dustymabe> jlebon: I'd have to unpack your question a bit
17:27:26 <lucab_> my main friction in this case is, we detected it but we don't have an easy clean way to avoid the binary, even if we know it's of no use for us
17:27:42 <dustymabe> it's mostly mapping deliverable (edition) to package set and then having an allowlist of setuid/setgid binaries
17:28:03 <dustymabe> if a package in the package set adds a new binary it would need to get evaluated and approved or reworked to be removed
17:28:10 <bgilbert> lucab_: postprocess script?
17:28:46 <lucab_> bgilbert: yeah sorry, I mean without hacking around Fedora packages
17:28:49 <dustymabe> bgilbert: right, we have a PR for that. what we're trying to do is not modify every package under the sun, but kick these policies back to the higher level
17:28:56 <bgilbert> +1
17:28:57 <jlebon> dustymabe: right, but is "evaluated and approved" done for all editions as one?
17:29:24 <dustymabe> jlebon: I don't know yet.. this is just a proposal/idea.
17:29:38 <lucab_> (we are close to end time)
17:29:58 <jlebon> ok, just saying different editions have different use cases, and i can imagine wanting different tradeoffs for each
17:30:07 <dustymabe> I'd propose there might be things Fedora Workstation is OK with that Fedora Server isn't, however if there is a package common to both then that package would need to comply with the most strict requiring deliverable
17:30:23 <dustymabe> or split out into a subpackage
17:30:59 <lucab_> trying to getting to a point, do we prefer to a) wait a bit more on GH, b) touch again on this next week, c) move to fedora-devel@ and see how it goes there?
17:31:17 <lucab_> s/wait/write/
17:31:35 <dustymabe> I don't have a strong opinion
17:31:41 <jlebon> dustymabe: right, agreed
17:32:16 <lucab_> travier: where you planning to bring this up higher Fedora-wide quickly?
17:32:19 <lucab_> *were
17:32:21 <jlebon> i think this would be useful on devel, but would help to clarify a bit the proposal first
17:32:38 <dustymabe> agree
17:33:03 <travier> I don't have a timeline
17:33:22 <travier> there are a bunch of other changes I need draft
17:33:28 <travier> policy changes
17:33:34 <lucab_> let's keep going on GH for now then, I'd say
17:33:41 <travier> we can start a discussion on devel
17:33:48 <travier> draft a mail for devel
17:34:14 <lucab_> as you wish, but we are not in a hurry on this, let's not overload
17:34:40 <bgilbert> +1
17:35:12 <travier> then the question is what do we do in the meantime? ship the binary?
17:35:43 <jlebon> is it needed for the functionality of the package in FCOS?
17:36:14 <dustymabe> no it's not
17:36:17 <travier> not as far as we've investigated
17:36:23 <jlebon> then, let's nuke it for now
17:36:34 <dustymabe> travier: how about we see what the BZ yields and then we can delete it
17:36:41 <dustymabe> https://bugzilla.redhat.com/show_bug.cgi?id=2112857
17:36:48 <travier> https://github.com/coreos/fedora-coreos-config/pull/1887
17:36:51 * dustymabe notes that this is only in `rawhide` right now
17:36:53 <lucab_> it's rawhide-s390x only too, I wouldn't stress too much
17:37:19 <travier> Sure, but the test is for testing-devel
17:37:24 <travier> it's easy to forget this
17:37:34 <lucab_> dustymabe: do you want to long-snooze right now?
17:37:38 <travier> we can always revert this change
17:38:28 <dustymabe> lucab_: long snooze won't work because we modified the test.. travier i'm fine with merging if everyone has a strong preference for that
17:39:28 <dustymabe> reviewed: https://github.com/coreos/fedora-coreos-config/pull/1887#pullrequestreview-1060764987
17:39:40 <lucab_> I'd say let's merge it now then see where the BZ goes
17:39:52 <lucab_> ok, super
17:39:57 <lucab_> #topic Open Floor
17:40:19 <lucab_> we are already overtime, so closing this in a short bit
17:40:21 <dustymabe> #info saqali and ravanelli have a talk at Flock/Nest on Friday
17:40:28 <lucab_> \o/
17:40:47 <travier> 🎉
17:41:21 <lucab_> ok, closing, thanks all!
17:41:24 <lucab_> #endmeeting