18:00:02 #startmeeting FESCO (2015-06-10) 18:00:02 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:02 #meetingname fesco 18:00:02 The meeting name has been set to 'fesco' 18:00:03 #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh 18:00:03 #topic init process 18:00:03 Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza 18:00:10 hello 18:00:11 hi 18:00:13 Hello 18:00:24 hi 18:00:33 hi all 18:00:37 morning 18:01:41 Okay let's start now 18:01:52 #topic #1445 F23 Self Contained Changes 18:01:53 .fesco 1445 18:01:53 https://fedorahosted.org/fesco/ticket/1445 18:01:55 paragan: #1445 (F23 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1445 18:02:10 Netizen_Spin 18:02:23 https://fedoraproject.org/wiki/Changes/Netizen_Spin 18:02:37 we asked a number of questions on list... but I saw no replies from the owner. 18:02:42 i'm -1 on this 18:02:42 I see that since the Netizen change page has created there are no updates happened to that wiki page. 18:02:44 So I didn't seen much of a discussion 18:02:58 Hi, I'm here (late) 18:03:07 sgallagh, Hi 18:03:08 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 sgallagh: discussing the Netizen spin 18:03:34 -1 without prejudice against resubmission seems cleanest 18:03:38 Yeah, the Netizen thing sounds like it would be better as a remix, honestly. 18:03:52 -1 18:03:56 same, -1 18:03:58 -1, for the record 18:04:03 due to lack of response and interest 18:04:06 I am too -1 18:05:18 I discussed it with jreznik today and his POV is for remix as well 18:05:55 proposal: FESCo did not see any updates on the Netizen change page hence rejecting this change 18:06:02 I do not have a vote, but -1 from my side as well :-) 18:06:17 looks all are -1 here 18:06:26 paragan: yes 18:06:30 * rishi is here 18:06:33 -1 too 18:07:01 #agreed FESCo did not see any updates on the Netizen change page hence rejecting this change ( -7, 0, 0) 18:07:16 next self-contained change proposal is 18:07:19 https://fedoraproject.org/wiki/Changes/SystemFirmwareUpdates 18:07:30 +1 yes plz 18:07:42 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 +1 18:07:48 there was no discussion on mailing list, but seems to be ok from my side 18:07:53 +` 18:07:57 Yes, _1. 18:07:59 +1 18:07:59 +1 18:08:02 on to a hopefully brighter future! :) 18:08:07 yes though no discussion looks good +1 18:08:37 +1 18:08:40 +1 though i'll note we carry a kernel patch for now to make this possible 18:09:00 jwb: but that's already upstream 18:09:15 pjones, yes, but not in Linus' tree until 4.2 timeframe 18:09:19 right. 18:09:53 +1 18:10:23 #agreed https://fedoraproject.org/wiki/Changes/SystemFirmwareUpdates change (+7, 0, 0) 18:10:31 #topic #1447 F23 System Wide Change: Default Local DNS Resolver 18:10:32 .fesco 1447 18:10:33 https://fedorahosted.org/fesco/ticket/1447 18:10:34 paragan: #1447 (F23 System Wide Change: Default Local DNS Resolver) – FESCo - https://fedorahosted.org/fesco/ticket/1447 18:10:59 so any questions? :) 18:11:13 thozza: The one on trust configuration I sent to devel today; sorry about being so late. 18:11:16 https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#Upgrade.2Fcompatibility_impact 18:11:40 I'll note that the Server WG discussed this topic yesterday and is in favor of supporting it in that Edition 18:11:42 mitr: didn't see it 18:11:48 * nirik is +1 18:11:54 I am also +1 18:12:04 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 sgallagh: feel free to ping some of us next time, we can participare 18:12:09 I am +1 to this proposal 18:12:11 participate 18:12:14 it would be nice to figure out the hotspot login story and some other items, but hopefully we can 18:12:22 thozza: https://lists.fedoraproject.org/pipermail/devel/2015-June/211282.html 18:12:28 Yes, +1. 18:12:39 thozza: FWIW, the support was overwhelmingly positive. 18:12:44 aestheically i'm in favor of a local resolver even before we consider dnssec 18:12:46 mitr: we definitely want to document anything that needs to be documented 18:12:59 we are still working on some implementation stuff 18:13:05 and also some automated testing 18:13:38 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 mitr: so we proposed some changes to glibc, but there was no response 18:13:57 they are actively ignoring us ;) 18:14:12 so there is currently no way to tell if the server is trusted 18:14:15 thozza: But Carlos is on the Wiki. 18:14:25 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 other than SELinux ensuring that nothing rewrites the resolv.conf 18:15:01 rishi: yes, but in the end, there was no response... although he was included in the initial discussion 18:15:09 upstream is really unresponsive in this 18:15:21 he might just be busy/away... 18:15:25 mitr: In other words, the locally running resolver should be beneficial even if applications do not integrate with it directly. 18:15:50 carlos is pretty busy all the time, yeah 18:15:52 nirik: may be.... we tried to refresh the discussion on the upstream list, but no luck 18:15:59 we will have to do it again 18:16:00 nirik: Unfortunatelly this discussion with upstream is (not) going on at least for one year now. 18:16:34 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 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 but we all know how it goes... so all you can do is keep pushing and try and get some answers. 18:17:45 hey all 18:17:46 nirik: yes, we plan to do that 18:18:16 but we don't think that without the glibc support the feature is useless 18:18:29 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 I am +1 to thedefault local dns 18:18:39 I'm +1 for the record 18:18:47 thozza: is anyone working on getting our docker config to do something sane for this? 18:19:14 pspacek: OK, trusted iff local (modulo Docker?) is a good story. Just write it down :) 18:19:43 "sane" could even be "ignores the local resolver" as long as dns works, as far as i'm concerned 18:19:51 ajax: PJP should be doing it 18:20:00 sweet, good enough for me. +1 18:20:09 I see +8 votes so lets accept this. 18:20:11 we have weekly sync call on Friday, so trying to really get everything done for F23 18:20:13 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 ajax: Docker uses 8.8.8.8 by default if resolv.conf contains only 127.0.0.1. 18:20:51 #agreed F23 System Wide Change: Default Local DNS Resolver (+8 , 0, -0) 18:20:58 thozza: I assume disabling this is just removing dnssec-triggerd ? 18:21:01 pspacek: fair enough. 18:21:28 pspacek: that'll do! 18:21:37 (ie, we should document how to disable for folks that don't want it for whatever reason) 18:21:51 nirik: right 18:22:08 It is enough to remove the dns=unbound from NM configuration 18:22:37 if it is not there, dnssec-trigger is basically ignoring NM dispatcher events 18:22:54 but it would still put 127.0.0.1 in /etc/resolv.conf no? 18:23:08 anyhow, don't mean to hyjack. 18:23:09 nirik: no, if it does, it is a bug 18:23:36 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 they really hardened the policy in F22 vs F21 18:25:13 let's move to the next topic 18:25:45 #topic Next week's chair 18:25:45 any volunteer? :) 18:26:10 I can do next week I guess. 18:26:32 Thanks nirik for volunteering 18:26:50 #info nirik will chair next week's meeting 18:27:05 #topic Open Floor 18:27:38 I have one item. 18:27:54 sure 18:28:47 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 I've not have any time to try and gather people on this. ;( 18:29:17 bleh 18:29:18 so, would anyone else be interested in taking this on? or helping out? 18:29:26 Also, what exactly do we want out of this... 18:29:40 just a password length/strength policy? or something higher level? 18:29:46 ajax: I completely agree. 18:29:58 folks are filing anaconda bugs already for f23 about the current behavior. 18:29:59 Workgroup's need to define their own policy right? 18:30:20 well, except we also don't define any base policy 18:30:21 nirik: By current behaviour you mean the double done? 18:30:36 rishi: I mean no double done 18:30:42 ok, right 18:31:24 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 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 sadly, spins aren't able to do that so they would get the base policy probibly 18:31:36 I don't know how to define a base policy because it seems it doesn't have a target audience / product. 18:31:38 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 Then we can deal with product differences through the existing kickstart mechanisms I guess. 18:32:52 (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 jwb: well, they did provide a way for products to set their own 18:33:40 I like what mitr is saying because it gives a convenient way to skirt around the whole "base policy" issue. 18:33:45 nirik, then i don't see a point in defining anything else. 18:34:05 rishi: That part I don’t particularly like; Workstation isn’t exempt from needing to be secure. 18:34:11 jwb: well, the non products get a default set by anaconda team 18:34:14 that many people don't like 18:34:33 rishi: OTOH without this hypothetical rate limiting, having a truly great base policy may not be possible, so… 18:34:42 nirik, why? spins have kickstarts just like editions... 18:35:01 jwb: it won't work. It has to be installed in the tree that anaconda is running from. 18:35:10 it replaces files in anaconda I think. 18:35:20 mitr: Umm... Workstation doesn't want to be sure? 18:35:23 the products can do that because they have the foo-product branding stuff 18:35:29 *secure 18:35:30 which is pulled in at build time 18:35:47 nirik, that sounds like something the spins could leverage still. 18:35:54 rishi: Workstation is arguing for the loosest requirements IIRC. 18:36:06 jwb: only if we allowed xfce-product packages/branding 18:36:12 s/xfce/whatever/ 18:36:13 why wouldn't we? 18:36:21 they aren't 'products' ? 18:36:24 we should define a base policy, and allow the products to change it 18:36:43 nirik, so? why can't spins have their own branding? 18:37:02 mitr: "loosest" for some, "sanest" for others. I don't think one can cook up a policy out of thin air. 18:37:12 It has to be driven by what the target audience is. 18:37:24 rishi: /me vaguely waves his security credentials around ☺ 18:37:25 Whatmight work for Workstation, might not work for Server. 18:37:31 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 but I predict breakage 18:37:44 rishi: Anyway, side issue 18:37:59 nirik, well, that plays well into my "spins are not worthwhile" gripe i guess 18:38:10 IMO the policy nazi's should butt out and let user's decide their own password quality :) 18:38:21 well, it seems a lot of work for the spins to just override this one thing 18:38:21 leigh123linux, nobody here is a nazi. not helpful. 18:38:44 then we have a default in anaconda that... no one uses? 18:39:07 * jwb shrugs 18:39:18 i think this is not worth doing full stop 18:39:32 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 The first problem is that anaconda folks came up with a set of arbitrary and very strict requirements. 18:39:56 jwb: users should be free to chose themselves 18:40:03 sgallagh, the second problem is that any set of requirements is arbitrary and nobody is going to agree on them 18:40:04 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 leigh123linux: linux might be about choice, fedora is not. take it elsewhere. 18:40:33 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 building a product necessarily requires making decisions on behalf of your consumers 18:41:13 "choice" is not a goal here 18:41:32 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 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 So that (to me) defines an incorrect default 18:42:51 sgallagh: sure. 18:43:17 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 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 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 rishi: That was the stopgap from F22, but the anaconda folks don't like that 18:43:51 Why? 18:43:56 And the UXD people think it's bad UX 18:44:03 The f22 only was a patch only applied to f22 branch. 18:44:29 rishi: "Why" has not been clearly explained (to me) 18:44:35 nirik: That is just a detail. :) 18:44:45 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 sgallagh: Ok. :) 18:45:08 nirik, thanks for taking this initiative 18:45:14 if I can find the time. ;( 18:45:28 nirik: Thanks. I wish I could help, but I'm overcommitted as it is 18:45:40 (see Server SIG meeting minutes...) 18:45:52 sure 18:45:54 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 rishi: I think both 18:46:42 But like I said; I don't have all the detail 18:47:06 It's definitely not discoverable. 18:47:12 (easily anyhow) 18:48:04 any other thing for open floor? 18:48:17 elections reminder 18:49:00 last I looked there was 5 nominations for 4 seats 18:50:47 * rishi has got to leave 18:50:54 See you next! 18:51:09 sure 18:51:20 If there is nothing to discuss then I'll end the meeting in a minute 18:51:23 dgilmore: We require 6 nominations, right? 18:51:32 what? 18:51:49 sgallagh: why ? 18:51:52 sgallagh, I don't see that rule 18:52:22 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 Ah, my mistake 18:52:37 https://fedoraproject.org/wiki/FESCo_election_policy 18:53:06 Carry on 18:55:57 okay let's end the meeting now 18:56:00 thanks everyone for having this meeting. 18:56:01 #endmeeting