16:31:38 <spresti> #startmeeting fedora_coreos_meeting
16:31:39 <zodbot> Meeting started Wed Jun  7 16:31:38 2023 UTC.
16:31:39 <zodbot> This meeting is logged and archived in a public location.
16:31:39 <zodbot> The chair is spresti. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:31:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:31:39 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:31:42 <aaradhak> .hello
16:31:42 <zodbot> aaradhak: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
16:31:51 <travier> #topic roll call
16:31:51 <fifofonix[m]> .hello fifofonix
16:31:52 <zodbot> fifofonix[m]: fifofonix 'Fifo Phonics' <fifofonix@gmail.com>
16:31:53 <dustymabe> .hi
16:31:53 <gursewak> .hi
16:31:53 <spresti> #topic roll call
16:31:54 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:57 <zodbot> gursewak: gursewak 'Gursewak Singh' <gurssing@redhat.com>
16:32:00 <dustymabe> .hi
16:32:01 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:32:05 <travier> .hello siosm
16:32:06 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:32:12 <hughsie_> hi all
16:32:16 <travier> #chair siosm spresti dustymabe
16:32:18 <spresti> ##chair dustymabe
16:32:20 <spresti> #chair dustymabe
16:32:20 <zodbot> Current chairs: dustymabe spresti
16:32:28 <spresti> #chair gursewak
16:32:28 <zodbot> Current chairs: dustymabe gursewak spresti
16:32:35 <yuval> hi
16:32:36 <aaradhak[m]> .hi
16:32:37 <zodbot> aaradhak[m]: Sorry, but user 'aaradhak [m]' does not exist
16:32:38 <spresti> #chair travier
16:32:38 <zodbot> Current chairs: dustymabe gursewak spresti travier
16:32:44 <travier> 👍
16:32:54 <spresti> #chair hughsie
16:32:54 <zodbot> Current chairs: dustymabe gursewak hughsie spresti travier
16:32:56 <travier> #chair fifofonix[m] JasonBrooks[m]
16:32:56 <zodbot> Current chairs: JasonBrooks[m] dustymabe fifofonix[m] gursewak hughsie spresti travier
16:33:03 <apiaseck> .hi c4rt0
16:33:04 <zodbot> apiaseck: Sorry, but user 'apiaseck' does not exist
16:33:11 <apiaseck> .hello c4rt0
16:33:12 <zodbot> apiaseck: c4rt0 'Adam Piasecki' <c4rt0gr4ph3r@gmail.com>
16:33:17 <aaradhak[m]> .hi aaradhak
16:33:18 <zodbot> aaradhak[m]: Sorry, but user 'aaradhak [m]' does not exist
16:33:25 <yuval> .hello yuvalk
16:33:26 <zodbot> yuval: Sorry, but user 'yuvalk' does not exist
16:33:27 <spresti> #chair apiaseck
16:33:27 <zodbot> Current chairs: JasonBrooks[m] apiaseck dustymabe fifofonix[m] gursewak hughsie spresti travier
16:33:31 <yuval> .hello yuval
16:33:32 <zodbot> yuval: yuval 'yuval goel' <goelyuval@gmail.com>
16:33:37 <travier> #chair yuval
16:33:37 <zodbot> Current chairs: JasonBrooks[m] apiaseck dustymabe fifofonix[m] gursewak hughsie spresti travier yuval
16:33:50 <pjones> .hello pjones
16:33:53 <zodbot> pjones: pjones 'Peter Jones' <pjones@redhat.com>
16:33:54 <travier> #chair aaradhak[m]
16:33:54 <zodbot> Current chairs: JasonBrooks[m] aaradhak[m] apiaseck dustymabe fifofonix[m] gursewak hughsie spresti travier yuval
16:33:59 <marmijo[m]> .hello marmijo
16:34:00 <travier> #chair pjones
16:34:00 <zodbot> Current chairs: JasonBrooks[m] aaradhak[m] apiaseck dustymabe fifofonix[m] gursewak hughsie pjones spresti travier yuval
16:34:00 <zodbot> marmijo[m]: marmijo 'Michael Armijo' <marmijo@redhat.com>
16:34:05 <travier> #chair marmijo[m]
16:34:05 <zodbot> Current chairs: JasonBrooks[m] aaradhak[m] apiaseck dustymabe fifofonix[m] gursewak hughsie marmijo[m] pjones spresti travier yuval
16:34:28 <jforbes> .hell2
16:34:31 <jforbes> .hello2
16:34:32 <zodbot> jforbes: jforbes 'Justin Forbes' <jforbes@redhat.com>
16:34:45 <jforbes> either works I suppose
16:34:48 <spresti1> Sorry  lost power
16:34:53 <travier> We have 2 important tickets with guests folks today: https://github.com/coreos/fedora-coreos-tracker/issues/1504 & https://github.com/coreos/fedora-coreos-tracker/issues/1478
16:35:15 <spresti1> #info there were no action items from last meeting!
16:35:16 <bgilbert> .hi
16:35:17 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:35:25 <travier> #chair bgilbert spresti1
16:35:25 <zodbot> Current chairs: JasonBrooks[m] aaradhak[m] apiaseck bgilbert dustymabe fifofonix[m] gursewak hughsie marmijo[m] pjones spresti spresti1 travier yuval
16:35:32 <travier> #info there were no action items from last meeting!
16:35:43 <spresti1> #topic tracker: Regular updates for the UEFI revoked signatures database (dbx)
16:35:57 <spresti1> #link https://github.com/coreos/fedora-coreos-tracker/issues/1478
16:36:16 <spresti1> discuss
16:36:34 <dustymabe> 👋
16:36:47 <dustymabe> we have some special guests here with us today
16:36:55 <hughsie_> so i guess my opening remark would be that the "do nothing" option is getting worse with each exploit that comes up
16:37:01 <dustymabe> jforbes pjones hughsie_ - welcome
16:37:52 <travier> which means that this put emphasis on having reliable bootloader updates to enable dbx updates
16:37:57 <hughsie_> and my other remark is that some bios vendors update the dbx as part of "firmware BIOS updates" even if we tell them it's a dumb idea
16:38:01 <jforbes> hughsie_: I definitely agree with that. and things like gnome software nag pretty frequently for dbx updates which gets people to actually do it
16:38:26 <hughsie_> so if we don't update shim then it's going to be update bios -> locked out
16:38:34 <bgilbert> hughsie_: ooh yeah, we hadn't factored in the BIOS update part
16:38:49 <hughsie_> as we only do the "check the esp for blocked content" dance for an explicit dbx update
16:39:42 <travier> fwupd does do BIOS updates right? so that's a "manual" update for BIOS
16:39:44 <travier> ?
16:39:49 <travier> does not*
16:39:52 <hughsie_> so i think we have to assume that the dbx is going to be updated, either by the bios vendor (even as a motherboard replacement!) or by the user using fwupd
16:40:03 <hughsie_> travier, yup, it's done millions of them :)
16:40:13 <dustymabe> fwupd++
16:40:36 <travier> hold on, I though fwup was EFI only
16:40:38 <jforbes> Some systems require fwupd, it seems gigabyte has been shipping auto updateing boards for a while (with no security)
16:41:01 <jforbes> travier: as opposed to?
16:41:05 <pjones> travier: we're only talking about UEFI, just lots of people use "BIOS" generically
16:41:05 <hughsie_> travier, ohh i see what you mean; yes, mostly UEFI only -- but vendors still call it a BIOS to distinguish them from CSME/EC/etc
16:41:27 <pjones> that terminolody is a fight that we have already squarely lost
16:41:30 <travier> ah ok, confusing terminology
16:41:39 <jforbes> no one is shipping bios anymore
16:41:45 <hughsie_> right, if you're dual booting with windows then that's just going to update the dbx without asking; then we SOL
16:41:55 <bgilbert> hughsie_: no dual booting with FCOS.  we don't support it
16:42:02 <hughsie_> that makes it simpler then
16:42:21 <jforbes> bgilbert: support vs practice are 2 different things in Fedora, always have been.
16:42:29 <pjones> but still, at some point there are going to be firmware updates to fix critical issues and they're going to do it for us without meaningful coordination
16:42:32 <hughsie_> but i think "should we update shim" has to be a 100% yes now
16:42:32 <bgilbert> jforbes: I have literally not heard of anyone doing it
16:42:37 <bgilbert> I'd be surprised if it works
16:42:50 <dustymabe> jforbes: yeah, but in this case they can't even install (coreos-installer is essentiall a dd)
16:42:58 <jforbes> bgilbert: it would take me 3 minutes to set it up with a different bootloader
16:43:12 <quentin9696[m]> .hi
16:43:13 <bgilbert> jforbes: after install, sure.  but there's no guarantee we won't break you later
16:43:13 <zodbot> quentin9696[m]: Sorry, but user 'quentin9696 [m]' does not exist
16:43:23 <pjones> jforbes: but you'd have to boot a rescue image the first time to get there
16:43:24 <bgilbert> and in any event, we're within our rights to say "you broke it, you get to keep both pieces" in that case
16:43:27 <travier> ok, so this makes it more important to have reliable bootloader updates
16:43:28 <jforbes> the clover stuff would work
16:43:48 <pjones> jforbes: so it's a pretty safe bet that a) not a lot of people are doing it, and b) the FCOS team isn't supporting them if they are ;)
16:44:12 <dustymabe> #chair HristoMarinov[m] Guidon
16:44:12 <zodbot> Current chairs: Guidon HristoMarinov[m] JasonBrooks[m] aaradhak[m] apiaseck bgilbert dustymabe fifofonix[m] gursewak hughsie marmijo[m] pjones spresti spresti1 travier yuval
16:44:12 <travier> yes, let's leave the dual boot case as unsupported
16:44:17 <dustymabe> #chair quentin9696[m]
16:44:17 <zodbot> Current chairs: Guidon HristoMarinov[m] JasonBrooks[m] aaradhak[m] apiaseck bgilbert dustymabe fifofonix[m] gursewak hughsie marmijo[m] pjones quentin9696[m] spresti spresti1 travier yuval
16:44:43 <jforbes> Right, though from a chasing a bug scenario, it is less obvious compared to say tainting drivers...  People don't always mention that they dual boot
16:44:51 <dustymabe> travier: I think we had already decided that auto bootloader updates was something we wanted to do.. the open question was if we also wanted to auto update the dbx
16:45:00 <hughsie_> i guess an important thing to note is that fwupdmgr update is always "safe" i.e. it'll check the ESP(s) for anything in the dbx before actually updating it
16:45:24 <travier> dustymabe: 👍
16:45:26 <dustymabe> hughsie_++
16:45:50 <hughsie_> but the question remains about what to do on failure
16:46:09 <hughsie_> if the user is running an old shim, and you try the dbx it'll fail; if you retry 60 seconds later it'll still fail
16:46:14 <travier> hughsie_: Can we single out dbx updates when calling fwupd?
16:46:19 <hughsie_> yup
16:46:27 <jforbes> I certainly feel that bootloader update should happen.   I wouldn't necessarily agree on dbx, but if dual boot is explicitly not supported, I suppose that is fine
16:46:33 <bgilbert> hughsie_: I assume it'd need to be: auto update bootloader, reboot, auto update dbx
16:46:43 <hughsie_> i don't think you need to reboot
16:46:48 <bgilbert> ah, cool
16:47:03 <hughsie_> fwupdmgr update GUID or fwupdmgr update DEVICE_ID works fine for this
16:47:09 <bgilbert> if a system deadends itself, unfortunately the best we can do is to put a message in the MOTD.  we don't have any clear notification API that reaches outside the machine
16:47:18 <bgilbert> we already have that problem with OS update failures
16:47:27 <hughsie_> right, it s the same kind of thing
16:47:31 <travier> hughsie_: how do we figure out the GUID/DEVICE_ID?
16:47:33 <travier> is it per system?
16:47:40 <hughsie_> if it helps, fwupd adds stuff to the MOTD when there are critical updates pending to
16:47:41 <hughsie_> to
16:47:43 <hughsie_> tooo
16:47:54 <dustymabe> oh.. nice
16:47:57 <dustymabe> hadn't seen that before
16:48:10 <hughsie_> "fwupdmgr get-devices" -> look for the dbx
16:48:11 <dustymabe> hmm. I wonder if there is a service that has to be enabled for that to work
16:48:12 <hughsie_> e.g.
16:48:19 <jforbes> yes, rather handy, that is when I learn that there is an update for my xps
16:48:28 <hughsie_> │ └─UEFI dbx:
16:48:28 <hughsie_> │       Device ID:        362301da643102b9f38477387e2193e57abaa590
16:48:28 <hughsie_> │       Summary:          UEFI revocation database
16:48:28 <hughsie_> │       Current version:  371
16:48:28 <hughsie_> │       Minimum Version:  371
16:48:29 <hughsie_> │       Vendor:           UEFI:Linux Foundation
16:48:31 <hughsie_> │       Install Duration: 1 second
16:48:33 <hughsie_> │       GUIDs:            14503b3d-73ce-5d06-8137-77c68972a341 ← UEFI\CRT_A9087D1044AD18F7A94916D284CBC01827CF23CD8F60B79072C9CAA1FEF4D649
16:48:36 <hughsie_> │                         5971a208-da00-5fce-b5f5-1234342f9cf7 ← UEFI\CRT_A9087D1044AD18F7A94916D284CBC01827CF23CD8F60B79072C9CAA1FEF4D649&ARCH_X64
16:48:38 <bgilbert> assuming bootloader updates happen, are there any other concerns about dbx autoupdate, other than the possibility of failure?
16:48:41 <hughsie_> │                         c6682ade-b5ec-57c4-b687-676351208742 ← UEFI\CRT_A1117F516A32CEFCBA3F2D1ACE10A87972FD6BBE8FE0D0B996E09E65D802A503
16:48:44 <hughsie_> │                         f8ba2887-9411-5c36-9cee-88995bb39731 ← UEFI\CRT_A1117F516A32CEFCBA3F2D1ACE10A87972FD6BBE8FE0D0B996E09E65D802A503&ARCH_X64
16:48:47 <hughsie_> and I think the device ID is stable too
16:48:51 <hughsie_> that's actually a good question
16:48:55 <pjones> hughsie_: dbx updates aren't guaranteed to be reflected in GetVariable() before a reboot
16:48:58 <bgilbert> in the failure case, I'm honestly not 100% sad if the machine stops booting.  it'll get attention
16:49:14 <travier> There is json output so we can query that
16:49:16 <bgilbert> we wouldn't do that intentionally, but if that's the eventual consequence...
16:49:18 <hughsie_> the dbx update adds keys essentially to NVRAM
16:49:24 <hughsie_> so if you have 10KB spare space
16:49:31 <hughsie_> and there's a 20KB addition
16:49:35 <bgilbert> right
16:49:36 <hughsie_> you'd hope it fails
16:49:52 <hughsie_> some HP machines have not enough space left
16:50:00 <hughsie_> on the LVFS we get the failure reports
16:50:16 <hughsie_> also the biggest vendor with failures is "To Be Set By the O.E.M."
16:50:22 <bgilbert> haah
16:50:33 <hughsie_> where it's some $40 motherboard with some UEFI firmware from 2011
16:50:42 <travier> So we would need to enable fwupd-refresh.timer to get the MOTD?
16:50:47 <hughsie_> yup
16:50:55 <dustymabe> travier: I wonder if we should just do that anyway?
16:51:04 <dustymabe> should that be in the fedora presets (not just FCOS)?
16:51:11 <hughsie_> i said yup too early, that should have been "i think so"
16:51:18 <travier> GNOME Software & Discover manage that on desktops
16:51:30 <travier> better UX
16:51:45 <dustymabe> travier: so maybe for server specific variants then
16:51:46 <travier> graphical UX I should say
16:51:48 <travier> yes
16:51:51 <travier> agree
16:52:00 <travier> iot, server, coreos
16:52:18 <travier> that would be a ffedora change :)
16:52:21 <dustymabe> so there is one action item at least
16:52:47 <spresti1> So I am a bit out of my depth, can some one kick off the first prepose?
16:52:54 <hughsie_> what's the plan for updating shim now?
16:53:03 <hughsie_> the bootupd thing?
16:53:14 <dustymabe> spresti1: I think we can do this for the first small bit
16:53:17 <bgilbert> the bootupd thing, yeah
16:53:19 <travier> #proposed #action travier write a ticket to submit a fedora change to enable fwupd-refresh.timer by default on IoT, CoreOS & Server editions
16:53:30 <dustymabe> +1
16:54:09 <travier> spresti1: I don't understand your question
16:54:16 <jforbes> Rather surprised that it isn't already
16:54:30 <travier> ah, you meant propose?
16:54:35 <bgilbert> +1 to proposed, though self-actions don't require a vote afaik
16:54:35 <spresti1> travier you got it.  and yeah lol
16:54:42 <travier> 👍
16:54:53 <spresti1> +1 to proposed
16:55:05 <bgilbert> so it seems like where we are is: general consensus on dbx updates, but we're blocked on getting bootupd over the line
16:55:19 <travier> well, it would enable it for CoreOS so the vote is about that
16:55:27 <travier> bgilbert: +1
16:55:39 <hughsie_> just a question: is bootupd the only way you could do this?
16:55:54 <dustymabe> #action travier write a ticket to submit a fedora change to enable fwupd-refresh.timer by default on IoT, CoreOS & Server editions
16:55:57 <travier> pjones: hughsie_ any interest in unifying the bootloader update stack on a single sofware?
16:56:15 <hughsie_> i mean, fwupd can mount and copy stuff to the ESP
16:56:16 <pjones> I'm not sure exactly what the part of this bootupd is actually solving is
16:56:19 <travier> we can not do it via RPMs postprocess scripts
16:56:23 <bgilbert> hughsie_: we could replace bootupd with something else, but we need basically the same features in any event
16:56:39 <hughsie_> what is bootupd actually required to do for shim updates?
16:56:45 <pjones> I think we do need to build actual A/B updating into shim's packaging, but last I looked at bootupd it didn't actually do that.
16:56:55 <bgilbert> pjones: it doesn't.  that's part of what's missing
16:57:06 <pjones> but isn't that the whole thing it was supposed to solve?
16:57:07 <hughsie_> you mean a new BootXXXX target for the B?
16:57:20 <pjones> hughsie_: and a startup check to swap the order, yeah
16:57:36 <bgilbert> pjones: it also syncs the state of the ESP with the ostree.  we don't get that for free
16:57:45 <travier> It's doing properly the "copy the new version the old one" instead of it being a prone to error bash script
16:58:10 <hughsie_> don't take this the wrong way; that doesn't sound super tricky
16:58:20 <travier> it's a very small program
16:58:39 <bgilbert> well, it's a medium-small program.  it has a lot of Architecture (TM)
16:58:47 <hughsie_> why does it need to be a daemon?
16:58:49 <dustymabe> I think anyone would be happy to have something other than bootupd own this piece.
16:58:57 <travier> yes, it has ostree integration which makes it larger
16:59:06 <dustymabe> I don't think it is a daemon
16:59:15 <bgilbert> it has a daemon component, I think dbus-activated
16:59:20 <travier> hughsie_: was happens if you Ctrl+C a command mid way?
16:59:26 <travier> it's trying to avoid that issue
16:59:37 <hughsie_> it's FAT32 tho
16:59:45 <travier> just like dnf has a daemon
16:59:47 <hughsie_> you don't get much atomic promises on that
16:59:56 <bgilbert> I'm personally not going to argue that its architecture is optimal
17:00:13 <dustymabe> https://github.com/coreos/bootupd/issues/454
17:00:16 <bgilbert> it has the benefit of existing, though.  if someone wants to propose an alternative, I think that could be up for discussion
17:00:19 <dustymabe> Since Linux v6.0 the vfat filesystem has support for renameat2(..., RENAME_EXCHANGE):
17:00:28 <travier> you want the update to go through even if terminal dies for whatever reason
17:00:29 <pjones> so the thing to do here is making the boot order update the atomic part, making it so we never have to change boot entries and there are two shims on the filesystem at all times, so that doesn't need to be atomic.
17:00:50 <travier> pjones: +1
17:00:50 <dustymabe> pjones: +1
17:01:04 <hughsie_> right; it seems just using Boot0001 and 0002 gets a lot of what you and for free
17:01:08 <travier> Note: We're at the halfway mark and we have another discussion
17:01:09 <pjones> and then change by setting BootNext, rebooting, and checking in a startup .service whether it worked, and if so, update BootOrder
17:01:09 <hughsie_> *want
17:01:35 <pjones> (with the caveat that I'm not sure we can do the update on BootOrder right now, but if we can't that's just a bug)
17:01:46 <travier> https://github.com/coreos/bootupd/issues/440
17:02:23 <dustymabe> anybody want to summarize where we are in this conversation?
17:02:26 <spresti1> Alright, I think to travier's point we should move on to the next topic as we already have an agreed apon action.
17:02:42 <dustymabe> spresti1: that action was tangential
17:03:01 <bgilbert> hughsie_: re Boot0001 and Boot0002, we're in a weird place right now
17:03:18 <bgilbert> the design was to always use the Fallback Boot Behavior and never install boot entries
17:03:27 <bgilbert> but it turns out that shim did that behind our back
17:03:40 <hughsie_> *Fallback*?
17:03:56 <bgilbert> FCOS still acts as though those boot entries don't exist, and I don't think bootupd messes with them
17:03:58 <travier> the default path in the efi partition
17:04:04 <travier> bootx64.efi
17:04:11 <bgilbert> we have an open ticket to fix that but it isn't being worked on
17:04:11 <hughsie_> aha, okay
17:04:17 <travier> not the efi fallback
17:04:28 <hughsie_> being honest it sounds like you do need engineering resources :)
17:04:29 <travier> (confusing terminology again :/)
17:04:37 <bgilbert> uh, may have gotten my term wrong, it's been a minute
17:04:40 <bgilbert> https://github.com/coreos/fedora-coreos-tracker/issues/946
17:04:50 <bgilbert> hughsie_: wouldn't hurt <3
17:05:39 <dustymabe> maybe let's close out this topic in the next 5m
17:05:49 <travier> Unifying the approach on boot loader updates would be nice
17:05:58 <dustymabe> I think the answer is: "yes, we'd like to update the dbx automatically" ?
17:06:05 <travier> +1
17:06:11 <bgilbert> +1 to unifying.  and I don't think we need to unify around our existing tooling if there's a better option
17:06:18 <dustymabe> +1 to that for sure
17:06:33 <dustymabe> if there is a better option or a team more focused on that goal
17:06:41 <dustymabe> who do we talk to about that?
17:06:50 <travier> #proposed we want to enable automatic update of dbx. This is pending on bootlaoder auto update work
17:07:19 <hughsie_> well, i guess talk to jared who's the manager of the bootloader team
17:07:26 <dustymabe> travier: but is it that simple? I'm guessing we'd be using fwupd to do the dbx update?
17:07:28 <travier> #proposed We will enable automatic update of the dbx only (not all firmwares). This is pending on bootlaoder auto update work
17:07:39 <hughsie_> but if it's a request to do more things, he'll say no as we're crazy busy atm
17:07:48 <bgilbert> travier: s/bootlaoder/bootloader/
17:07:51 <travier> #proposed We will enable automatic update of the dbx only (not all firmwares). This is pending on bootloader auto update work
17:08:20 <dustymabe> travier: +1
17:08:28 <bgilbert> should we have that block on bootloader updates?  or just let it fail if sigs are old?
17:08:32 <travier> #proposed We will enable automatic update for the dbx only (not all firmwares). This is pending on being able to enable bootloader update automatically
17:08:42 <bgilbert> i.e. should we go ahead and enable it now
17:08:51 <travier> we could do that too indeed
17:09:17 <dustymabe> bgilbert: hmm. I mean that means existing systems that are out there would certainly stop booting
17:09:28 <bgilbert> dustymabe: not if we trust the fwupd safety check
17:09:36 <dustymabe> I see
17:09:45 <dustymabe> maybe ?
17:09:49 <hughsie_> if it helps, i trust the fwupd safety check
17:09:49 <travier> :)
17:09:57 <travier> 👍
17:09:59 <bgilbert> +1
17:10:06 <bgilbert> re getting help, I guess the question for our visitors is: would you rather see us keep working on bootupd, or can you spare cycles to collaborate on an alternative?
17:10:18 <bgilbert> practically speaking, I think those are the options
17:10:22 <bgilbert> (other options welcome)
17:10:45 <bgilbert> (or ofc feel free to contribute to bootupd if you'd like)
17:10:49 <travier> maybe we should remove all the ostree integration from bootupd
17:11:05 <hughsie_> fwiw, bootupd is fine for me, but it seems we've been talking about it for *years* now
17:11:08 <dustymabe> another question is how this overlaps with all the stuff systemd is doing
17:11:20 <bgilbert> hughsie_: yeah, I think it's been backburner for most of its existence
17:11:37 * dustymabe often mixes up bootctl and bootupctl
17:11:56 <hughsie_> i'm a bit confused why it's not a big deal for ostree too
17:12:07 <hughsie_> surely fedora silverblue has the same problem
17:12:13 <travier> they have
17:12:22 <travier> all rpm-ostree based variants have this issue
17:12:24 <pjones> tbh I don't think it's a lot of complex code to do proper uefi a/b booting in shim, but it's a project we don't have the resources to take on
17:12:28 <hughsie_> sooo this makes it an ostree problem in my book
17:12:49 <walters> it's a problem for all image-based update systems that handle userspace and kernel but not other things
17:12:55 <spresti1> Allright all I love the discussion, but we are running out of time. Lets try and wrap this up into an action.
17:13:10 <jforbes> I am guessing silverblue at least gets the prompts for updating already, but I am not sure on that
17:13:15 <dustymabe> +1 for the current proposed.. we can tweak it later (next meeting) if we like
17:14:07 <spresti1> +1 dusty
17:14:13 <travier> #proposed We will enable automatic update of the dbx only (not all firmwares). We will rely on fwupd check to not update the dbx when the bootloader is not yet updated
17:14:29 <spresti1> +1
17:14:31 <bgilbert> +1 for proposed, though it doesn't contain any decision on moving forward with the thing that we're actually blocked on
17:14:38 <pjones> not sure if I get a vote here, but I'd +1 it
17:14:43 <dustymabe> bgilbert: we have a separate ticket for that
17:14:47 <bgilbert> right
17:15:01 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/1468
17:15:30 <travier> anyone against enabling that even if we don't have botloader updates?
17:15:46 <dustymabe> travier: I guess it would be OK from what everyone is telling me
17:16:03 <travier> yep, just trying to clarify what -1 would look like here
17:16:18 <dustymabe> maybe we should do it with a long preview window in `next` or something
17:16:30 <bgilbert> +1 to enable, it'll do some incremental amount of good.  `next` first sounds reasonable
17:16:39 <dustymabe> could roll it in for f39 transition
17:16:47 <jforbes> there is no urgency until there is
17:16:54 <travier> ok to go agreed?
17:17:10 <spresti1> +1
17:17:11 <dustymabe> jforbes: for bootloader though, not dbx?
17:17:22 <jforbes> both really
17:17:36 <travier> #agreed We will enable automatic update of the dbx only (not all firmwares). We will rely on fwupd check to not update the dbx when the bootloader is not yet updated
17:17:48 <dustymabe> +1
17:17:52 <pjones> dustymabe: the nature of the attacks is that someone installs and old bootloader without telling you ;)
17:17:58 <pjones> *an
17:18:09 <bgilbert> jforbes hughsie_ pjones: thanks for the input, much appreciated!
17:18:09 <jforbes> meaning start the preview, and if you need to force it through quicker it is an option
17:18:12 <travier> Thanks for coming and for the lively discussion pjones hughsie_
17:18:16 <hughsie_> no probs
17:18:29 <hughsie_> nice to use IRC again after all these months
17:18:34 <travier> :)
17:18:35 <pjones> hah, indeed
17:18:37 <spresti1> Ok lets take the rest of this convo and move it to next meeting or offline.
17:18:37 <spresti1> Lets jump topics really quick.
17:18:42 <spresti1> #topic tracker: New Package Request: NetworkManager-libreswan
17:18:47 <bgilbert> :-)
17:18:52 <spresti1> #link https://github.com/coreos/fedora-coreos-tracker/issues/1504
17:18:54 <travier> alright, I'll summarize this one
17:19:07 <spresti1> Thank you travier
17:19:18 <travier> The idea is a ask to add libreswan and the corresponding NetworkManager integration to FCOS
17:20:05 <travier> This is going to be added in some form to RHCOS/OCP to enabe/simplify more ipsec deployment use cases
17:20:38 <travier> so the question is do we want this in FCOS directly
17:20:49 <spresti1> With that lovely intro from travier
17:20:50 <spresti1> discuss
17:20:57 <bgilbert> not enough to pull in Python.  any prospect of removing the dep?
17:21:01 <travier> Right now the main problem is the Python de
17:21:03 <travier> dep
17:21:06 <yuval> it will allow native, host, support for ipsec
17:21:19 <quentin9696[m]> I have a question: why do we use systemd-networkd on FCOS ?
17:21:21 <spresti1> so I dont quite understand why is python so bad?
17:21:24 <bgilbert> quentin9696[m]: we don't
17:21:31 <yuval> Python dep is btw just on 2 diagnostic commands
17:21:36 <quentin9696[m]> why don't, sorry
17:21:51 <travier> Why not Python is explained in https://github.com/coreos/fedora-coreos-tracker/blob/main/Design.md?rgh-link-date=2023-06-02T08%3A16%3A20Z#approach-towards-shipping-python
17:21:54 <bgilbert> quentin9696[m]: there was an extremely long debate about it early on
17:22:11 <dustymabe> yeah, I mean there are a bunch of other packages getting brought in too (not just the python dep)
17:22:29 <spresti1> thanks travier
17:22:31 <bgilbert> quentin9696[m]: the short version is: it doesn't support dynamic config changes, it isn't super well maintained (or at least that was true at the time), and we don't have the resources to support two
17:22:55 <dustymabe> ^^ that was an answer regarding systemd-networkd
17:22:57 <quentin9696[m]> bgilbert: alright, make sense
17:23:44 <bgilbert> yuval: could they be split into an optional subpackage?
17:24:35 <yuval> In theory? I believe so. but I'm not a libreswan maintainer and that would be up to them
17:24:38 <travier> Another question would be about why we're choosing libreswan over strongswan, or why ipsec and not another VPN protocol
17:24:50 <yuval> yeah just wanted to comment on that
17:25:05 <yuval> while StrongSwan is not an option for RHCOS ATM, it might be a better choice for fcos
17:25:17 <bgilbert> we agreed to add wireguard
17:25:31 <travier> we agreed to add the tools for wireguard
17:25:35 <bgilbert> yes
17:25:37 <travier> as wireguard was already in the kernel
17:25:54 <travier> wireguard support is core networkmanager afaik
17:25:55 <bgilbert> we agreed to add the bits needed to use wireguard
17:26:08 <bgilbert> IPsec is at least standardized
17:26:11 <yuval> you might wanna consider adding both. there are different use cases (and both are supported in kernel)
17:26:23 <yuval> (both = ipsec and wireguard)
17:26:31 <bgilbert> I'm not necessarily advocating for adding it, but I think it's defensible
17:26:56 <dustymabe> hmm. I'm not sure here
17:27:01 <quentin9696[m]> yuval: wireguard is integrated to the kernel
17:27:18 <bgilbert> I also see unbound and nss as deps.  I assume at least unbound isn't because of the python deps
17:27:22 <dustymabe> I'm feeling like this is something that people can layer (either client side or via container layering)
17:28:04 <bgilbert> it seems pretty heavyweight for something that users haven't really been asking for
17:28:16 <quentin9696[m]> since 5.6
17:29:16 <travier> #proposed we will not add libreswan support for now in FCOS given that it depends on Python. This could be revisited once the dependency is split
17:29:23 <travier> (I'll have to leave, sorry)
17:29:24 <bgilbert> at the very least, some dep decoupling would be needed
17:29:46 <travier> Thanks for joining yuval
17:29:46 <dustymabe> right. though. while the dep decoupling would be useful. I don't want to be misleading about inclusion later
17:29:55 <bgilbert> +1 dustymabe
17:30:39 <yuval> I agree that for fcos it can be achieved with layering
17:30:43 <dustymabe> I think if it was just a couple packages it might not be so bad.. but it's not right now. and then there is the strongsuan versus libreswan
17:30:55 <dustymabe> which ultimately ends up with us putting them both in in the future
17:31:08 <yuval> the use-case/request originate from OCP where it's more complicated to do in a supported way
17:32:20 <dustymabe> bgilbert: so what are your thoutghts on a proposal? Do you think it would make much difference if the dep list were trimmed?
17:32:41 <spresti1> #proposed we will not add libreswan support for now in FCOS given that it depends on Python and implies that we ill have to add strongsuan.
17:33:41 <bgilbert> #proposed We will not add Libreswan support to FCOS for now.  It pulls in several additional packages, including Python, and we'd also need to decide whether to add strongSwan.
17:34:14 <dustymabe> +1 - the proposals are almost the same thing
17:34:40 <dustymabe> we can say that we may revisit this again in the future if user demand is evident
17:34:42 <bgilbert> spresti1's proposal implies that we've concluded we'd need both
17:34:57 <dustymabe> +1 for the most recent proposal then
17:35:05 <bgilbert> #proposed We will not add Libreswan support to FCOS for now.  It pulls in several additional packages, including Python, and we'd also need to decide whether to add strongSwan.  We can revisit this in the future if demand is high.
17:35:18 <spresti1> +1
17:35:26 <quentin9696[m]> +1
17:35:28 <dustymabe> +1
17:35:44 <bgilbert> #agreed We will not add Libreswan support to FCOS for now.  It pulls in several additional packages, including Python, and we'd also need to decide whether to add strongSwan.  We can revisit this in the future if demand is high.
17:36:39 <spresti1> Awesome :) we are over time. So I think I am going to skip open discussion ?
17:37:05 <dustymabe> anyone with an open discussion topic speak now or forever...
17:37:05 <bgilbert> we usually open it for a minute or two anyway
17:37:14 <spresti1> #topic Open Floor
17:37:35 <yuval> would it make any difference if the request was for StrongSwan (only)
17:37:39 <yuval> assuming no deps issues there
17:37:54 <bgilbert> yuval: if the deps are cleaner, it might make a difference, yeah
17:38:01 <yuval> just asking out of curiousity, as I believe in the fcos case, StrongSwan is probably a better option
17:38:18 <yuval> (which btw, wont solve my issue, but that's a different story :-) )
17:38:19 <fifofonix[m]> dustymabe: were you going to publish the slides for the fedora talk we gave last week? (someone on community channel wanted them)
17:38:51 <dustymabe> fifofonix[m]: yeah. let me talk to jwf to see if there was a place the recordings and slides were going to be posted
17:39:15 <fifofonix[m]> dustymabe: +1
17:39:43 <HristoMarinov[m]> dustymabe: +1
17:40:36 <spresti1> Ok, well since the conversations are coming to an end. I am going to end the meeting unless there are any last convos?
17:40:44 <bgilbert> +1
17:41:04 <fifofonix[m]> spresti: thanks for running things
17:41:04 <spresti1> #endmeeting