15:00:06 <stickster> #startmeeting Fedora Workstation WG
15:00:06 <zodbot> Meeting started Wed Apr  1 15:00:06 2015 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:09 <stickster> #meetingname workstation
15:00:09 <zodbot> The meeting name has been set to 'workstation'
15:00:16 <stickster> #topic Roll call!
15:00:32 <mcatanzaro> Hola
15:00:46 <stickster> o/ :-)
15:00:59 <cschalle_> hola
15:01:15 * jwb is 1/2 here
15:01:15 <kalev> hullo
15:02:01 <stickster> #chair cschalle_ kalev mclasen_ otaylor rdieter_work
15:02:01 <zodbot> Current chairs: cschalle_ kalev mclasen_ otaylor rdieter_work stickster
15:02:10 <stickster> oops
15:02:12 <stickster> #chair mcatanzaro
15:02:12 <zodbot> Current chairs: cschalle_ kalev mcatanzaro mclasen_ otaylor rdieter_work stickster
15:02:14 <stickster> Sorry!
15:02:32 * mclasen_ is here
15:02:38 * otaylor is here
15:02:51 * cschalle_ is here
15:03:10 * stickster notes Ryan is now on BNE time so he won't make it today for sure
15:03:46 * stickster plunges ahead, may be a short session today
15:04:03 <stickster> #topic pwquality changes
15:04:32 <jwb> this is for f23 right?
15:04:34 <stickster> There are actually two subtopics here... One is state of F22 and what needs to be modified to make Workstation do the right thing
15:05:01 <jwb> i think you guys kind of ran out of time for f22.  freeze is in effect
15:05:20 <mcatanzaro> I believe FESCo asked anaconda to revert their changes before freeze, so for F22 we should not need to do anything if I'm not mistaken.
15:05:37 <stickster> Yeah, sgallagh I think can confirm that, mcatanzaro
15:05:43 <mcatanzaro> Or maybe it's a beta freeze exception...?
15:05:58 <jwb> uh... they didn't do that
15:06:20 <sgallagh> They didn't, but it's a blocker bug.
15:06:21 <stickster> #link https://fedorahosted.org/fesco/ticket/1412
15:06:27 <sgallagh> It won't *exit* freeze without being fixed.
15:06:28 <mcatanzaro> Beta blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1191842
15:06:49 <sgallagh> https://github.com/rhinstaller/anaconda/pull/59 should get merged today
15:07:13 <mcatanzaro> "From 2015-03-25 FESCo meeting:
15:07:15 <mcatanzaro> 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."
15:07:25 <sgallagh> That will define the base policy. If Workstation wants something else, it can be overridden.
15:07:41 <sgallagh> But this is what you will get in Beta if you make no changes.
15:07:57 <jwb> mcatanzaro, right, that isn't a revert.  anyway, the effect is similar enough
15:07:58 <stickster> sgallagh: Shouldn't that be '--nostrict' and not '--notstrict' ?
15:08:02 <stickster> sgallagh: See https://github.com/rhinstaller/anaconda/commit/e7e86a23d56bde2b2493d17c99b0781508435993
15:08:08 <sgallagh> stickster: Trust me.
15:08:16 <sgallagh> The code and the commit comment disagree.
15:08:24 <sgallagh> --notstrict is honored by the code
15:08:48 <stickster> sgallagh: Yep, just saw it. The docs were wrong :-)
15:08:55 <sgallagh> bcl is going to correct that in the kickstart docs
15:08:55 <stickster> sgallagh: Thanks!
15:08:56 <kalev> excellent, thanks for making this happen, sgallagh
15:09:02 <stickster> sgallagh++
15:09:18 <stickster> ^ Note you guys can give some karma cookies this way ;-)
15:09:32 <sgallagh> So the remaining question is whether the Workstation product wants to use the base default or tweak it further.
15:10:09 <kalev> sgallagh: what is your recommendation?
15:11:02 <jwb> sgallagh, for f23 not f22, right?
15:11:04 <sgallagh> I wasn't making one. If you folks would prefer something different, I'll help you get that into your productimg package
15:11:17 <kalev> I think we should be fine for now
15:11:18 <sgallagh> jwb: You can do it for F22 with a productimg override file.
15:11:29 <jwb> sgallagh, ngh...
15:11:43 <sgallagh> jwb: I said "can", not "must
15:11:55 <mcatanzaro> Here is my recommendation: https://lists.fedoraproject.org/pipermail/desktop/2015-March/011776.html   <-- minquality should be 1, because anything else misunderstands how pwquality is intended to be used.  minlen should be enforced by pwquality and not anaconda....
15:12:09 <jwb> i don't see it being beta blocker candidate for f22, so i think focusing on f23 is probably better
15:12:18 <rdieter> here, sorry (pulled away @dayjob)
15:12:43 <sgallagh> /me notes that as long as --notstrict is in play, effectively any password will work, just with an extra click to confirm
15:12:50 * stickster would recommend we leave F22 be, since we have the override available. That lets users get what they want without unnecessary confusion. Agreed with jwb
15:13:02 <kalev> yes, I agree too
15:13:21 <mcatanzaro> Yes, for F22, we should just keep the F21 behavior, so there is no urgent need for us to change anything.
15:13:21 <mclasen_> yeah, letting users override is my main concern
15:13:48 <Corey84> would give more time for solid documentation too i'd think
15:13:49 <kalev> sgallagh's pull request above adds the Done button double click override back
15:13:54 <stickster> For f23 what I recall is that most folks (?) wanted to get everything operating under the same pwquality policy. So that's the second subtopic here. :-)
15:13:55 <sgallagh> mcatanzaro: To be clear, this is *not* exactly the F21 behavior. It's the F22 Alpha behavior with an override
15:14:25 <mcatanzaro> sgallagh: OK, thanks. The override being the most important part, though.
15:14:31 <sgallagh> /me nods
15:14:48 <stickster> #agreed The restored override takes care of F22 situation from Workstation WG POV
15:14:53 <Corey84> the override being the (double click okay) correct?
15:14:58 <stickster> Corey84: correct.
15:15:53 <Corey84> as long as there is a clear meaningful are oyu sure  dialog  overrides are fine imo
15:15:58 <otaylor> I'm OK with that approach too - If we change anything for f23, from my perspective, it would be to have an option for workstation to remove the user creation nag
15:16:04 <stickster> #topic F23 pwquality changes
15:16:13 <mcatanzaro> stickster: For F23, to get everything operating under the same pwquality policy, either anaconda needs to (lose the double-click OK and enforce minquality 1 instead of 50 and stop enforcing minlength itself) and gnome-initial-setup needs to start enforcing pwquality 1, OR we must drop pwquality from the PAM stack so that it's not enforced anywhere.
15:16:39 <mcatanzaro> Along with dropping it from the PAM stack, we'd need a couple changes in gnome-control-center.
15:17:06 <Corey84> when did the pwquality 50  get so bloody high ?
15:17:12 <mcatanzaro> FWIW: I think strict enforcement is only reasonable if pwquality starts accepting much weaker passwords than it currently does.
15:17:21 <Corey84> been working on 22 mostly as of late
15:17:29 <stickster> Corey84: This meeting isn't to go back over history, we want to concentrate on what to do for F23.
15:17:50 <stickster> mcatanzaro: That's the point of minquality 1 IIRC
15:18:04 <mclasen_> mcantanzaro: there's also a complication in the control-center where we're not free to ignore the pwquality checks for password changes
15:18:11 <mclasen_> since we're calling out to /usr/bin/passwd for it
15:19:00 <stickster> I'm not really keen on dropping pwquality from the PAM stack. I think it would make more sense for the first solution mcatanzaro mentioned.
15:19:30 <mcatanzaro> stickster: I think pwquality needs to give a nonzero score to much weaker passwords, IMO. This will definitely require pwquality.conf adjustments at the very least.
15:20:50 <kalev> might be something that can be done as a workstation specific config file, similar to what we have for firewalld
15:21:09 <stickster> (a) dropping the double-click shouldn't be a big deal AFAICT; (b) We'd need tmraz to advise on pwquality.conf changes which we could include in our specific config
15:21:11 <Corey84> seems sane
15:21:44 <stickster> currently the stock pwquality.conf ships in libpwquality, but it's marked %config so AIUI we could override it sanely and without stepping on anyone's toes
15:22:01 * stickster shuts up and asks for smarter heads to weigh in here
15:22:07 <mcatanzaro> https://lists.fedoraproject.org/pipermail/devel/2015-March/208845.html <-- my argument that local password strength doesn't really affect security
15:22:51 <rdieter> let's first try to get the standard/default setup acceptable, only resort to workstation-specific config as a last resort
15:23:01 <rdieter> (or are we to a last resort already?)
15:23:58 <stickster> rdieter: I think the issue with an across-the-board default is that Workstation doesn't allow SSH by default, making it different than e.g. Server
15:24:13 <sgallagh> /me notes that nirik has been attempting to start a distro-wide policy discussion
15:24:18 <mclasen_> mcatanzaro: for the 'enable ssh' case we could conceivably do something
15:24:28 <kalev> I think is is something that should be different between server and workstation. A server that by default enables remote logins, should probably get much stricter password checking than a local workstation.
15:24:34 <stickster> sgallagh: Cool, do you have a link I could grab?
15:24:41 <stickster> kalev: right.
15:24:44 <sgallagh> https://fedoraproject.org/wiki/User:Kevin/Draft_Passwordpolicy
15:24:48 <mclasen_> in the sharing panel, when you enable it, remind the user that he needs to have a good password
15:24:55 <stickster> #link https://fedoraproject.org/wiki/User:Kevin/Draft_Passwordpolicy
15:24:59 <mclasen_> or something like that
15:25:11 <mcatanzaro> I would love to see gnome-control-center take you straight to a "set a stronger password" screen when enabling SSH, rather than just a little reminder he will ignore.
15:26:02 <rdieter> stickster: personally, I'd prefer if server wants a more strict setup, let them make things different than the default, rather than the other way around
15:26:10 <mcatanzaro> mclasen_: If pwquality were to reject only very weak passwords, would you be OK with enforcing that in gnome-initial-setup? Otherwise the only solution is to remove pwquality from the PAM stack.
15:26:38 <mcatanzaro> (As I believe we all want a consistent policy between all apps.)
15:26:51 <mclasen_> in gnome-initial-setup, we _can_ ignore pwquality
15:27:09 <mclasen_> since we're not shelling out to /usr/bin/passwd
15:27:23 <kalev> also, again, it might make sense to have pwquality in the PAM stack for server, but not for a local workstation -- again something where we might want to differ in the configuration
15:27:29 <mclasen_> if we should ignore it is another question
15:27:52 <stickster> mclasen_: I think what mcatanzaro is saying is, if we want uniform policy then it would be best not to ignore it.
15:28:11 <mclasen_> well, we're just putting the override back into anaconda to allow ignoring it ?
15:28:16 <mcatanzaro> mclasen_: Yes, that's the status quo, which I do not like because it's inconsistent with gnome-control-center. So really basic principle: either gnome-initial-setup needs to change, or gnome-control-center needs to change. And the only way to change gnome-control-center is to remove the PAM check.
15:28:51 <stickster> mclasen_: That's for this release because we don't have any agreed-on uniform policy. We're talking about fixing that, and then getting all the apps to follow it.
15:29:38 <stickster> So changing g-i-s seems like the right answer to me
15:30:08 <mclasen_> we could change the control-center to always call out to the accountsservice for password changes to get out of the passwd shackles
15:30:11 <striker> Not sure if this can help or not, but I normally make my passwords using this: https://strikerttd.fedorapeople.org/randompass
15:30:17 <mclasen_> it is the way it is now because of 'audit trail'
15:31:21 <mclasen_> which, to be frank, is mostly baloney
15:32:13 <stickster> mclasen_: Would moving g-c-c to use accountsservice bring it into alignment with the overall pwquality policy?
15:32:18 <mcatanzaro> Ideally accountsservice would go through PAM too...? We should fix PAM rather than go around it IMO.
15:32:33 <mclasen_> pam is not fixable, really
15:32:54 <mcatanzaro> stickster: No, that would avoid checking the policy completely. Like g-i-s already does. Note that we're only talking about enforcement; we'll still use it to show strength regardless.
15:33:10 <kalev> mclasen_: even if we could tune the default pam configuration to suit workstation needs?
15:33:47 <mclasen_> we can tune the configuration, but that doesn't fix the api and the limitations it imposes
15:33:51 <kalev> ok
15:34:09 <mclasen_> we have horrible constructions in gdm to work around brokenness of pam
15:34:11 <mcatanzaro> We can "fix" PAM with regard to password strength checks (not with regard to ancient design decisions) by just not performing the check... there is no reason passwd should enforce password strength if control-center does not....
15:34:20 <mclasen_> juggling multiple pam stacks
15:35:20 <mclasen_> right
15:35:43 <mclasen_> so, things you want to be consistent include passwd as well
15:36:10 <mclasen_> realistically, the only way to get that for all the tools is to make the pam configuration do what we want
15:36:20 <mclasen_> not work around it in all the places
15:37:11 <kalev> and i think it's doable, since whereas previously the whole of fedora was constrained to a single configuration, we can now have different configurations between different products
15:37:46 <mcatanzaro> Yes, and the two options are (a) accept weaker passwords, or (b) remove pwquality-pam so there are no more checks. I'm inclined towards (a) but no strong preference. I have to leave the meeting early this week, bye for now!
15:37:52 <stickster> Right, it doesn't mean we have to do something weird like disable pwquality in PAM
15:38:00 <stickster> Thank you for input mcatanzaro !
15:39:10 <stickster> So would people agree that we should consult tmraz to find pwquality.conf settings that achieve what we want, lobby for those settings as the uniform policy, and if that doesn't succeed, we'd like to use those settings as Workstation specific?
15:39:30 <mclasen_> I concur with mcatanzaro. those are the options, and option a) is probably better
15:39:30 <rdieter> agreed
15:39:40 <kalev> sounds like a plan
15:39:45 <mclasen_> also in terms of being acceptable to the security guys
15:40:12 <stickster> *nod
15:40:18 <stickster> Anyone -1 ?
15:41:42 <stickster> The scoring in pwquality.conf is not as transparent as it looks at first blush. kalev, would you be willing to talk to tmraz (unless you have Plenty of Clue[tm] already) ;-) to see how we could get appropriate settings?
15:42:24 * stickster not sure what we all think is right here, but definitely we don't want the byzantine requirements that come along with score >= 50
15:42:55 <kalev> stickster: sure, I can try
15:43:13 <stickster> kalev: Thank you
15:43:58 <stickster> #action kalev work with tmraz to figure out appropriate pwquality.conf settings, may need some input from group on desired strength
15:44:08 <stickster> #topic Maps
15:44:24 <stickster> OK, this topic might be pretty short and sweet, I'm not sure. The last one wasn't as much :-)
15:45:15 <stickster> As Bastien and others noted... the reason Maps wasn't around in previous default was because of buggy behavior that's now fixed. So is there any reason not to have it in the default now?
15:45:31 <kalev> No, that's not true
15:45:42 <kalev> we explicitly removed gnome-maps last cycle
15:46:01 <mclasen_> I'm torn on this - if we include all the good apps on the image, we don't give people a chance to use our awesome software installer
15:46:05 <stickster> kalev: But my recollection is that was because it wasn't working very well and thus not a good thing to put in front of users.
15:46:12 <mclasen_> and we clutter the overview
15:46:26 <kalev> yes, that's exactly how I feel too :)
15:46:45 <kalev> we've always said that the reason we had to install so many apps by default was because we don't have a good app installer
15:47:07 <mclasen_> this is a bit tangled up with the goa thing
15:47:31 <stickster> mclasen_: In that we don't have bits to create accounts on something like OpenStreetMap?
15:47:37 <mclasen_> I think we should look at finding a better approach for that (regardless whether we include maps now or now)
15:48:10 <mclasen_> stickster: there's no editing capability in gnome-maps now, so I don't think you could use such an account for anything ?
15:48:26 <stickster> mclasen_: OK, I obviously don't understand your GOA point then
15:48:54 <stickster> can you illuminate me? :-)
15:48:56 <mclasen_> rishi asked for maps to be included so 'the goa foursquare provider can be enabled''
15:49:05 <stickster> ah
15:49:16 <mclasen_> goa wants to not advertise accounts that have no consumers
15:49:31 <mclasen_> so maps is needed purely because it can consume foursquare accounts
15:49:38 <stickster> Hm
15:50:35 <kalev> maybe a system where apps can say what accounts they know how to consume
15:50:37 <stickster> I guess that brings up an interesting point about capabilities and why not to call out to the software installer for such consumers
15:50:47 <stickster> similar to totem codecs
15:50:49 <mclasen_> I've suggested that
15:50:49 <kalev> and then goa displays the accounts only if there's a known consumer installed?
15:51:01 <stickster> (although that doesn't work that great either, AFAICT)
15:51:15 <mclasen_> there's a slippery slope though - we don't want goa to become a collection of app-specific accounts
15:51:19 <stickster> *nod
15:51:29 <mclasen_> if each provider has only one consumer, there's not much use in having it centralized
15:51:53 <mclasen_> which is why we've been shy about letting apps influence goa like that
15:51:59 <mclasen_> but I think we should revisit that
15:52:27 <drago01> "display only when one consumer is installed" makes sense to me
15:53:47 <stickster> So right now, the situation is that Maps appears in the default install, correct?
15:54:14 * stickster doesn't have a working TC in front of him to check at the moment.
15:54:41 <kalev> yes, hadess added it to the default install
15:56:22 <stickster> So do we want to change that, or not?
15:58:38 <stickster> From my POV, we have plenty of apps out there for the software installer to grab... a better working app... and rishi asking to enable 4sq, without much reason not to (other than that we'd like apps<->GOA interaction to improve upstream)
15:59:05 <stickster> So I'm -1 to change the current situation. Leave maps in. Others?
15:59:19 <otaylor> agree
15:59:51 <stickster> mclasen_: kalev: rdieter: cschalle_: ?
16:00:00 <rdieter> agreed (not strong feeling either way)
16:00:07 <cschalle_> agreed
16:00:10 * stickster supposes voting is kind of overrated here, if we just leave it alone it stays :-)
16:00:12 <mclasen_> ok with me
16:00:17 <kalev> I am fine either way
16:00:24 <stickster> OK, that sounds like agreed to me.
16:00:28 <stickster> #agreed leave Maps in for now
16:00:35 <mclasen_> I'll discuss possible goa changes with rishi
16:01:07 <stickster> OK -- some of us have to vamoose for another meeting, so I'm going to close down here... Thank you all for coming, and please note the new time for next meeting -- Monday April 13, 9:00am US-EDT / 1300 UTC
16:01:26 <stickster> #info Next meeting at new timeslot -- Monday April 13, 9:00am US-EDT / 1300 UTC
16:01:30 <stickster> #endmeeting