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