=================================== #fedora-meeting: FESCO (2015-03-25) ===================================
Meeting started by paragan at 18:00:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-03-25/fesco.2015-03-25-18.00.log.html . Meeting summary --------------- * init process (paragan, 18:00:02) * #1312 F22 System Wide Change: Replace Yum With DNF - http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF (paragan, 18:01:37) * AGREED: Replace Yum with DNF in F22+ with plan given in https://fedorahosted.org/fesco/ticket/1312#comment:29 but complete it before beta freeze (+5, 0, -0) (paragan, 18:08:23) * LINK: https://fedoraproject.org/wiki/Changes/Harden_All_Packages?rd=Changes/Harden_all_packages_with_position-independent_code does include -z,now (mitr, 18:23:50) * AGREED: Revisit Hardening change next week (paragan, 18:29:46) * #1412 anaconda password change is causing consternation among the user community please review this policy decision (paragan, 18:30:02) * LINK: http://pkgs.fedoraproject.org/cgit/anaconda.git/log/?h=f22 (mitr, 18:38:35) * AGREED: In f22 default back to f21 anaconda password behavior, ask anaconda developers, fedora-release and releng folks to make this change happen before Beta freeze. (+5, 0 ,-0) (paragan, 19:13:08) * ACTION: nirik to work with anaconda developers for anaconda password policy (paragan, 19:16:01) * #1374 F22 Self Contained Change: https://fedoraproject.org/wiki/Changes/DisabledRepoSupport (paragan, 19:16:18) * AGREED: FESCo approved the DisabledRepoSupport Change (+6, 0, -0) (paragan, 19:18:13) * Next week's chair (paragan, 19:18:42) * Open Floor (paragan, 19:20:56) Meeting ended at 19:25:02 UTC. Action Items ------------ * nirik to work with anaconda developers for anaconda password policy Action Items, by person ----------------------- * nirik * nirik to work with anaconda developers for anaconda password policy * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (85) * mitr (71) * paragan (67) * ajax (60) * rishi (51) * thozza (29) * jwb (23) * zodbot (9) * drago01 (8) * jreznik (5) * Corey84 (3) * dgilmore (2) * sgallagh (0) .. 18:00:02 <paragan> #startmeeting FESCO (2015-03-25) 18:00:02 <zodbot> Meeting started Wed Mar 25 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:02 <paragan> #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh 18:00:02 <paragan> #topic init process 18:00:02 <zodbot> Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza 18:00:16 <nirik> morning. 18:00:16 <jwb> hi 18:00:20 <paragan> Hi all 18:00:22 <dgilmore> hi 18:00:26 <mitr> Hello 18:00:30 <dgilmore> I have to run in an hour 18:00:35 <thozza> hi 18:00:58 <paragan> we are missing sgallagh_afk and rishi 18:01:26 <paragan> Okay let's start 18:01:37 <paragan> #topic #1312 F22 System Wide Change: Replace Yum With DNF - http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF 18:01:37 <paragan> .fesco 1312 18:01:40 <zodbot> paragan: #1312 (F22 System Wide Change: Replace Yum With DNF - http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF) – FESCo - https://fedorahosted.org/fesco/ticket/1312 18:02:00 <paragan> dnf developer has given the proposal in https://fedorahosted.org/fesco/ticket/1312#comment:29 18:02:30 <mitr> +1 18:02:32 * ajax waves 18:02:50 <paragan> anyone have any issues with his proposal? 18:03:03 <thozza> paragan: I'm +1 on it. 18:03:11 <nirik> If the yum/dnf folks agree with that plan of action, I don't think fesco should stop them... it's a bit worrying that it is happening now instead of before alpha tho. 18:03:31 <ajax> looks fine to me, +1 18:03:33 <paragan> right this should have happened before alpha 18:04:06 <ajax> i've had fewer issues with dnf in f22 than i've had with yum, tbh 18:04:42 <drago01> actually yum (as in the tool) should go away the libary / apis should be there to give users some porting time 18:04:48 <nirik> well, dnf has it's quirks, but it's the future! and we are just more used to yum's really... 18:04:53 <ajax> i don't think the timing should block the proposal, given how long its taken to get even to this point. 18:05:00 <drago01> I don't see a reason for a "yum-decprecated" command but well ... 18:05:02 <ajax> (talk talk talk) 18:05:13 <nirik> right, unless it doesn't land before beta freeze. 18:06:07 <paragan> Proposal: FESCo approves the plan given by dnf developer for Yum With DNF Change in https://fedorahosted.org/fesco/ticket/1312#comment:29 18:06:13 <ajax> +1 18:06:16 <ajax> (again) 18:06:18 <nirik> sure, +1 18:06:20 <mitr> +1 again 18:06:21 <paragan> I am +1 18:06:50 <mitr> (And please make sure this is done by beta freeze) 18:07:22 <nirik> asap 18:07:29 <paragan> I see +4 votes 18:07:38 <paragan> any more votes? 18:08:03 <thozza> +1 18:08:23 <paragan> #agreed Replace Yum with DNF in F22+ with plan given in https://fedorahosted.org/fesco/ticket/1312#comment:29 but complete it before beta freeze (+5, 0, -0) 18:08:44 <paragan> #topic #1384 F23 System Wide Change: Harden all packages - https://fedoraproject.org/wiki/Changes/Harden_All_Packages 18:08:45 <paragan> .fesco 1384 18:08:46 <zodbot> paragan: #1384 (F23 System Wide Change: Harden All Packages - https://fedoraproject.org/wiki/Changes/Harden_All_Packages) – FESCo - https://fedorahosted.org/fesco/ticket/1384 18:08:56 <ajax> ah, this again 18:09:03 <nirik> fun times. 18:09:10 * nirik reads mitr's comment he just added. 18:09:16 <mitr> Sorry about being so late 18:10:11 <mitr> tl;dr is that I would prefer -z,now on by default (for non-memory-safe languages at least), but it is not a life-or-death issue ☺ 18:10:56 <ajax> from a security perspective i'd probably agree 18:11:17 <ajax> from a performance perspective i think we really need to measure the impact and set about mitigation 18:11:32 <ajax> because it's going to be non-zero 18:11:44 <ajax> and at least on (admittedly dumb) workloads, appreciable 18:11:58 <ajax> what i _don't_ see is the feature owners doing that measurement 18:12:29 <ajax> the 'binary compatibility' thing is maybe not the best way i could have phrased it 18:12:43 <ajax> but basically every other elf system in the world defaults to -z lazy semantics 18:12:51 <ajax> so... kind of a big change 18:13:13 <mitr> So do we, for anything not compiled within Fedora or with redhat-rpm-config installed. Sure, that is fuzzy 18:13:44 <mitr> IIRC there were measurements of PIE impact, but not relro. 18:13:55 <ajax> relro is pretty much free at runtime 18:14:10 <ajax> there's one additional mprotect() before you hit main() 18:14:12 <mitr> isn’t relro what requires -z,now 18:14:18 <ajax> nggh 18:14:19 <ajax> so 18:14:22 <ajax> imprecise terms 18:14:51 <ajax> relro on its own just says "here's a section full of relocations that are const at runtime" 18:15:02 <ajax> in C terms, imagine taking the address of a function in an external DSO 18:15:13 <ajax> that _could_ be const 18:15:49 <mitr> Sure, I was talking about making the GOT/PLT read only. Sorry. 18:15:56 <mitr> (FWIW the older ticket with the measurements was https://fedorahosted.org/fesco/ticket/1113 ) 18:16:06 <ajax> once you make an executable PIE you create a lot more relocations 18:16:12 <ajax> and you'd like them to be read-only 18:17:06 <ajax> so that's where -z now comes in, because it moves those relocations to be approximately as read-only as they'd be were it not PIE 18:18:26 <paragan> ajax, what I get from the comments is following proposal, hope that looks okay 18:18:30 <paragan> Proposal: FESCo approves update to Hardening Change as: default to _hardened_build 0, link executables as -z now and PIE. The _hardened_build now only affects -z for shared libraries. 18:18:59 <ajax> paragan: "default _hardened_build to undefined" actually 18:19:12 <paragan> #undo 18:19:12 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x450b8d0> 18:19:16 <nirik> will that require updating all those specs? 18:19:34 <paragan> Proposal: FESCo approves update to Hardening Change as: default to _hardened_build undefined, link executables as -z now and PIE. The _hardened_build now only affects -z for shared libraries. 18:20:01 <ajax> nirik: enh, "require" is a funny word there 18:20:15 <ajax> presumably everything that's been "fixed" so far for this is already doing %undefined _hardened_build 18:20:24 <ajax> so... they'd still be doing that? 18:20:38 <ajax> we can make that mean whatever we want 18:20:43 <mitr> As a packaging matter, I would prefer that if we have a _hardened_build toggle at all (as opposed to manual overrides), it should control most or all of the functionality; having a _hardend_build toggle that controls the comparatively minor relro aspect but not the major ASLR one would be confusing. 18:20:52 <ajax> the patch i posted makes it mean what paragan proposed there 18:21:02 <mitr> OTOH with the -specs usage we probably do need a toggle 18:21:12 <ajax> the relro thing is effectively already the default anyway 18:21:23 <ajax> like, binutils defaults to it for us, before specs are involved 18:21:26 * nirik was thinking the case where someone did a %if _hardened_build or whatever, but not sure anyone does that 18:22:29 <jwb> i'm distracted and the proposal reads to me like FESCo is saying we aren't defaulting to hardened builds, which is what the feature was requesting. i'll just defer to people paying more attention than me 18:22:42 * rishi is here 18:22:53 <ajax> jwb: it's hair-splitting 18:22:58 <nirik> the problem is that "hardened_build" is covering several different things affecting differnt types of builds. ;) 18:23:14 <ajax> the feature was "harden all builds with position-independent code" 18:23:21 <jwb> originally i thought we approved PIE and PIE only. nothing to do with -znow 18:23:24 <ajax> is that what they actually meant or not? well, who knows. 18:23:46 <ajax> -znow is orthogonal to pic, so. 18:23:50 <mitr> https://fedoraproject.org/wiki/Changes/Harden_All_Packages?rd=Changes/Harden_all_packages_with_position-independent_code does include -z,now 18:24:15 <ajax> mitr: it says that now, yes. was that because they intended it to say that, or because they copied in what the macros _would_ do. 18:24:33 <ajax> (the latter i'm pretty sure) 18:25:09 <ajax> huh, i should give jakub's testcase there a try 18:25:30 <mitr> ajax: You’re right, that table was added later. 18:26:14 <ajax> anyway 18:26:20 <paragan> we are discussing this since last 15 minutes now 18:26:21 <nirik> I'm ok waiting for more test data or just +1ing ajaxs proposal . 18:26:22 <mitr> ajax: That test case is IIRC a completely artifical stress test. It doesn’t hurt to know but I wouldn’t consider this a decisive data point. 18:26:34 <ajax> i've not really had as much time to devote to this as i'd like due to rhel 18:26:40 <nirik> we just need to make sure we do our changes before any gcc mass rebuild. 18:26:57 <jwb> are we even going to have time for a mass rebuild before beta? 18:27:04 <nirik> jwb: no no, rawhide. 18:27:06 <mitr> I guess I’ll sum this up and be -1 at this point; the components that can’t live with -z,now have a workaround, and optimizing the system for running configure scripts seems dubious. 18:27:06 <ajax> jwb: f23 18:27:09 <jwb> oh, right 18:27:14 <jwb> sorry, as i said, distracted 18:27:43 <ajax> but yeah i'd like to come back to this over the next week, and i don't think there's any urgency in the f23 schedule yet 18:27:47 <mitr> But I haven’t had any time to actually help with the workarounds or anything else either 18:28:14 * nirik hasn't noticed any slowness on his rawhide system, but thats a poor measure. :) 18:28:27 <ajax> there's at least the other buglet mentioned there regarding gnat 18:28:27 <nirik> so, yeah, lets let it cook another week? 18:28:39 <ajax> nirik: +1 defer 18:29:21 <mitr> OK, defer 18:29:26 <ajax> i'm happy to get some more representative data once i'm out of rhel rebase stress 18:29:28 <paragan> okay let check this next week 18:29:46 <paragan> #agreed Revisit Hardening change next week 18:30:02 <paragan> #topic #1412 anaconda password change is causing consternation among the user community please review this policy decision 18:30:02 <paragan> .fesco 1412 18:30:04 <zodbot> paragan: #1412 (anaconda password change is causing consternation among the user community please review this policy decision) – FESCo - https://fedorahosted.org/fesco/ticket/1412 18:30:28 <drago01> mitr: "configure scripts" ? wouldn't this affect anything that execs multiple binaries in a short time like "make" ? 18:30:29 <nirik> so, anaconda can now adjust it's policy... 18:30:34 <paragan> Anaconda developers have added default password policy in anaconda -> https://github.com/rhinstaller/anaconda/commit/8f24eeaedd7691b6ebe119592e5bc09c1c42e181 18:30:46 <paragan> Products can implement their own policy by including a modified copy of https://github.com/rhinstaller/anaconda/blob/f22-branch/data/interactive-defaults.ks in their product.img -- drop it into /usr/share/anaconda/ and it will overwrite the default. 18:30:48 <mitr> drago01: configure scripts have a much larger overhead-to-useful-code ratio than compiling 18:31:18 <rishi> mitr: Don't configure scripts also compile random code to test the compiler? 18:31:18 <mitr> Looking at that interactive-defaults.ks, with the --strict, it _doesn’t_ actually implement what FESCo has asked for, or am I mistaken? 18:31:29 <nirik> so, on this one I'd say we should also defer and see if we can get all the products to agree to as few different policies as possible? 18:31:29 <drago01> mitr: I can't parse that 18:32:03 <ajax> i kinda don't care what the defaults do if the product kickstart can override it 18:32:03 <nirik> mitr: we can set whatever policy we want and/or let products set their own 18:32:11 <drago01> mitr: its not about "configure scripts are important" but "configure scripts are slow because $foo" ... "other uses cases do $foo and will be affected to" 18:32:12 <paragan> I am not sure if all product groups should be following the same password policy. 18:32:12 <drago01> o 18:32:13 <mitr> drago01: Things like (sed 's/^ //') are essentially millions of instructions to edit a few bytes of memory 18:32:16 <ajax> and there's --nostrict so 18:32:33 <rishi> We are having overlapping discussions. :/ 18:32:53 <drago01> rishi: oh sorry didn't notice that the topic changed 18:32:57 <nirik> on configure: benchmarking welcome, we don't need to discuss that here. 18:32:58 <mitr> nirik: Well, except for non-product? 18:33:29 <drago01> nirik: (you missed the point as well) 18:33:34 <mitr> And fundamentally I very much agree with some people in that thread, that there should be only one policy. If pwpolicy is a thing, it should affect the installed system. 18:33:43 <paragan> I see adamw have emailed to all product groups about this password policy rules. 18:33:59 <rishi> nirik: I spoke with Kalev about the Anaconda change. It appears that we (as in Workstation) have what we need to relax the password policy. 18:34:04 <nirik> drago01: sorry... 18:34:05 <rishi> So in that sense the change is OK. 18:34:11 <thozza> I think that what FESCo asked can be implemented in the products using the change made in anaconda 18:34:16 <mitr> I would say Defer, but the beta freeze is next Tuesday. 18:34:21 <nirik> rishi: sure, but if we can get everyone to agree to ONE POLICY thats better. ;) 18:35:04 <jwb> i don't think that's realistic 18:35:09 <rishi> nirik: Agreed. But strictly speaking that is outside the scope of what we asked from Anaconda. 18:35:15 <jwb> cloud wants to use ssh keys and not passwords at all 18:35:15 <nirik> sure. 18:35:35 <nirik> cloud doesn't run the installer... 18:35:47 <thozza> can we use the same policy as for F21 for all products in F22? 18:36:03 <jwb> by default? 18:36:07 <jwb> maybe 18:36:10 <nirik> if we can get them all to agree. 18:36:16 <rishi> Now the ball is in the WGs' court, not Anaconda's. 18:36:33 <jwb> but getting it coordinated and approved by Server and Workstation before then seems a stretch 18:36:35 <thozza> I thought we want to fall back to the F21 state for F22 18:36:43 <thozza> until some policy is prepared 18:36:49 <nirik> jwb: adamw has sent out an email to try and do this... it might well be possible 18:37:00 <jwb> what was asked them to do was allow the 'double done click' functionality 18:37:00 <nirik> thozza: all we agreed to was to readd the 'double done' 18:37:06 <mitr> Proposal: go back to anaconda and ask them to implement exactly what https://fedorahosted.org/fesco/ticket/1412#comment:37 has asked for; AFAICS that hasn’t happened and _we don’t have time_. 18:37:07 <jwb> afaik, they didn't do that and did this instead? 18:37:13 <thozza> nirik: sure 18:37:42 <paragan> afaik they don't want to change upstream code 18:37:44 <mitr> We can continue to have the pwpolicy discussion for F23 of course. 18:37:53 <nirik> mitr: ? 18:37:54 <thozza> mitr: I think it is possible also with the change they made 18:38:04 <mitr> paragan: so IIRC the plan was to patch it in f22, which, looing at git log, didn't happen. 18:38:22 <nirik> They said that they would re-add it, but in a local to fedora way. 18:38:30 <nirik> that upstream defaults would not change 18:38:35 <jwb> perhaps there's a subtle language issue here 18:38:35 <mitr> http://pkgs.fedoraproject.org/cgit/anaconda.git/log/?h=f22 18:38:35 <nirik> thats what this is? 18:38:36 <paragan> right instead they given choices to implement password policies 18:38:58 <jwb> they said it would have to be carried as a patch. nobody ever said who was creating said patch 18:39:14 <ajax> childish. 18:39:25 <ajax> like the world's stupidest game of "i'm not touching you!" 18:40:05 <jwb> could be they just forgot too 18:40:13 <thozza> can we just use what anaconda is using except --strict (use --nostrict) instead which would bring back the double click 18:40:16 <thozza> ? 18:40:18 <nirik> anyhow... 18:40:49 <mitr> Sorry, the git log above is not really representative because anaconda is just rebasing tarballs 18:40:50 <paragan> so what we want to propose here, fallback to old double click password acceptance or implement password policies 18:41:19 <thozza> paragan: the double click can be implemented using --nostrict 18:41:24 <nirik> I'm not sure of the details (we need sgallagh_afk who has actually tested stuff for server), but I would say: 18:41:50 <nirik> set a default policy back to the f21 one, working groups can override 18:42:14 <thozza> nirik: that's what I said basically... so I agree 18:42:28 <nirik> but the ramp is short. 18:42:31 <rishi> Ok, so pwpolicy has --nostrict flag. 18:42:34 <mitr> Proposal: anaconda to switch the default as requested previously for F22, for all products and non-products, using whatever mechanism they find appropriate, in whatever package they find appropriate, by F22 beta freeze. 18:42:46 <paragan> I am not sure if the rules they have given in that commit, can be used to created f21 policy by product groups 18:42:46 <nirik> mitr: -1 18:43:05 <mitr> I'm not excited to go looking for new ways to package that kickstart in $something now, and someone to do it. 18:43:25 <nirik> mitr: that ordering people to do work for us where we know they will not be thrilled to do so. Setting up for failure. 18:43:37 <nirik> sgallagh was testing this yesterday for server. 18:43:51 <rishi> nirik: Agreed. 18:44:04 <nirik> but the f22 build doesn't have this yet. 18:44:08 <mitr> nirik: We have already done that three weeks ago; if we do it at all, then we need to follow up or enforce. Or we can just plain stop doing that and make these meetings shorter :) 18:44:10 <rishi> mitr: I am reading https://github.com/rhinstaller/anaconda/commit/8f24eeaedd7691b6ebe119592e5bc09c1c42e181 ... 18:44:10 <nirik> and rawhide was crashing on him 18:44:27 <rishi> mitr: It seems we have the necessary framework to restore the F21 behaviour. 18:44:35 <nirik> right. 18:44:47 <mitr> rishi: Framework, perhaps. Actual packaging desiign, people to impelment such design, and _time_, not. The freeze is on Tuesday. 18:44:48 <jreznik> yep 18:45:11 <jreznik> but still doable 18:45:29 <jreznik> and everything is better than double click from UX perspective 18:45:39 <nirik> we are not getting rid of double done. 18:46:17 <rishi> mitr: We can just ask the WGs to use a policy that is exactly the same as the F21 behaviour. 18:46:22 <paragan> hm so defer this ticket again? 18:46:31 <mitr> paragan: No time 18:46:32 <jwb> nirik, uh... 18:46:37 <jwb> it's already gone 18:46:48 <jreznik> it's gone for good 18:46:51 <paragan> right beta freeze is coming 18:46:53 <jwb> we asked for it to be added back. it isn't added back 18:46:56 <jwb> so? 18:46:57 <rishi> jwb: Gone? Double done is gone? 18:46:58 * nirik sighs. 18:47:00 <nirik> no. 18:47:12 <rishi> So what is this --nostrict thing then? 18:47:14 <nirik> It is not added back currently. 18:47:18 <mitr> rishi: Yes it is gone in the configuration that is being used at this very moment. 18:47:22 <nirik> however, they have given us a way to do so 18:47:35 <rishi> mitr: nirik: Right. 18:47:36 <nirik> it's up to us to do so by adding a small %anaconda section to the kickstarts we use 18:47:52 <nirik> or I suppose yell at them and ask them to scrap all this and just re-add double done 18:47:55 <rishi> So we can just use a config that mimics F21. 18:48:18 <nirik> rishi: yes... 18:48:51 <rishi> Basically, I don't want to antagonize the Anaconda folks too much. 18:48:51 <nirik> --nostrict --minlen=6 --minquality=1 --nochanges --emptyok 18:49:40 <paragan> I still not sure what are we concluding here 18:49:51 <rishi> As long as we can reasonably do whatever we want, which at this point is getting the F21 behaviour back. 18:49:58 <rishi> nirik: Right. 18:50:33 <thozza> can we ask them to carry the patch for the default configuration of options they introduced for F22? 18:50:42 <thozza> to mimic the F21 behavior... 18:50:46 <thozza> I mean anaconda 18:51:17 <thozza> why should we ship it in a separate package? 18:51:19 <rishi> And on top of that, ask the WGs to not change the behaviour because now they can do that in their kickstart. 18:51:25 <thozza> sure 18:51:31 <nirik> rishi: why? 18:51:52 <nirik> thozza: we could ask, but they didn't want to change the defaults... so not sure they would be receptive. 18:51:57 <mitr> rishi: That seems unnecessary. 18:52:02 <rishi> Umm... don't we want F22 to retain the F21 behaviour? 18:52:33 <rishi> Atleast that is what https://fedorahosted.org/fesco/ticket/1412#comment:37 says. 18:52:38 <jwb> nirik, i see. i was confused because the UI work was done in a commit before the one bcl linked to 18:52:40 <nirik> all we wanted was the double done back. ;) 18:52:51 <mitr> nirik: Well #1191842 is a beta blocker 18:52:57 <thozza> nirik: they can keep the defaults in rawhide and upstream 18:53:05 <nirik> mitr: good point. 18:53:45 <mitr> nirik: As a matter of principle, “upstream disagrees” is no way to make a consistent distribution. I just don’t buy that at all. 18:53:46 <nirik> thozza: well, we could ask. 18:53:49 <rishi> nirik: Yeah, but now we have the possibility that a product change the policy to something else. 18:54:05 <rishi> At the end of the day, the question is: "what does the user see". 18:54:31 <mitr> rishi: If a product thinks they have a good basis for a different policy, and enough time and interest to implement this, I don’t currently see a good reason to stop them. 18:54:52 <nirik> mitr: well, this is a bigger conversation really... I mean when we have a upstream that doesn't do what we want, normally we have a set of maintainers that adjusts upstream for us, but we really don't have that in some cases. 18:54:55 <rishi> mitr: Ok., so in that case, everything is perfect now. No? 18:55:21 <mitr> rishi: No becaususe if a product doesn't think so or doesn’t have time and interest we are in a broken situation. 18:56:00 <rishi> mitr: Can't the product just use: 18:56:01 <rishi> --nostrict --minlen=6 --minquality=1 --nochanges --emptyok 18:56:06 <rishi> as nirik said ? 18:56:20 <nirik> sure, but then all the nonproduct things will still have the anaconda defaults. 18:56:22 <mitr> So…? Do we have a volunteer to figure out what kickstarts, where and how need adjusting, and do so, so that I can +1 them and we can move on? If not, please let 18:56:28 <mitr> ’s kick this back to anaconda. 18:56:35 <mitr> Or are there any other options we could be pursuing? 18:56:37 <rishi> nirik: You mean the spins? 18:57:00 <nirik> spins, atomic images, arm appliances, the other billion things we are making now. 18:57:05 <nirik> netinstall isos 18:57:22 <rishi> nirik: Ok. I see the point now. 18:57:30 <thozza> is there any common package/place to include the defaults? I mean common for all spins, etc... 18:57:37 <nirik> mitr: what exactly do you want to ask anaconda folks? can you form a proposal? 18:57:38 <rishi> In that case, I think it is reasonable to ask Anaconda to change the default to mimic F21. 18:57:42 <ajax> spin-kickstarts.git, yes 18:57:59 <nirik> many of the items in the spin-kickstarts use common stuff and include... 18:58:01 <mitr> nirik: I have formed two above; I suppose the second one, perhaps toned down by someone who is not as annoyed as I am. 18:58:20 <rishi> Unless we can osomehow verride it for the spins, atomic images, etc.. 18:58:34 <nirik> I don't know enough about the setup to say. 18:58:44 <nirik> as I noted sgallagh was looking into it. 18:58:45 <mitr> thozza: IMHO libpwquality would be appropriate but that is again getting into design discussions we don’t have time for. 18:59:00 <paragan> Should we wait to see what product WG's are concluding on how to use this new password policy or we want to decide on this today? 18:59:18 <mitr> paragan: Wait till when? 18:59:30 <nirik> I am ok waiting a week to see if we can come up with something based on this anaconda framework. 18:59:34 <paragan> not sure say next week 18:59:34 <mitr> nirik: for the record: 18:59:36 <mitr> Proposal: anaconda to switch the default as requested previously for F22, for all products and non-products, using whatever mechanism they find appropriate, in whatever package they find appropriate, by F22 beta freeze. 18:59:44 <mitr> paragan: The freeze is Tuesday next week, again. 18:59:54 <nirik> yes, but as you noted this is a blocker bug. 18:59:54 <ajax> mitr: +1 19:00:00 <thozza> mitr: +1 19:00:09 <mitr> +1 for the record 19:00:10 <rishi> paragan: As far as I can see this isn't about the WGs. 19:00:17 <thozza> they now have the mechanism they implemented, so they can use it :) 19:00:29 <rishi> It seems to be about what the non-product things that we have are going to use. 19:00:46 <rishi> mitr: +1 19:00:53 <paragan> rishi, I just thought we are not finding common proposal so hear what WG will say 19:01:40 <paragan> mitr, defaults to f21 password policy in your proposal? 19:02:16 <mitr> paragan: To be more precise, s/as requested previously for F22/& in https://fedorahosted.org/fesco/ticket/1412#comment:37/ 19:02:22 <rishi> paragan: Well, right now, all the WGs can either decide to use the F21 policy, or use their own (mitr and nirik sounded happy about that). The problem seems to be that the non-products don't have a way to override the Anaconda default, which is not what the F21 policy was. 19:02:45 * nirik is again hobbled by not having played with this stuff. 19:02:54 <nirik> it could well be that they can override too in their kickstarts, etc. 19:02:57 <mitr> rishi: For the record I am _not_ happy about what the pwpolicy thing does, but that can be easily enough adjusted for F23 19:04:06 <mitr> (to be specific, the kickstart directives should IMHO affect the installed system) 19:04:07 <rishi> mitr: Out of curiosity, what part of the pwpolicy thing do you not like? 19:04:12 <mitr> ^^ 19:04:18 <nirik> so, that means we want --nostrict to be default in f22 anaconda... right? 19:04:45 <paragan> I am not sure if anaconda developers will be agree to provide double done as they have given way to implement own policies 19:04:45 <thozza> nirik: right 19:04:49 <jreznik> and it does not have to be implemented by anaconda but other teams 19:04:52 <mitr> nirik: As far as my proposal above, I wanted to leave the implementation details up to implementers. 19:04:59 <mitr> nirik: But yes, it seems so. 19:05:02 <jwb> paragan, they provided double done via --nostrict 19:05:34 <mitr> (We are going in this circle for the 3rd or 4th time, aren’t we?) 19:05:35 <rishi> mitr: The kickstart directives don't affect the installed system? Are you talking about things like gnome-initial-setup or gnome-control-center which have their own password UI? 19:05:36 * nirik also notes it could be implemented by fedora-release-nonproduct for nonproducts perhaps. But again, I have not had time to look at implementation details 19:05:52 <thozza> mitr: it seems so :-( 19:06:12 <ajax> i'm trying very hard not to. 19:06:15 <mitr> rishi: AFAICS they affect _nothing_; and they should affect _everything_ the same way the auth directive does. 19:06:19 <rishi> I guess we should first figure out if the non-products can override the default. 19:06:24 <nirik> +0 on the proposal from me, as I don't know that anaconda would be the best place to make this change. 19:06:26 <rishi> That should break the circle. :) 19:06:40 <thozza> we have +4 on mitr's proposal 19:06:53 * rishi re-reads the proposal 19:07:02 <mitr> nirik: The proposal is not claiming that anaconda is the best _place_, only the best _people_ to make it. 19:07:06 * Corey84 joins rishi 19:07:08 <thozza> nirik: it does not say it has to be anaconda 19:07:09 <thozza> ;) 19:07:20 <nirik> mitr: well, I am not sure thats even the case. 19:07:31 <mitr> nirik: That’s fair. 19:07:34 <nirik> if we can make this in fedora-release* the maintainers there would be 19:07:37 <rishi> "whatever package" and "whatever mechanism" seems like the operative words. :) 19:07:53 <Corey84> given the issues anaconda has been facing as of late I say its not but willing to help change that 19:08:28 <nirik> mitr: ok, so 'anaconda' in your proposal was the software, not the anaconda developers specifically? 19:08:53 <mitr> nirik: Sorry, it should have been the developers. 19:08:57 <paragan> Proposal: Ask anaconda developers to provide patch that will give F21 password double done policy in F22 for all products 19:09:05 <Corey84> i'd go +1 if that interpration is correct 19:09:07 <paragan> does above looks similar to mitr proposal 19:09:14 <rishi> nirik: We can add a "whoever" in there for all I care. 19:09:16 <mitr> paragan: s/provide and apply/ 19:09:24 <jwb> Corey84, please don't vote if you are not a FESCo member 19:09:40 <rishi> paragan: Your proposal doesn't cover the non-products. 19:10:26 <mitr> Rewording for clarity: 19:10:28 <mitr> Proposal: Ask anaconda developers to switch the default as requested previously for F22 in https://fedorahosted.org/fesco/ticket/1412#comment:37 , for all products and non-products, using whatever mechanism they find appropriate, in whatever package they find appropriate, by F22 beta freeze. 19:10:29 <nirik> proposal: In f22 default back to f21 anaconda password behavior, ask anaconda developers, fedora-release and releng folks to make this change happen before Beta freeze. 19:10:34 <paragan> Okay +1 to mitr proposal then 19:11:03 <rishi> I like nirik 's more. 19:11:07 <paragan> actually I was looking for simple text 19:11:17 <mitr> nirik: +1 I guess, it’s a collective body/collective responsibility either way. 19:11:20 <paragan> I like nirik's proposal 19:11:25 <rishi> Because it includes more people than just "anaconda developers". 19:11:31 <ajax> +1 to whatever makes this a thing we're not talking about anymore tbh 19:11:38 <rishi> ajax: Yeah. 19:11:38 <nirik> ajax: :) 19:11:54 * rishi hands out a few +1s to both nirik and mitr 19:12:02 <paragan> I see we are about to get nirik proposal approved but who is going to work on this? 19:12:09 <thozza> mitr: +1 19:12:21 <nirik> I can try and shepard it... 19:12:36 <nirik> hopefully sgallagh has already done the heavy lifting. 19:12:42 <nirik> do we want to allow products to override tho? 19:13:08 <paragan> #agreed In f22 default back to f21 anaconda password behavior, ask anaconda developers, fedora-release and releng folks to make this change happen before Beta freeze. (+5, 0 ,-0) 19:13:34 <mitr> nirik: In principle, I think so; at this moment, I’d say preferably only if it is done by Beta freeze. 19:13:35 <nirik> proposal: products may override password policies from the default. 19:13:48 <nirik> mitr: good point... 19:14:21 <rishi> nirik: I am leaning towards "no" to that since it is quite late, but if some WG really wants something else, then it should be b y Beta freeze. 19:14:31 <mitr> nirik: +1 if that needs to be voted on; IIRC configuration divergences have always been fair game, though I am not sure whether we have an explicit decision to that effect 19:14:42 <nirik> ok, like I said sgallagh was working on it, so he may have something for server by tuesday 19:14:59 <nirik> mitr: also good point. so, lets just say they can and move on. 19:16:01 <paragan> #action nirik to work with anaconda developers for anaconda password policy 19:16:09 <rishi> nirik: mitr: FWIW when I tried to relax the policy in gnome-control-center, I was hampered by pam. So not sure how easily a product can use its own policy in practice. 19:16:18 <paragan> #topic #1374 F22 Self Contained Change: https://fedoraproject.org/wiki/Changes/DisabledRepoSupport 19:16:19 <paragan> .fesco 1374 19:16:20 <zodbot> paragan: #1374 (F22 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1374 19:16:25 <mitr> rishi: g-c-c should not have its own policy at all, it should be in pwquality. 19:16:27 <nirik> rishi: well, for install... but yes, there's still nothing unified. ;( 19:16:46 <nirik> +1 this self contained change. 19:16:55 <paragan> +1 19:16:56 <mitr> +1 to the disabled-repo support (and annoyed about the packaging tools split) 19:17:24 <thozza> +1 19:17:24 <ajax> +1 to this change 19:17:54 <paragan> cool 19:17:58 <rishi> +1 19:18:13 <paragan> #agreed FESCo approved the DisabledRepoSupport Change (+6, 0, -0) 19:18:39 <paragan> I think we are done with tickets :) 19:18:42 <paragan> #topic Next week's chair 19:18:42 <paragan> any volunteer? :) 19:18:55 <ajax> have we rotated everyone through yet? 19:20:17 <mitr> I can do it next week. 19:20:38 <paragan> mitr, thanks 19:20:45 <paragan> #note mitr to chair next week 19:20:56 <paragan> #topic Open Floor 19:20:56 <paragan> anything for open floor? 19:21:20 <ajax> nothing from me. 19:21:26 * nirik has nothing 19:23:18 <paragan> If there is nothing to discuss then I'll end the meeting in a minute 19:25:02 <paragan> thanks everyone for having this meeting. 19:25:02 <paragan> #endmeeting -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
