16:31:38 #startmeeting fedora_coreos_meeting 16:31:39 Meeting started Wed Jun 7 16:31:38 2023 UTC. 16:31:39 This meeting is logged and archived in a public location. 16:31:39 The chair is spresti. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 16:31:39 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:31:39 The meeting name has been set to 'fedora_coreos_meeting' 16:31:42 .hello 16:31:42 aaradhak: (hello ) -- Alias for "hellomynameis $1". 16:31:51 #topic roll call 16:31:51 .hello fifofonix 16:31:52 fifofonix[m]: fifofonix 'Fifo Phonics' 16:31:53 .hi 16:31:53 .hi 16:31:53 #topic roll call 16:31:54 dustymabe: dustymabe 'Dusty Mabe' 16:31:57 gursewak: gursewak 'Gursewak Singh' 16:32:00 .hi 16:32:01 dustymabe: dustymabe 'Dusty Mabe' 16:32:05 .hello siosm 16:32:06 travier: siosm 'Timothée Ravier' 16:32:12 hi all 16:32:16 #chair siosm spresti dustymabe 16:32:18 ##chair dustymabe 16:32:20 #chair dustymabe 16:32:20 Current chairs: dustymabe spresti 16:32:28 #chair gursewak 16:32:28 Current chairs: dustymabe gursewak spresti 16:32:35 hi 16:32:36 .hi 16:32:37 aaradhak[m]: Sorry, but user 'aaradhak [m]' does not exist 16:32:38 #chair travier 16:32:38 Current chairs: dustymabe gursewak spresti travier 16:32:44 👍 16:32:54 #chair hughsie 16:32:54 Current chairs: dustymabe gursewak hughsie spresti travier 16:32:56 #chair fifofonix[m] JasonBrooks[m] 16:32:56 Current chairs: JasonBrooks[m] dustymabe fifofonix[m] gursewak hughsie spresti travier 16:33:03 .hi c4rt0 16:33:04 apiaseck: Sorry, but user 'apiaseck' does not exist 16:33:11 .hello c4rt0 16:33:12 apiaseck: c4rt0 'Adam Piasecki' 16:33:17 .hi aaradhak 16:33:18 aaradhak[m]: Sorry, but user 'aaradhak [m]' does not exist 16:33:25 .hello yuvalk 16:33:26 yuval: Sorry, but user 'yuvalk' does not exist 16:33:27 #chair apiaseck 16:33:27 Current chairs: JasonBrooks[m] apiaseck dustymabe fifofonix[m] gursewak hughsie spresti travier 16:33:31 .hello yuval 16:33:32 yuval: yuval 'yuval goel' 16:33:37 #chair yuval 16:33:37 Current chairs: JasonBrooks[m] apiaseck dustymabe fifofonix[m] gursewak hughsie spresti travier yuval 16:33:50 .hello pjones 16:33:53 pjones: pjones 'Peter Jones' 16:33:54 #chair aaradhak[m] 16:33:54 Current chairs: JasonBrooks[m] aaradhak[m] apiaseck dustymabe fifofonix[m] gursewak hughsie spresti travier yuval 16:33:59 .hello marmijo 16:34:00 #chair pjones 16:34:00 Current chairs: JasonBrooks[m] aaradhak[m] apiaseck dustymabe fifofonix[m] gursewak hughsie pjones spresti travier yuval 16:34:00 marmijo[m]: marmijo 'Michael Armijo' 16:34:05 #chair marmijo[m] 16:34:05 Current chairs: JasonBrooks[m] aaradhak[m] apiaseck dustymabe fifofonix[m] gursewak hughsie marmijo[m] pjones spresti travier yuval 16:34:28 .hell2 16:34:31 .hello2 16:34:32 jforbes: jforbes 'Justin Forbes' 16:34:45 either works I suppose 16:34:48 Sorry lost power 16:34:53 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 #info there were no action items from last meeting! 16:35:16 .hi 16:35:17 bgilbert: bgilbert 'Benjamin Gilbert' 16:35:25 #chair bgilbert spresti1 16:35:25 Current chairs: JasonBrooks[m] aaradhak[m] apiaseck bgilbert dustymabe fifofonix[m] gursewak hughsie marmijo[m] pjones spresti spresti1 travier yuval 16:35:32 #info there were no action items from last meeting! 16:35:43 #topic tracker: Regular updates for the UEFI revoked signatures database (dbx) 16:35:57 #link https://github.com/coreos/fedora-coreos-tracker/issues/1478 16:36:16 discuss 16:36:34 👋 16:36:47 we have some special guests here with us today 16:36:55 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 jforbes pjones hughsie_ - welcome 16:37:52 which means that this put emphasis on having reliable bootloader updates to enable dbx updates 16:37:57 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 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 so if we don't update shim then it's going to be update bios -> locked out 16:38:34 hughsie_: ooh yeah, we hadn't factored in the BIOS update part 16:38:49 as we only do the "check the esp for blocked content" dance for an explicit dbx update 16:39:42 fwupd does do BIOS updates right? so that's a "manual" update for BIOS 16:39:44 ? 16:39:49 does not* 16:39:52 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 travier, yup, it's done millions of them :) 16:40:13 fwupd++ 16:40:36 hold on, I though fwup was EFI only 16:40:38 Some systems require fwupd, it seems gigabyte has been shipping auto updateing boards for a while (with no security) 16:41:01 travier: as opposed to? 16:41:05 travier: we're only talking about UEFI, just lots of people use "BIOS" generically 16:41:05 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 that terminolody is a fight that we have already squarely lost 16:41:30 ah ok, confusing terminology 16:41:39 no one is shipping bios anymore 16:41:45 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 hughsie_: no dual booting with FCOS. we don't support it 16:42:02 that makes it simpler then 16:42:21 bgilbert: support vs practice are 2 different things in Fedora, always have been. 16:42:29 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 but i think "should we update shim" has to be a 100% yes now 16:42:32 jforbes: I have literally not heard of anyone doing it 16:42:37 I'd be surprised if it works 16:42:50 jforbes: yeah, but in this case they can't even install (coreos-installer is essentiall a dd) 16:42:58 bgilbert: it would take me 3 minutes to set it up with a different bootloader 16:43:12 .hi 16:43:13 jforbes: after install, sure. but there's no guarantee we won't break you later 16:43:13 quentin9696[m]: Sorry, but user 'quentin9696 [m]' does not exist 16:43:23 jforbes: but you'd have to boot a rescue image the first time to get there 16:43:24 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 ok, so this makes it more important to have reliable bootloader updates 16:43:28 the clover stuff would work 16:43:48 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 #chair HristoMarinov[m] Guidon 16:44:12 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 yes, let's leave the dual boot case as unsupported 16:44:17 #chair quentin9696[m] 16:44:17 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 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 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 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 dustymabe: 👍 16:45:26 hughsie_++ 16:45:50 but the question remains about what to do on failure 16:46:09 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 hughsie_: Can we single out dbx updates when calling fwupd? 16:46:19 yup 16:46:27 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 hughsie_: I assume it'd need to be: auto update bootloader, reboot, auto update dbx 16:46:43 i don't think you need to reboot 16:46:48 ah, cool 16:47:03 fwupdmgr update GUID or fwupdmgr update DEVICE_ID works fine for this 16:47:09 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 we already have that problem with OS update failures 16:47:27 right, it s the same kind of thing 16:47:31 hughsie_: how do we figure out the GUID/DEVICE_ID? 16:47:33 is it per system? 16:47:40 if it helps, fwupd adds stuff to the MOTD when there are critical updates pending to 16:47:41 to 16:47:43 tooo 16:47:54 oh.. nice 16:47:57 hadn't seen that before 16:48:10 "fwupdmgr get-devices" -> look for the dbx 16:48:11 hmm. I wonder if there is a service that has to be enabled for that to work 16:48:12 e.g. 16:48:19 yes, rather handy, that is when I learn that there is an update for my xps 16:48:28 │ └─UEFI dbx: 16:48:28 │ Device ID: 362301da643102b9f38477387e2193e57abaa590 16:48:28 │ Summary: UEFI revocation database 16:48:28 │ Current version: 371 16:48:28 │ Minimum Version: 371 16:48:29 │ Vendor: UEFI:Linux Foundation 16:48:31 │ Install Duration: 1 second 16:48:33 │ GUIDs: 14503b3d-73ce-5d06-8137-77c68972a341 ← UEFI\CRT_A9087D1044AD18F7A94916D284CBC01827CF23CD8F60B79072C9CAA1FEF4D649 16:48:36 │ 5971a208-da00-5fce-b5f5-1234342f9cf7 ← UEFI\CRT_A9087D1044AD18F7A94916D284CBC01827CF23CD8F60B79072C9CAA1FEF4D649&ARCH_X64 16:48:38 assuming bootloader updates happen, are there any other concerns about dbx autoupdate, other than the possibility of failure? 16:48:41 │ c6682ade-b5ec-57c4-b687-676351208742 ← UEFI\CRT_A1117F516A32CEFCBA3F2D1ACE10A87972FD6BBE8FE0D0B996E09E65D802A503 16:48:44 │ f8ba2887-9411-5c36-9cee-88995bb39731 ← UEFI\CRT_A1117F516A32CEFCBA3F2D1ACE10A87972FD6BBE8FE0D0B996E09E65D802A503&ARCH_X64 16:48:47 and I think the device ID is stable too 16:48:51 that's actually a good question 16:48:55 hughsie_: dbx updates aren't guaranteed to be reflected in GetVariable() before a reboot 16:48:58 in the failure case, I'm honestly not 100% sad if the machine stops booting. it'll get attention 16:49:14 There is json output so we can query that 16:49:16 we wouldn't do that intentionally, but if that's the eventual consequence... 16:49:18 the dbx update adds keys essentially to NVRAM 16:49:24 so if you have 10KB spare space 16:49:31 and there's a 20KB addition 16:49:35 right 16:49:36 you'd hope it fails 16:49:52 some HP machines have not enough space left 16:50:00 on the LVFS we get the failure reports 16:50:16 also the biggest vendor with failures is "To Be Set By the O.E.M." 16:50:22 haah 16:50:33 where it's some $40 motherboard with some UEFI firmware from 2011 16:50:42 So we would need to enable fwupd-refresh.timer to get the MOTD? 16:50:47 yup 16:50:55 travier: I wonder if we should just do that anyway? 16:51:04 should that be in the fedora presets (not just FCOS)? 16:51:11 i said yup too early, that should have been "i think so" 16:51:18 GNOME Software & Discover manage that on desktops 16:51:30 better UX 16:51:45 travier: so maybe for server specific variants then 16:51:46 graphical UX I should say 16:51:48 yes 16:51:51 agree 16:52:00 iot, server, coreos 16:52:18 that would be a ffedora change :) 16:52:21 so there is one action item at least 16:52:47 So I am a bit out of my depth, can some one kick off the first prepose? 16:52:54 what's the plan for updating shim now? 16:53:03 the bootupd thing? 16:53:14 spresti1: I think we can do this for the first small bit 16:53:17 the bootupd thing, yeah 16:53:19 #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 +1 16:54:09 spresti1: I don't understand your question 16:54:16 Rather surprised that it isn't already 16:54:30 ah, you meant propose? 16:54:35 +1 to proposed, though self-actions don't require a vote afaik 16:54:35 travier you got it. and yeah lol 16:54:42 👍 16:54:53 +1 to proposed 16:55:05 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 well, it would enable it for CoreOS so the vote is about that 16:55:27 bgilbert: +1 16:55:39 just a question: is bootupd the only way you could do this? 16:55:54 #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 pjones: hughsie_ any interest in unifying the bootloader update stack on a single sofware? 16:56:15 i mean, fwupd can mount and copy stuff to the ESP 16:56:16 I'm not sure exactly what the part of this bootupd is actually solving is 16:56:19 we can not do it via RPMs postprocess scripts 16:56:23 hughsie_: we could replace bootupd with something else, but we need basically the same features in any event 16:56:39 what is bootupd actually required to do for shim updates? 16:56:45 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 pjones: it doesn't. that's part of what's missing 16:57:06 but isn't that the whole thing it was supposed to solve? 16:57:07 you mean a new BootXXXX target for the B? 16:57:20 hughsie_: and a startup check to swap the order, yeah 16:57:36 pjones: it also syncs the state of the ESP with the ostree. we don't get that for free 16:57:45 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 don't take this the wrong way; that doesn't sound super tricky 16:58:20 it's a very small program 16:58:39 well, it's a medium-small program. it has a lot of Architecture (TM) 16:58:47 why does it need to be a daemon? 16:58:49 I think anyone would be happy to have something other than bootupd own this piece. 16:58:57 yes, it has ostree integration which makes it larger 16:59:06 I don't think it is a daemon 16:59:15 it has a daemon component, I think dbus-activated 16:59:20 hughsie_: was happens if you Ctrl+C a command mid way? 16:59:26 it's trying to avoid that issue 16:59:37 it's FAT32 tho 16:59:45 just like dnf has a daemon 16:59:47 you don't get much atomic promises on that 16:59:56 I'm personally not going to argue that its architecture is optimal 17:00:13 https://github.com/coreos/bootupd/issues/454 17:00:16 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 Since Linux v6.0 the vfat filesystem has support for renameat2(..., RENAME_EXCHANGE): 17:00:28 you want the update to go through even if terminal dies for whatever reason 17:00:29 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 pjones: +1 17:00:50 pjones: +1 17:01:04 right; it seems just using Boot0001 and 0002 gets a lot of what you and for free 17:01:08 Note: We're at the halfway mark and we have another discussion 17:01:09 and then change by setting BootNext, rebooting, and checking in a startup .service whether it worked, and if so, update BootOrder 17:01:09 *want 17:01:35 (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 https://github.com/coreos/bootupd/issues/440 17:02:23 anybody want to summarize where we are in this conversation? 17:02:26 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 spresti1: that action was tangential 17:03:01 hughsie_: re Boot0001 and Boot0002, we're in a weird place right now 17:03:18 the design was to always use the Fallback Boot Behavior and never install boot entries 17:03:27 but it turns out that shim did that behind our back 17:03:40 *Fallback*? 17:03:56 FCOS still acts as though those boot entries don't exist, and I don't think bootupd messes with them 17:03:58 the default path in the efi partition 17:04:04 bootx64.efi 17:04:11 we have an open ticket to fix that but it isn't being worked on 17:04:11 aha, okay 17:04:17 not the efi fallback 17:04:28 being honest it sounds like you do need engineering resources :) 17:04:29 (confusing terminology again :/) 17:04:37 uh, may have gotten my term wrong, it's been a minute 17:04:40 https://github.com/coreos/fedora-coreos-tracker/issues/946 17:04:50 hughsie_: wouldn't hurt <3 17:05:39 maybe let's close out this topic in the next 5m 17:05:49 Unifying the approach on boot loader updates would be nice 17:05:58 I think the answer is: "yes, we'd like to update the dbx automatically" ? 17:06:05 +1 17:06:11 +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 +1 to that for sure 17:06:33 if there is a better option or a team more focused on that goal 17:06:41 who do we talk to about that? 17:06:50 #proposed we want to enable automatic update of dbx. This is pending on bootlaoder auto update work 17:07:19 well, i guess talk to jared who's the manager of the bootloader team 17:07:26 travier: but is it that simple? I'm guessing we'd be using fwupd to do the dbx update? 17:07:28 #proposed We will enable automatic update of the dbx only (not all firmwares). This is pending on bootlaoder auto update work 17:07:39 but if it's a request to do more things, he'll say no as we're crazy busy atm 17:07:48 travier: s/bootlaoder/bootloader/ 17:07:51 #proposed We will enable automatic update of the dbx only (not all firmwares). This is pending on bootloader auto update work 17:08:20 travier: +1 17:08:28 should we have that block on bootloader updates? or just let it fail if sigs are old? 17:08:32 #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 i.e. should we go ahead and enable it now 17:08:51 we could do that too indeed 17:09:17 bgilbert: hmm. I mean that means existing systems that are out there would certainly stop booting 17:09:28 dustymabe: not if we trust the fwupd safety check 17:09:36 I see 17:09:45 maybe ? 17:09:49 if it helps, i trust the fwupd safety check 17:09:49 :) 17:09:57 👍 17:09:59 +1 17:10:06 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 practically speaking, I think those are the options 17:10:22 (other options welcome) 17:10:45 (or ofc feel free to contribute to bootupd if you'd like) 17:10:49 maybe we should remove all the ostree integration from bootupd 17:11:05 fwiw, bootupd is fine for me, but it seems we've been talking about it for *years* now 17:11:08 another question is how this overlaps with all the stuff systemd is doing 17:11:20 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 i'm a bit confused why it's not a big deal for ostree too 17:12:07 surely fedora silverblue has the same problem 17:12:13 they have 17:12:22 all rpm-ostree based variants have this issue 17:12:24 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 sooo this makes it an ostree problem in my book 17:12:49 it's a problem for all image-based update systems that handle userspace and kernel but not other things 17:12:55 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 I am guessing silverblue at least gets the prompts for updating already, but I am not sure on that 17:13:15 +1 for the current proposed.. we can tweak it later (next meeting) if we like 17:14:07 +1 dusty 17:14:13 #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 +1 17:14:31 +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 not sure if I get a vote here, but I'd +1 it 17:14:43 bgilbert: we have a separate ticket for that 17:14:47 right 17:15:01 https://github.com/coreos/fedora-coreos-tracker/issues/1468 17:15:30 anyone against enabling that even if we don't have botloader updates? 17:15:46 travier: I guess it would be OK from what everyone is telling me 17:16:03 yep, just trying to clarify what -1 would look like here 17:16:18 maybe we should do it with a long preview window in `next` or something 17:16:30 +1 to enable, it'll do some incremental amount of good. `next` first sounds reasonable 17:16:39 could roll it in for f39 transition 17:16:47 there is no urgency until there is 17:16:54 ok to go agreed? 17:17:10 +1 17:17:11 jforbes: for bootloader though, not dbx? 17:17:22 both really 17:17:36 #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 +1 17:17:52 dustymabe: the nature of the attacks is that someone installs and old bootloader without telling you ;) 17:17:58 *an 17:18:09 jforbes hughsie_ pjones: thanks for the input, much appreciated! 17:18:09 meaning start the preview, and if you need to force it through quicker it is an option 17:18:12 Thanks for coming and for the lively discussion pjones hughsie_ 17:18:16 no probs 17:18:29 nice to use IRC again after all these months 17:18:34 :) 17:18:35 hah, indeed 17:18:37 Ok lets take the rest of this convo and move it to next meeting or offline. 17:18:37 Lets jump topics really quick. 17:18:42 #topic tracker: New Package Request: NetworkManager-libreswan 17:18:47 :-) 17:18:52 #link https://github.com/coreos/fedora-coreos-tracker/issues/1504 17:18:54 alright, I'll summarize this one 17:19:07 Thank you travier 17:19:18 The idea is a ask to add libreswan and the corresponding NetworkManager integration to FCOS 17:20:05 This is going to be added in some form to RHCOS/OCP to enabe/simplify more ipsec deployment use cases 17:20:38 so the question is do we want this in FCOS directly 17:20:49 With that lovely intro from travier 17:20:50 discuss 17:20:57 not enough to pull in Python. any prospect of removing the dep? 17:21:01 Right now the main problem is the Python de 17:21:03 dep 17:21:06 it will allow native, host, support for ipsec 17:21:19 I have a question: why do we use systemd-networkd on FCOS ? 17:21:21 so I dont quite understand why is python so bad? 17:21:24 quentin9696[m]: we don't 17:21:31 Python dep is btw just on 2 diagnostic commands 17:21:36 why don't, sorry 17:21:51 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 quentin9696[m]: there was an extremely long debate about it early on 17:22:11 yeah, I mean there are a bunch of other packages getting brought in too (not just the python dep) 17:22:29 thanks travier 17:22:31 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 ^^ that was an answer regarding systemd-networkd 17:22:57 bgilbert: alright, make sense 17:23:44 yuval: could they be split into an optional subpackage? 17:24:35 In theory? I believe so. but I'm not a libreswan maintainer and that would be up to them 17:24:38 Another question would be about why we're choosing libreswan over strongswan, or why ipsec and not another VPN protocol 17:24:50 yeah just wanted to comment on that 17:25:05 while StrongSwan is not an option for RHCOS ATM, it might be a better choice for fcos 17:25:17 we agreed to add wireguard 17:25:31 we agreed to add the tools for wireguard 17:25:35 yes 17:25:37 as wireguard was already in the kernel 17:25:54 wireguard support is core networkmanager afaik 17:25:55 we agreed to add the bits needed to use wireguard 17:26:08 IPsec is at least standardized 17:26:11 you might wanna consider adding both. there are different use cases (and both are supported in kernel) 17:26:23 (both = ipsec and wireguard) 17:26:31