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