16:31:01 <dustymabe> #startmeeting fedora_coreos_meeting 16:31:01 <zodbot> Meeting started Wed Dec 18 16:31:01 2019 UTC. 16:31:01 <zodbot> This meeting is logged and archived in a public location. 16:31:01 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:31:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:31:01 <zodbot> The meeting name has been set to 'fedora_coreos_meeting' 16:31:11 <dustymabe> #topic roll call 16:31:53 <walters> .hello2 16:31:54 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com> 16:32:04 <dustymabe> #chair walters 16:32:04 <zodbot> Current chairs: dustymabe walters 16:32:46 <jlebon> .hello2 16:32:47 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com> 16:32:56 <dustymabe> #chair jlebon 16:32:56 <zodbot> Current chairs: dustymabe jlebon walters 16:33:16 <mnguyen_> .hello mnguyen 16:33:17 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com> 16:33:25 <dustymabe> #chair mnguyen_ 16:33:25 <zodbot> Current chairs: dustymabe jlebon mnguyen_ walters 16:34:30 <dustymabe> #chair kaeso 16:34:30 <zodbot> Current chairs: dustymabe jlebon kaeso mnguyen_ walters 16:34:41 <dustymabe> #topic Action items from last meeting 16:35:01 <dustymabe> * jlebon to open an RFE for ignition to make logic for #279 easier 16:35:03 <dustymabe> * miabbott to help us get the azure image upload/boot tested 16:35:04 <red_beard> .hello redbeard 16:35:05 <dustymabe> * lucab to send upgrade email with manual recovery stepsY 16:35:05 <zodbot> red_beard: redbeard 'Brian 'redbeard' Harrington' <bharring@redhat.com> 16:35:19 <miabbott> .hello miabbott 16:35:20 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com> 16:35:21 <dustymabe> well welcome red_beard 16:35:25 <dustymabe> #chair red_beard miabbott 16:35:25 <zodbot> Current chairs: dustymabe jlebon kaeso miabbott mnguyen_ red_beard walters 16:35:37 <red_beard> dustymabe: morning. i finally figuted out timezones 16:36:04 <dustymabe> #info timezones are hard 16:36:11 <miabbott> dustymabe: still have the Azure task on my plate; things in $DAYJOB blew up last week 16:36:18 <dustymabe> miabbott: it happens 16:36:20 <jlebon> #info jlebon filed Ignition RFE https://github.com/coreos/ignition/issues/903 16:37:04 <dustymabe> luca just told me he's having bridge issues, will try to join shortly 16:38:06 <dustymabe> #info luca sent out an email for upgrade email with manual recover steps https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/message/NM73RYDKVTHQFFX2IYKQJSDPQI2CCLWW/ 16:38:23 <dustymabe> thanks luca for doing that 16:38:53 <dustymabe> I'll re-action the last item 16:38:59 <dustymabe> #action miabbott to help us get the azure image upload/boot tested 16:39:13 <miabbott> 👍 16:39:15 <dustymabe> first order of business for the day: holidays 16:39:25 <dustymabe> #topic meetings during the next two weeks 16:39:41 <kaeso[m]> .hello lucab 16:39:42 <zodbot> kaeso[m]: lucab 'Luca Bruno' <lucab@redhat.com> 16:39:53 <dustymabe> I propose that we cancel the next two meetings since many people are away during the holidays. 16:40:23 <dustymabe> ack/nack ? 16:40:34 <dustymabe> #chair kaeso[m] 16:40:34 <zodbot> Current chairs: dustymabe jlebon kaeso kaeso[m] miabbott mnguyen_ red_beard walters 16:40:44 <jlebon> ack 16:40:45 <mnguyen_> ack 16:40:58 <red_beard> ack 16:41:01 <kaeso[m]> ack (I'll be away on both) 16:41:48 <dustymabe> #agreed we'll cancel the 12/25/2019 and 01/01/2020 meetings since they are both holidays for many 16:42:11 <dustymabe> #topic Request for usbguard package inclusion 16:42:15 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/326 16:42:29 <dustymabe> thoughts on inclusion of this package in FCOS? 16:43:39 <red_beard> dustymabe: to confirm, it's already packaged in Fedora? 16:44:15 <dustymabe> #link https://apps.fedoraproject.org/packages/usbguard 16:44:16 <kaeso[m]> dustymabe: I started doing some due diligence 16:44:19 <jlebon> how standard is it to have it included in other distros? also, did CL include it? 16:44:23 <dustymabe> red_beard: yep 16:44:36 <dustymabe> kaeso[m]: yep, I saw that. thank you 16:44:45 <kaeso[m]> dustymabe: I'm not totally convinced on both the usecase and the fact that it should be part of the OS 16:44:50 * red_beard goes to look at the specfile 16:45:01 <kaeso[m]> jlebon: did not have that, to the best of my knowledge 16:45:25 <dustymabe> yeah, i'm not sure either. i've never used it before 16:45:28 <kaeso[m]> dustymabe: at least there is still some discussion to be done about the defaults, too 16:45:58 <red_beard> how is this "better" than udev rules? 16:46:09 <dustymabe> i've typically considered physical access to a server to mean it can be owned anyway 16:46:36 <red_beard> dustymabe: also true 16:46:56 <walters> there's some degrees there 16:47:03 <dustymabe> true 16:47:14 <walters> plugging in a USB device quickly is quite different from 5 minutes with uninterrupted access 16:47:46 <red_beard> looking at the rule language, it appears to be a different DSL for largely the same functionality (only now requiring more userspace mechanisms) 16:47:49 <kaeso[m]> red_beard: chiming on the same line, the real blocking is kernel-side and the policy logic can be done at several levels (udev / usbguard / a long-running container) 16:47:58 <red_beard> (for reference - https://usbguard.github.io/documentation/rule-language.html ) 16:48:03 <walters> certainly today if you can reboot you can own the system (default grub isn't locked, etc.) 16:48:36 <dustymabe> walters: :) https://dustymabe.com/2015/07/06/encrypting-more-boot-joins-the-party/ 16:48:48 <kaeso[m]> walters: yes, I think our current (informal) threat model does not cover "malicious physical access" 16:48:50 <dustymabe> I experimented in that space some time ago 16:49:03 <walters> Note dm-crypt is *not* integrity 16:49:41 <red_beard> and that the userspace components implement their own ACLs to allow users to mutate the rules 16:49:58 <dustymabe> so. it seems like we have some questions for the person who opened the ticket? it looks like the OP references something from NIST, so they might be going for compliance? 16:50:02 <red_beard> which gets into more of the question: how much should non-administrative users be making changes to the USB configs on the host 16:50:47 <kaeso[m]> the NIST items referenced does not relate to the host, BTW, but other similar items do 16:51:13 <red_beard> well, JAORMX (Juan Osorio Robles) is a Red Hatter, so it souldn't be too hard to spark some follow up conversations. 16:51:18 <walters> I think USBGuard upstream wants to support the "user owns desktop" case, but the request here is more I think to support the rule language, not anything related to "unprivileged" users 16:51:44 <dustymabe> walters: agree 16:52:04 <walters> IOW we could configure USBGuard for RHCOS at least to not listen on DBus at all 16:52:32 <walters> (But it's probably not worth carrying the delta to do so) 16:52:45 <red_beard> wouldn't that really just be a mechanism to take USBGuard rules and render them as udev within CT? 16:53:01 <red_beard> which achieves the ability to "specify a policy for what devices are allowed" 16:54:09 <dustymabe> yes, i think so 16:54:19 <dustymabe> it all depends on how much we want to maintain over time 16:54:59 <dustymabe> i.e. do we write sugar to do something like this in FCCT or do we include the package that allows users to lay down a file and achieve the goal that way 16:55:37 <dustymabe> i tend to vote for things that make our maintenance burden easier 16:56:05 <dustymabe> which is not always the most ideal solution for the user, unfortunately 16:56:19 <dustymabe> so, do we have any questions we want to ask in the ticket? 16:56:32 <red_beard> dustymabe: one other option - a blog post on how to do this with udev through fedora magazine 16:56:47 <red_beard> raises the tide of all ships (and udev containing distros) 16:57:15 <dustymabe> red_beard: sounds good to me. would you mind pointing out in the ticket that this can be achieved with udev and maybe all we need to do is document it? 16:57:33 <red_beard> :thumbs_up: 16:57:36 <red_beard> ack 16:57:59 <kaeso[m]> taking a step back, the NIST compliance thing does not need usbguard, just https://www.kernel.org/doc/Documentation/usb/authorization.txt 16:59:16 <dustymabe> kaeso[m]: also something that would be good to add to the ticket 16:59:40 <dustymabe> would you mind? 16:59:48 <walters> I suspect the *requirement* doesn't need it, but the RHEL *implementation* does 17:00:28 <dustymabe> walters: i.e. that's the solution that RHEL engineers prefer? 17:01:00 <walters> Right, I mean I'm not *sure* but if the existing solution didn't actually use usbguard's rules why would they ask for it? 17:01:31 <walters> To be clear I'm not arguing necessarily for including usbguard 17:01:51 <dustymabe> not sure who the OP is - ahh it says Red Hat Finland 17:02:07 <dustymabe> ehh, either way let's carry on the discussion in the ticket 17:02:19 <dustymabe> we'll see where it goes 17:02:40 <dustymabe> any other comments before the next topic? 17:03:36 <red_beard> not from me 17:04:05 <dustymabe> #topic Create stable stream 17:04:14 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/331 17:04:30 <dustymabe> jlebon: created this ticket this morning. 17:05:25 <dustymabe> we've been in our testing/preview cycle for some time now. we've still got a lot of work to do, but our release engineering and tooling bits are working pretty well and we've got FCOS mostly where we need it to be without a ton of crazy changes planned 17:06:13 <dustymabe> so the logical next thing to do is to create a stable stream for us to start testing against (will require some changes to our tools as outlined in the ticket) 17:06:56 <dustymabe> hopefully we'll work out any kinks with our tools for multiple streams as part of this process 17:07:58 <dustymabe> there are a few other things to do before things are good enough. we need to complete the migration to the new installer (thanks bgilbert for the rewrite) among a few others 17:08:23 <kaeso[m]> jlebon: I failed to parse your last reply in that ticket, what was your plan? 17:08:55 <jlebon> kaeso[m]: i tweaked the comment :) 17:09:24 <dustymabe> thank you jlebon and kaeso[m] for helping getting our tooling to a good state where we can take the next step 17:10:19 <jlebon> there's the website bit left, which is important. before, rfairley worked on that, though he might be busy 17:10:45 <dustymabe> jlebon: I know abai has been working on the website recently 17:11:15 <dustymabe> https://pagure.io/fedora-web/websites/pull-request/77 17:11:33 <jlebon> cool, let's rope in abai then :) 17:11:50 <dustymabe> so he might be able to pick up a piece of work there. let's create a separate issue for the website work 17:12:19 <dustymabe> #action jlebon to create a separate issue to track the updates needed to the websites for the stable stream 17:12:26 <dustymabe> jlebon: ^^ ok? 17:12:30 <jlebon> ack 17:12:48 <dustymabe> #topic docs help 17:13:39 <dustymabe> #info we have some professional help coming in the form of adrianne, please welcome her if you see her in the community or on the issue trackers 17:14:12 <dustymabe> #topic open floor 17:14:18 <dustymabe> anyone have anything for open floor? 17:15:15 * dustymabe forces mnguyen_ to come up with a topic for open floor 17:15:35 <mnguyen_> i've got nothing 17:15:47 <mnguyen_> happy holidays 17:15:48 <mnguyen_> :D 17:15:53 <dustymabe> perfect topic! 17:15:57 <dustymabe> #endmeeting