13:00:45 <stickster> #startmeeting Fedora Workstation WG
13:00:45 <zodbot> Meeting started Mon Jul 20 13:00:45 2015 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:48 <stickster> #meetingname workstation
13:00:48 <zodbot> The meeting name has been set to 'workstation'
13:01:18 <stickster> #chair juhp mcatanzaro rdieter_work
13:01:18 <zodbot> Current chairs: juhp mcatanzaro rdieter_work stickster
13:01:27 <stickster> #topic Roll call!
13:01:35 <mcatanzaro> Hi
13:02:18 <stickster> o/
13:02:57 <otaylor> Here!
13:03:02 <stickster> #chair otaylor
13:03:02 <zodbot> Current chairs: juhp mcatanzaro otaylor rdieter_work stickster
13:03:12 <stickster> juhp: rdieter_work: You guys here?
13:04:12 <stickster> *sigh
13:05:18 <stickster> I'm going to plunge ahead and see what we can get done.
13:05:30 <stickster> #topic Thanks and gratitude
13:05:48 <stickster> mcatanzaro: Thank you for running the meetings the past several weeks while I was at Summit and vacation.
13:06:11 <mcatanzaro> stickster: You're welcome!
13:06:17 <stickster> Facilitating online may not be glamorous but it helps keep the ball rolling, so muchas gracias :-)
13:07:29 <stickster> mcatanzaro: Hey, I saw your additional priority item and I agree we want to discuss that. I'd like to have quorum so we can reach some decision
13:07:43 <stickster> mcatanzaro: Are you OK with holding off for a few minutes to see if we can get enough people?
13:07:48 <mcatanzaro> stickster: Sure
13:07:52 <stickster> OK. In that case...
13:08:07 * mcatanzaro is uncertain what counts as a quorum under our rules, or if we even have rules for that.
13:08:22 <stickster> Quorum is usually considered to be a simple majority in Fedora meetings... so 5 for us
13:08:29 <mcatanzaro> OK.
13:08:34 <stickster> Right now I think we only have you, me, otaylor
13:08:44 <mcatanzaro> mclasen said he would be late.
13:08:56 <stickster> Right, we'll hold on for him and I'm hoping someone else will show before too long
13:09:22 <stickster> #action stickster follow up on mailing list about switching meeting times, since this is the second time in three meetings we've had trouble reaching quorum
13:09:46 <jwb> i'm here but i'm not in the wg :)
13:09:52 <stickster> jwb: Always nice to have you :-)
13:10:10 <stickster> Let's move on to something reasonably #info-y
13:10:14 <stickster> #topic Flock presence
13:10:37 <stickster> #info stickster, cschaller, and mclasen should be present at Flock (and jwb)
13:10:45 <stickster> Who else is attending from the group?
13:11:06 * mcatanzaro has TBH yet to figure out where in the world Flock will be.
13:11:15 <stickster> http://flocktofedora.org
13:11:15 <jwb> Rochester, NY
13:11:22 <stickster> ^
13:11:27 <otaylor> I'll be there
13:11:37 <stickster> #info otaylor also attending
13:11:50 <otaylor> (I grew up in Rochester, parents still live there)
13:12:22 <mcatanzaro> It runs over the end of GUADEC, so unlikely that I will attend. :(
13:12:49 * mclasen sneaks in
13:13:09 <stickster> #chair mclasen
13:13:09 <zodbot> Current chairs: juhp mcatanzaro mclasen otaylor rdieter_work stickster
13:13:31 <stickster> mclasen: FYI we're missing quorum (again?) but we're going to try to proceed anyway
13:14:12 <mclasen> I'll send regrets for cschalle - he's in Norway (I think ?)
13:14:13 <stickster> mclasen: Just looking into who else is coming to Flock from the WG besides you, me, Owen, Christian, and jwb
13:14:22 <stickster> mclasen: Correct, I expected he'd be missing
13:14:42 <stickster> Oh!
13:14:54 <stickster> #info ryanlerch also attending, thanks to some last-minute budget wrangling
13:15:11 <mclasen> thats a long trip
13:16:08 <stickster> mclasen: Correct, but we try to get the whole Fedora Engineering team to that one event each year
13:16:32 <mclasen> sure, makes sense
13:16:38 <stickster> OK, let's go to mcatanzaro suggested topic
13:16:51 <stickster> #topic BZ 1241310 -- password strength
13:17:13 <stickster> mcatanzaro: Care to summarize this for us? I see there was some recent bug activity too.
13:17:33 <mcatanzaro> stickster: The summary is that we no longer know what we're doing. :D
13:18:05 <mcatanzaro> The pwquality developer is changing pwquality to allow somewhat weaker passwords, but we're no longer sure if that's desirable or not.
13:18:26 <mcatanzaro> Jasper's biggest complaint is that pwquality just seems to be really bad at rating passwords.
13:19:31 <mcatanzaro> My biggest goal remains to make the password enforcement behavior consistent between g-i-s and g-c-c, and at the end of the day that means we choose to enforce password strength for both or neither. Maybe mclasen has thoughts on this?
13:19:41 <stickster> mcatanzaro: It seems to be something of a misunderstanding that very slight differences in the score are meaningful in libpwquality terms
13:19:43 * Corey84 in late
13:20:28 <stickster> #info Some libpwquality changes are being made to allow weaker passwords, but it's not yet clear this solves Workstation case.
13:20:34 <mclasen> as long as the control-center shells out to passwd for changing passwords, that means we essentially tie ourselves to whatever policy the commandline tools end up using
13:21:07 <otaylor> It does seem like there should be a system policy for what is acceptable for local user passwords
13:21:07 <stickster> mclasen: It looks like there are a few changes coming in that would help, like being able to set up /etc/security/pwquality.conf.d/NN-foo.conf
13:21:10 * mclasen main concern is that we don't want to have users stuck at the password page, unable to come up with a password that passes the checks
13:21:29 <otaylor> it shoudn't be part of the code of individual tools
13:22:15 <Corey84> could there be a  toggle  in the  password spoke for a  slightly  less secure one with a  tooltip stating so?
13:22:15 <mclasen> the individual tools mainly have to get involved with the policy because they want to show strength/quality feedback
13:22:46 <stickster> otaylor: Also agreed... if there's a systemwide conf everyone can rely on, which we can override with a Workstation policy, that *should* work fine to solve our issues
13:22:46 <mclasen> and if we implement that ourselves, we risk saying 'looks like a cool password' in the ui, only to have the backend code not accept it
13:22:54 <randomuser`> Corey84, if you do that, you have to be very explicit about what's "strong" and what's "weak but acceptable" and it can easily be a lengthy explanation
13:23:23 <Corey84> fair enough
13:23:44 <Corey84> or possibly a  link to the docs  for pwquality?
13:23:54 <mcatanzaro> Well the discussion is not about how to display weak passwords (we have a bar that makes it pretty clear what weak is), but whether to allow the user to set weak passwords at all. For what pwquality decides is weak.
13:24:10 <mcatanzaro> Corey84: I think if we need to link to pwquality docs, we have failed to create a decent UI. :)
13:24:12 <stickster> Corey84: Linking a first-time Fedora user (developer or not) to some highly esoteric docs in e.g. the installer or control center isn't really helpful
13:24:16 <stickster> Yeah, mcatanzaro++
13:24:47 <stickster> If it's done right, someone should be able to type in a password and be assured that if it meets our intended minima, it should be accepted.
13:24:58 <randomuser`> a tooltip with "hints for creating a strong password" would be helpful without needing to be comprehensive
13:25:14 <mclasen> do we want to have different criteria for local vs ssh passwords ?
13:25:40 <Corey84> I  mainly use  server and Desktop  how  tight is  pwquality on WS
13:25:41 <otaylor> mclasen: how would that work? Isn't a "ssh password" determined when someone enables sshd?
13:25:41 <cmurf> If there's a minimum quality, there needs to be descriptive text integrated in each UI to tell the user how to produce a password of minimum quality.
13:25:47 <stickster> mclasen: That's a tougher question. Currently IIRC Workstation doesn't enable sshd.service by default.
13:26:04 <mclasen> otaylor:  yes, basically - you'd have to warn the user to set a stronger password when he enables sshd
13:26:09 <mcatanzaro> But we have UI for enabling "Remote Access" (sshd) under the Sharing panel.
13:26:24 <Corey84> could look at the  Centos ks on  github for  a  lockdown of   ssh pass
13:27:20 <Corey84> mcatanzaro,  can't  local and  sshd  use separate params  from pwquality tho?
13:27:25 <mcatanzaro> The fact is, when you enable sshd, you open yourself up to distributed password guessing attacks; your password really does need to be very strong. Best practice is to not allow password authentication at all, but we don't have any UI for setting up an RSA key to use.
13:27:31 <Corey84> just set a higher min for sshd
13:27:51 <mcatanzaro> Whereas, if you do not have sshd enabled, your password could be "fred" and nobody would ever guess it.
13:28:16 <stickster> mcatanzaro: Maybe we need a page in yelp so that when a user enables sharing (sshd), they get some sort of caution about password strength
13:28:20 <mcatanzaro> Corey84: I think we should find a way to do that.
13:28:21 <Corey84> have the user drop to tui for  ssh-keygen then  OR   not allow it if min qual not meet
13:28:37 <randomuser`> IMO allowing a weaker password because sshd is not on by default is an arbitrary and potentially confusing departure from fedora-global defaults
13:28:44 <stickster> drop to tui == doesn't sound good to me
13:28:53 <mclasen> stickster: I think it would have to be a prompt in the sharing panel that allows you to set a stronger password right there
13:28:56 <Corey84> randomuser`,  +1
13:29:03 <stickster> mclasen: That might be just the thing.
13:29:11 <Corey84> requires in sharing i'd think
13:29:13 <mclasen> unfortunately, I think we don't have a  way to check the quality of the current password, short of asking the user to enter it again
13:29:33 <otaylor> mclasen: could theoretically save whether its' strong or not
13:29:37 <mclasen> we could of course store that information in a lookaside
13:29:39 <stickster> mclasen: Yup, I was assuming that too
13:29:46 <mclasen> 'strong-enough-for-ssh'
13:29:59 <mcatanzaro> randomuser`: I don't think "fedora-global defaults" can be useful for both the case where remote access is enabled and the case where it isn't, since the requirements for password strength are very dramatically different. I agree with mclasen that a prompt in the sharing panel would be ideal.
13:29:59 <randomuser`> it would be preferrable to not have to document"if $edition; then $behavior" situations
13:30:03 <Corey84> didnt someone just add similiar  feature for luks in the kickstart.py    can't we  look at  intregrating that
13:30:28 <mcatanzaro> otaylor: Where would the saving take place? g-i-s and g-c-c? It could be stale. accountsservice? That's not even used by g-c-c, let alone passwd.
13:30:33 <stickster> randomuser`: We're trying to avoid the situation where docs would have to cover the minima at all
13:30:42 * randomuser` nods
13:30:46 <mclasen> mcatanzaro: best would be a pam module
13:30:51 * Corey84 nods
13:31:03 <mclasen> that could cover all avenues to password setting
13:31:04 <mcatanzaro> mclasen: accountsservice bypasses PAM, though, I believe.
13:31:14 <Corey84> but its pam already  calling pwqaulity
13:31:30 <randomuser`> I'm not saying I'm going to jump on documenting this - just pointing out that disparity between editions for this provides potential for confusion and frustration
13:31:34 <Corey84> isnt?
13:31:48 <juhp_> sorry I am so late
13:32:01 <mcatanzaro> juhp_: Welcome!
13:32:08 <stickster> Yay, quorum ;-)
13:32:13 <juhp_> :)
13:32:33 <Corey84> would it be posible to  only have  accountservice  used if  in "expert mode" or  non sshd
13:32:41 <mcatanzaro> randomuser`: TBH, the reason we have different products is so that they can have different defaults. Nobody is confused and frustrated that we don't have sendmail anymore.
13:32:43 <Corey84> defaultign to pam instead
13:32:48 <stickster> So... given the above discussion... What action do we want to take to improve the Workstation situation, in light of the libpwquality changes coming?
13:33:42 <Corey84> personally id say  default to  pam with a  lookaside for accountservice  if no ssh
13:34:21 <otaylor> stickster: the libpwquality changes probably get things low enough to be secure for ssh without making people bang there head into the wall, but I think we probably need to be even lower if we want a smooth experience
13:34:39 <mclasen> stickster: I'd like to suggest that we should disable password auth for ssh by default
13:34:51 <stickster> otaylor: That would say to me, we want to produce an /etc/security/pwquality.conf.d/10-workstation.conf
13:34:54 <mcatanzaro> I would say (1) change g-i-s and g-c-c to prevent the user from setting a password if pwquality reports a password strength error, (2) consider changing the pwquality defaults if need be, (3) consider what to do for SSH.
13:34:54 <Corey84> ^ +1  id be down for that
13:35:17 <jwb> mclasen, how do you envision getting keys onto a machine?
13:35:52 <Corey84> NFS or  local store ---would preseumably require pre setup
13:36:07 <jwb> that doesn't make sense
13:36:11 <Corey84> at least as a temp for setup
13:36:22 <stickster> I'm scratching my head at that, too.
13:36:31 <mcatanzaro> Corey84: accountsservice is just a nice D-Bus API to change account settings; we really should use it regardless, it's just an implementation detail that it bypasses PAM. But currently we don't use it in g-c-c for password changing for that reason.
13:37:21 <Corey84> have the user create them  prior to  setting up  WS  and  have on say usb  import from there
13:37:31 <stickster> This sounds way complicated.
13:37:42 <Corey84> its not really
13:37:47 <stickster> So you have to *have* a Fedora system to set up Fedora Workstation?
13:37:49 <otaylor> it's a workstation, so we can assume the user *does* have local access. It's not a server sitting in a room somewhere that was just kickstarted
13:37:51 <mcatanzaro> If we disable password access via SSH, we will probably need help from designers as to how to help users set up an SSH key when remote login is enabled in the Sharing panel.
13:37:56 <stickster> otaylor++
13:37:56 <zodbot> stickster: Karma for otaylor changed to 1:  https://badges.fedoraproject.org/tags/cookie/any
13:38:10 <mcatanzaro> We're not going to expect the user to do anything prior to installing Workstation.
13:38:11 <mclasen> jwb: dunno, really - searhorse has some ui support for exporting and syncing keys, but I've never really explored or used that
13:38:59 <mcatanzaro> mclasen: seahorse is in severe need of redesign, and it's very buggy.
13:39:03 <randomuser`> this sounds like a UI/UX problem, and it seems logical to me to provide settings targeted towards acceptably secure ssh until the UX problem is solved
13:39:10 <stickster> mclasen: seahorse also has a creating keys module
13:39:13 <stickster> including ssh
13:39:16 <Corey84> or allow a  OTP pass auth for ssh with a forced  reset post  first boot
13:39:54 <mcatanzaro> The SSH key creation might even be embeddable in applications via gcr, if we're lucky.
13:40:35 * stickster still not seeing the actual plan in the chatter here :-)
13:40:37 <jwb> ssh key creation doesn't seem like a problem here.  you aren't going to need to create an ssh key to ssh into the machine you're currently using.
13:40:53 <Corey84> ^
13:40:59 <jwb> the problem is when you have existing keys and want them included on a new machine you just installed
13:41:26 <Corey84> or if we assume it  connected to some other system or  server  (already in play)  use it to  grab  keys
13:41:46 <jwb> which is far more likely.  i mean, if you only have _one_ machine, ssh doesn't even really come into play here.  what are you going to use to ssh into it?
13:41:56 <mcatanzaro> We would need UI to create the key in the Sharing panel, UI to import keys, and docs on how to do it for other operating systems.
13:42:07 <mcatanzaro> Anyway, we are getting far afield of the original discussion.
13:42:10 <stickster> jwb: In which case you're unlikely to turn on sshd.
13:42:17 <jwb> stickster, right.
13:42:17 <mcatanzaro> And it would be nice to start talking about Atomic today.
13:42:35 <jwb> you want to talk about a complete redo of the foundations of workstation in 18min?
13:42:39 <jwb> bold :)
13:42:57 <stickster> jwb: My fault for putting it on the agenda ;-) but I didn't want it to lie fallow
13:43:36 <stickster> Anyhoo... The problem of making the password quality work correctly isn't orthogonal to the sshd issue, but this seems impossible to solve as a single initiative with the design work required
13:44:22 <otaylor> For the password discussion, it seems like maybe we need one or more plans written down to concretize what we're trying to decide on
13:45:45 <stickster> otaylor: I think you're probably right, but that's what I'm trying to get laid out here in meeting notes ;-)
13:45:59 <stickster> What if the initial phase consisted of:
13:46:13 <stickster> 1. drop-in .conf file for pwquality
13:47:04 <stickster> 2. (if needed?) g-i-s and g-c-c changes to align them to use same stack
13:47:16 <stickster> 3. testing of a reasonable set of passwords we'd want to succeed, to see that this works properly as expected
13:47:34 <mcatanzaro> We should do 2. for sure. For 1. and 3. there is the question of what is the reasonable set of passwords we'd want to succeed.
13:47:55 <stickster> 4. a warning popup in Remote Sharing cautioning about password strength (while we work on sshd issues longer-term)
13:47:57 <otaylor> Basic question determining course of action: is strong enough for ssh to strong for usability?
13:48:04 <stickster> mcatanzaro: Of course, that's TBD
13:48:19 <stickster> otaylor: Yeoman's guess is, "yes."
13:48:20 <mcatanzaro> otaylor: If you can remember your SSH password, I'd say it's likely not strong enough, so yes.
13:48:58 <stickster> mcatanzaro: Well, I don't know that I'd go that far. I have an easy to remember SSH passphrase but it's 49 characters long.
13:49:01 <corey84__> I always  use  keys personally
13:49:49 <stickster> mcatanzaro: otaylor: I think we can agree that *initial* usability might be harder with sshd-strength passphrases
13:49:50 <mcatanzaro> That is a slight exaggeration of course but you need some strategy (which most users won't have) to remember a secure passPHRASE. That's what stickster does I'm sure.
13:50:41 <stickster> otaylor: So does the answer to your question above affect the plan I wrote out?
13:50:41 <Corey84> 54 characters passPHRASE her for most things just not  ssh
13:50:56 <otaylor> I'd agree that we need to permit quite weak local passwords to allow a wide range of users of the workstation
13:51:05 <stickster> agreed
13:51:47 <Corey84> locally  sure with the understanding that has  potential security issues
13:51:55 <Corey84> not  for  sshd ever th imo
13:52:10 <stickster> juhp_: Do you want to add to this discussion?
13:52:27 <otaylor> stickster: My main issue with your list above, is that I think that 4. isn't good enough, if it's along the lines of "You know need strong passwords. Make sure you do that. Bye!"
13:52:59 * otaylor types homophones likes crazy < 7am local time
13:53:18 <mclasen> I think that 4. will have to be worked out in more detail, probably with some designers in the room
13:53:22 <stickster> otaylor: Heh. I liked mclasen's implication -- present a dialog to reset the password if needed
13:53:29 <stickster> otaylor: Or yeah, whatever, design.
13:53:41 <juhp_> stickster, mm, I kind of joined in the middle of the discussion but listening carefully
13:54:34 <stickster> Key point being, we want *something* to alert or at least help the user to ensure acceptably strong remote-in credentials
13:54:37 <juhp_> I use passwords with ssh
13:55:18 <rtcm> I wonder if we even need the ssh toggle in g-c-c. I mean the panel is called "sharing" and non-tech savy users don't even understand what that toggle does
13:55:19 <stickster> juhp_: Many of us do. I'm not prescribing the solution here, just that we don't want to solve everything at once unless necessary
13:55:31 <mcatanzaro> Corey84: I don't see any security issues with allowing weak local passwords. They don't provide any technical protection against anything, really.
13:55:37 <juhp_> stickster, right
13:55:48 <stickster> mcatanzaro: Corey84: Let's not get in to a high-level discussion of security principles ;-)
13:55:49 <mcatanzaro> rtcm: I've found that toggle to be very convenient. I have no clue how to set up sshd any other way, tbh. :p
13:55:58 <Corey84> stickster,  ok
13:56:15 <randomuser`> rtcm, I think people that want sshd are probably going to look for how to enable the service, not look for a button stashed in a sharing ui :P
13:56:20 <mcatanzaro> stickster: Well, that is relevant, it is justification for allowing the weaker passwords we want to allow.
13:56:30 * randomuser` says while mcatanzaro proves him wrong
13:56:33 <mclasen> mcatanzaro: systemctl start sshd
13:56:58 <mcatanzaro> mclasen: :p
13:57:16 <stickster> OK, so with the edit of (4) Make a plan for the sshd enablement that makes sense in short-term, along with a longer-term plan we could follow on for e.g. F25
13:57:25 <stickster> would folks agree with that?
13:57:46 <stickster> and (4) to be detailed on-list
13:57:57 <mcatanzaro> +1
13:58:20 <stickster> This discussion took a lot longer than planned, but if people could +1 really quickly, I'll make one short reminder and we'll be done for today
13:58:23 * mclasen agrees
13:58:25 <mclasen> +1
13:58:26 <otaylor> +1 [not sure if we *need* two plans]
13:58:26 <stickster> (or -1 if that's how you feel) :-)
13:58:32 <stickster> otaylor: Perhaps not
13:58:53 * stickster +1 if that wasn't clear
13:58:55 <stickster> juhp_: ?
13:58:58 <juhp_> sounds okay to me
13:59:21 <stickster> #agreed on initial password plan (see log for full details)
13:59:42 <stickster> mcatanzaro: Can I ask you to pull out that summary, and maybe add some detail around (4) we could use to keep discussion moving on list?
13:59:51 <mcatanzaro> stickster: Sure
14:00:12 <stickster> #action mcatanzaro Pull the plan to the list and kickstart discussion on item 4 for sshd strength
14:00:15 <stickster> Thank you sir!
14:00:20 <stickster> crap, it's the top of the hour.
14:00:28 <stickster> #topic F23 Alpha freeze coming!
14:00:45 <stickster> FREEZE IS COMING! So we'll pull that discussion out in #fedora-workstation after this ;-)
14:00:48 * stickster has to run
14:00:51 <stickster> #endmeeting