18:00:02 <paragan> #startmeeting FESCO (2015-06-10)
18:00:02 <zodbot> Meeting started Wed Jun 10 18:00:02 2015 UTC.  The chair is paragan. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:02 <paragan> #meetingname fesco
18:00:02 <zodbot> The meeting name has been set to 'fesco'
18:00:03 <paragan> #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh
18:00:03 <paragan> #topic init process
18:00:03 <zodbot> Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza
18:00:10 <ajax> hello
18:00:11 <jwb> hi
18:00:13 <mitr> Hello
18:00:24 <jkurik> hi
18:00:33 <thozza> hi all
18:00:37 <nirik> morning
18:01:41 <paragan> Okay let's start now
18:01:52 <paragan> #topic #1445 F23 Self Contained Changes
18:01:53 <paragan> .fesco 1445
18:01:53 <paragan> https://fedorahosted.org/fesco/ticket/1445
18:01:55 <zodbot> paragan: #1445 (F23 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1445
18:02:10 <paragan> Netizen_Spin
18:02:23 <paragan> https://fedoraproject.org/wiki/Changes/Netizen_Spin
18:02:37 <nirik> we asked a number of questions on list... but I saw no replies from the owner.
18:02:42 <jwb> i'm -1 on this
18:02:42 <paragan> I see that since the Netizen change page has created there are no updates happened to that wiki page.
18:02:44 <thozza> So I didn't seen much of a discussion
18:02:58 <sgallagh> Hi, I'm here (late)
18:03:07 <paragan> sgallagh, Hi
18:03:08 <nirik> I'm -1 based on what I know now, but if the owner wants to reply and revise and resubmit before the deadline, great.
18:03:20 <thozza> sgallagh: discussing the Netizen spin
18:03:34 <mitr> -1 without prejudice against resubmission seems cleanest
18:03:38 <sgallagh> Yeah, the Netizen thing sounds like it would be better as a remix, honestly.
18:03:52 <thozza> -1
18:03:56 <ajax> same, -1
18:03:58 <sgallagh> -1, for the record
18:04:03 <thozza> due to lack of response and interest
18:04:06 <paragan> I am too -1
18:05:18 <jkurik> I discussed it with jreznik today and his POV is for remix as well
18:05:55 <paragan> proposal: FESCo did not see any updates on the Netizen change page hence rejecting this change
18:06:02 <jkurik> I do not have a vote, but -1 from my side as well :-)
18:06:17 <paragan> looks all are -1 here
18:06:26 <thozza> paragan: yes
18:06:30 * rishi is here
18:06:33 <rishi> -1 too
18:07:01 <paragan> #agreed FESCo did not see any updates on the Netizen change page hence rejecting this change ( -7, 0, 0)
18:07:16 <paragan> next self-contained change proposal is
18:07:19 <paragan> https://fedoraproject.org/wiki/Changes/SystemFirmwareUpdates
18:07:30 <ajax> +1 yes plz
18:07:42 <paragan> As per update by pjones on this change page, implementation of this is almost completed. Looks like this change is available in gnome-software-3.17.2 release.
18:07:48 <nirik> +1
18:07:48 <jkurik> there was no discussion on mailing list, but seems to be ok from my side
18:07:53 <mitr> +`
18:07:57 <rishi> Yes, _1.
18:07:59 <rishi> +1
18:07:59 <mitr> +1
18:08:02 <nirik> on to a hopefully brighter future! :)
18:08:07 <paragan> yes though no discussion looks good +1
18:08:37 <thozza> +1
18:08:40 <jwb> +1 though i'll note we carry a kernel patch for now to make this possible
18:09:00 <pjones> jwb: but that's already upstream
18:09:15 <jwb> pjones, yes, but not in Linus' tree until 4.2 timeframe
18:09:19 <pjones> right.
18:09:53 <sgallagh> +1
18:10:23 <paragan> #agreed https://fedoraproject.org/wiki/Changes/SystemFirmwareUpdates change (+7, 0, 0)
18:10:31 <paragan> #topic #1447 F23 System Wide Change: Default Local DNS Resolver
18:10:32 <paragan> .fesco 1447
18:10:33 <paragan> https://fedorahosted.org/fesco/ticket/1447
18:10:34 <zodbot> paragan: #1447 (F23 System Wide Change: Default Local DNS Resolver) – FESCo - https://fedorahosted.org/fesco/ticket/1447
18:10:59 <thozza> so any questions? :)
18:11:13 <mitr> thozza: The one on trust configuration I sent to devel today; sorry about being so late.
18:11:16 <paragan> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#Upgrade.2Fcompatibility_impact
18:11:40 <sgallagh> I'll note that the Server WG discussed this topic yesterday and is in favor of supporting it in that Edition
18:11:42 <thozza> mitr: didn't see it
18:11:48 * nirik is +1
18:11:54 <sgallagh> I am also +1
18:12:04 <mitr> I am +1 anyway, there are several reasonable ways to do it. But if we do go the “the configured resolver is trusted by default” way, that will need non-trivial documentation and PR effort.
18:12:08 <thozza> sgallagh: feel free to ping some of us next time, we can participare
18:12:09 <paragan> I am +1 to this proposal
18:12:11 <thozza> participate
18:12:14 <nirik> it would be nice to figure out the hotspot login story and some other items, but hopefully we can
18:12:22 <mitr> thozza: https://lists.fedoraproject.org/pipermail/devel/2015-June/211282.html
18:12:28 <rishi> Yes, +1.
18:12:39 <sgallagh> thozza: FWIW, the support was overwhelmingly positive.
18:12:44 <ajax> aestheically i'm in favor of a local resolver even before we consider dnssec
18:12:46 <thozza> mitr: we definitely want to document anything that needs to be documented
18:12:59 <thozza> we are still working on some implementation stuff
18:13:05 <thozza> and also some automated testing
18:13:38 <paragan> thozza, I see this https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#Option_1_-_Use_experimental_implementation_available_in_Fedora_20_and_newer
18:13:50 <thozza> mitr: so we proposed some changes to glibc, but there was no response
18:13:57 <thozza> they are actively ignoring us ;)
18:14:12 <thozza> so there is currently no way to tell if the server is trusted
18:14:15 <rishi> thozza: But Carlos is on the Wiki.
18:14:25 <pspacek> mitr: In short term (for this release) we will simply have the validator locally but applications will not be relaying on it. We have some patches on libc-aplha list which add 'trusted' API for applications - this should be a next logical step but should not stop us from running the resolver locally.
18:14:35 <thozza> other than SELinux ensuring that nothing rewrites the resolv.conf
18:15:01 <thozza> rishi: yes, but in the end, there was no response... although he was included in the initial discussion
18:15:09 <thozza> upstream is really unresponsive in this
18:15:21 <nirik> he might just be busy/away...
18:15:25 <pspacek> mitr: In other words, the locally running resolver should be beneficial even if applications do not integrate with it directly.
18:15:50 <ajax> carlos is pretty busy all the time, yeah
18:15:52 <thozza> nirik: may be.... we tried to refresh the discussion on the upstream list, but no luck
18:15:59 <thozza> we will have to do it again
18:16:00 <pspacek> nirik: Unfortunatelly this discussion with upstream is (not) going on at least for one year now.
18:16:34 <nirik> sorry to hear it. I just prefer to assume people are busy than they are actively ignoring something. ;) Seems far more likely
18:16:46 <mitr> pspacek: Sure; still, if we are changing the ways DNS is configured, it would be mighty convenient if we only changed it _once_ to whatever the final mechanism and semantics are; and “is the resolver you are configuring trusted” is a pretty essential component.
18:17:12 <nirik> but we all know how it goes... so all you can do is keep pushing and try and get some answers.
18:17:45 <dgilmore> hey all
18:17:46 <thozza> nirik: yes, we plan to do that
18:18:16 <thozza> but we don't think that without the glibc support the feature is useless
18:18:29 <pspacek> mitr: I understand that. The intent is autoconfigure it if local resolver is running (and so we are able to support the new behavior) and honor the old behavior otherwise (with untreusted resolver by default). I.e. users should not see a change because this will be done by dnssec-trigger or some other dameon, once we get the new Glibc API.
18:18:31 <dgilmore> I am +1 to thedefault local dns
18:18:39 <thozza> I'm +1 for the record
18:18:47 <ajax> thozza: is anyone working on getting our docker config to do something sane for this?
18:19:14 <mitr> pspacek: OK, trusted iff local (modulo Docker?) is a good story. Just write it down :)
18:19:43 <ajax> "sane" could even be "ignores the local resolver" as long as dns works, as far as i'm concerned
18:19:51 <thozza> ajax: PJP should be doing it
18:20:00 <ajax> sweet, good enough for me.  +1
18:20:09 <paragan> I see +8 votes so lets accept this.
18:20:11 <thozza> we have weekly sync call on Friday, so trying to really get everything done for F23
18:20:13 <pspacek> mitr: Well, there is nothing to write down until we get the Glibc API - there is simply no way to express this in API.  I would rather not claim that something is trusted if the API does not convey this type of information.
18:20:51 <pspacek> ajax: Docker uses 8.8.8.8 by default if resolv.conf contains only 127.0.0.1.
18:20:51 <paragan> #agreed F23 System Wide Change: Default Local DNS Resolver (+8 , 0, -0)
18:20:58 <nirik> thozza: I assume disabling this is just removing dnssec-triggerd ?
18:21:01 <mitr> pspacek: fair enough.
18:21:28 <ajax> pspacek: that'll do!
18:21:37 <nirik> (ie, we should document how to disable for folks that don't want it for whatever reason)
18:21:51 <thozza> nirik: right
18:22:08 <thozza> It is enough to remove the dns=unbound from NM configuration
18:22:37 <thozza> if it is not there, dnssec-trigger is basically ignoring NM dispatcher events
18:22:54 <nirik> but it would still put 127.0.0.1 in /etc/resolv.conf no?
18:23:08 <nirik> anyhow, don't mean to hyjack.
18:23:09 <thozza> nirik: no, if it does, it is a bug
18:23:36 <thozza> I had to disable it on F22 due to SELinux, but new policy is in updates-testing, so will enable it tomorrow
18:23:56 <thozza> they really hardened the policy in F22 vs F21
18:25:13 <paragan> let's move to the next topic
18:25:45 <paragan> #topic Next week's chair
18:25:45 <paragan> any volunteer? :)
18:26:10 <nirik> I can do next week I guess.
18:26:32 <paragan> Thanks nirik for volunteering
18:26:50 <paragan> #info nirik will chair next week's meeting
18:27:05 <paragan> #topic Open Floor
18:27:38 <nirik> I have one item.
18:27:54 <paragan> sure
18:28:47 <nirik> So, for fedora 22 we reverted the anaconda password check thing to allow double done. This was done ONLY for f22... with the idea we would come up with a wider policy around this for f23.
18:29:01 <nirik> I've not have any time to try and gather people on this. ;(
18:29:17 <ajax> bleh
18:29:18 <nirik> so, would anyone else be interested in taking this on? or helping out?
18:29:26 <nirik> Also, what exactly do we want out of this...
18:29:40 <nirik> just a password length/strength policy? or something higher level?
18:29:46 <nirik> ajax: I completely agree.
18:29:58 <nirik> folks are filing anaconda bugs already for f23 about the current behavior.
18:29:59 <paragan> Workgroup's need to define their own policy right?
18:30:20 <nirik> well, except we also don't define any base policy
18:30:21 <rishi> nirik: By current behaviour you mean the double done?
18:30:36 <nirik> rishi: I mean no double done
18:30:42 <rishi> ok, right
18:31:24 <nirik> So, I guess I can try and move it forward... have some base password stength policy and then workgroups can override if they wish.
18:31:33 <mitr> I would suggest principle 1: policy is defined in pwquality.conf; kickstart may provide a way to set contents of pwquality.conf but anaconda should not have a separate configuration that applies only to itself and not to the installed system, or vice versa.
18:31:34 <nirik> sadly, spins aren't able to do that so they would get the base policy probibly
18:31:36 <rishi> I don't know how to define a base policy because it seems it doesn't have a target audience / product.
18:31:38 <jwb> setting a base to have the WGs just define their own seems to be counter to what the anaconda team was after
18:31:44 <mitr> Then we can deal with product differences through the existing kickstart mechanisms I guess.
18:32:52 <mitr> (And it would still be great to have more on-line rate limiting and looser password quality requirements; but that requires someone to take on having this sytem-wide as a project.)
18:33:00 <nirik> jwb: well, they did provide a way for products to set their own
18:33:40 <rishi> I like what mitr is saying because it gives a convenient way to skirt around the whole "base policy" issue.
18:33:45 <jwb> nirik, then i don't see a point in defining anything else.
18:34:05 <mitr> rishi: That part I don’t particularly like; Workstation isn’t exempt from needing to be secure.
18:34:11 <nirik> jwb: well, the non products get a default set by anaconda team
18:34:14 <nirik> that many people don't like
18:34:33 <mitr> rishi: OTOH without this hypothetical rate limiting, having a truly great base policy may not be possible, so…
18:34:42 <jwb> nirik, why?  spins have kickstarts just like editions...
18:35:01 <nirik> jwb: it won't work. It has to be installed in the tree that anaconda is running from.
18:35:10 <nirik> it replaces files in anaconda I think.
18:35:20 <rishi> mitr: Umm... Workstation doesn't want to be sure?
18:35:23 <nirik> the products can do that because they have the foo-product branding stuff
18:35:29 <rishi> *secure
18:35:30 <nirik> which is pulled in at build time
18:35:47 <jwb> nirik, that sounds like something the spins could leverage still.
18:35:54 <mitr> rishi: Workstation is arguing for the loosest requirements IIRC.
18:36:06 <nirik> jwb: only if we allowed xfce-product packages/branding
18:36:12 <nirik> s/xfce/whatever/
18:36:13 <jwb> why wouldn't we?
18:36:21 <nirik> they aren't 'products' ?
18:36:24 <dgilmore> we should define a base policy, and allow the products to change it
18:36:43 <jwb> nirik, so?  why can't spins have their own branding?
18:37:02 <rishi> mitr: "loosest" for some, "sanest" for others. I don't think one can cook up a policy out of thin air.
18:37:12 <rishi> It has to be driven by what the target audience is.
18:37:24 <mitr> rishi: /me vaguely waves his security credentials around ☺
18:37:25 <rishi> Whatmight work for Workstation, might not work for Server.
18:37:31 <nirik> jwb: I guess. the products stuff was a massive pain from a releng/creation side. If we want 12 more of them I guess we could..
18:37:37 <nirik> but I predict breakage
18:37:44 <mitr> rishi: Anyway, side issue
18:37:59 <jwb> nirik, well, that plays well into my "spins are not worthwhile" gripe i guess
18:38:10 <leigh123linux> IMO the policy nazi's should  butt out and let user's decide their own password quality :)
18:38:21 <nirik> well, it seems a lot of work for the spins to just override this one thing
18:38:21 <jwb> leigh123linux, nobody here is a nazi.  not helpful.
18:38:44 <nirik> then we have a default in anaconda that... no one uses?
18:39:07 * jwb shrugs
18:39:18 <jwb> i think this is not worth doing full stop
18:39:32 <nirik> anyhow. how should we best move this forward? Does someone want to propose something to the list? or wait for me to try and gather people for a proposal? or ?
18:39:33 <sgallagh> The first problem is that anaconda folks came up with a set of arbitrary and very strict requirements.
18:39:56 <leigh123linux> jwb: users should be free to chose themselves
18:40:03 <jwb> sgallagh, the second problem is that any set of requirements is arbitrary and nobody is going to agree on them
18:40:04 <sgallagh> None of the products or spins wanted that, so they gave us some ability to override it, but again it only works for productimg packages
18:40:29 <ajax> leigh123linux: linux might be about choice, fedora is not.  take it elsewhere.
18:40:33 <sgallagh> jwb: Sure, but I didn't really hear anyone saying that stricter passwords was an improvement
18:40:45 * rishi looks at mitr
18:41:07 <ajax> building a product necessarily requires making decisions on behalf of your consumers
18:41:13 <ajax> "choice" is not a goal here
18:41:32 <jwb> ok, i'm going to stop interjecting.  i'm not helping and i don't care one bit what the requirements are
18:41:53 <sgallagh> Right, but the problem is that the default as shipped by anaconda doesn't seem to agree with *anyone* (defining anyone as the WGs and Spin maintainers)
18:42:06 <sgallagh> So that (to me) defines an incorrect default
18:42:51 <nirik> sgallagh: sure.
18:43:17 <nirik> ok. I don't think we are going to get anywhere here... I'll see if I can do something by next week and write up some kind of proposal...
18:43:28 <rishi> sgallagh: Can't Anaconda just go back to the "double done" forever, and le the products and spins do whatever they want? (Ignoring the exact mechanisms for that)
18:43:30 <mitr> sgallagh: Trying to persuade anaconda would be the cleanest solution, yes. Considering that we have a viable workaround (and the “F22 only” threat is not honestly credible) I don’t see that much urgency.
18:43:47 <sgallagh> rishi: That was the stopgap from F22, but the anaconda folks don't like that
18:43:51 <rishi> Why?
18:43:56 <sgallagh> And the UXD people think it's bad UX
18:44:03 <nirik> The f22 only was a patch only applied to f22 branch.
18:44:29 <sgallagh> rishi: "Why" has not been clearly explained (to me)
18:44:35 <rishi> nirik: That is just a detail. :)
18:44:45 <nirik> I'll try talking out of meeting with anaconda, t8m and others and see if I can come up with something people will agree on.
18:45:04 <rishi> sgallagh: Ok. :)
18:45:08 <paragan> nirik, thanks for taking this initiative
18:45:14 <nirik> if I can find the time. ;(
18:45:28 <sgallagh> nirik: Thanks. I wish I could help, but I'm overcommitted as it is
18:45:40 <sgallagh> (see Server SIG meeting minutes...)
18:45:52 <nirik> sure
18:45:54 <rishi> sgallagh: UX people don't like the idea of being able to override the weak password warning? Or they don't like the "double done" way of doing that?
18:46:04 <sgallagh> rishi: I think both
18:46:42 <sgallagh> But like I said; I don't have all the detail
18:47:06 <nirik> It's definitely not discoverable.
18:47:12 <nirik> (easily anyhow)
18:48:04 <paragan> any other thing for open floor?
18:48:17 <jwb> elections reminder
18:49:00 <dgilmore> last I looked there was 5 nominations for 4 seats
18:50:47 * rishi has got to leave
18:50:54 <rishi> See you next!
18:51:09 <paragan> sure
18:51:20 <paragan> If there is nothing to discuss then I'll end the meeting in a minute
18:51:23 <sgallagh> dgilmore: We require 6 nominations, right?
18:51:32 <jwb> what?
18:51:49 <jkurik> sgallagh: why ?
18:51:52 <paragan> sgallagh, I don't see that rule
18:52:22 <nirik> A minimum number of candidates are necessary in order to hold an election. This will be the number of open seats + 25%.
18:52:33 <sgallagh> Ah, my mistake
18:52:37 <nirik> https://fedoraproject.org/wiki/FESCo_election_policy
18:53:06 <sgallagh> Carry on
18:55:57 <paragan> okay let's end the meeting now
18:56:00 <paragan> thanks everyone for having this meeting.
18:56:01 <paragan> #endmeeting