Tuesday, 2017-02-28

*** mancdaz has quit IRC00:00
*** ctracey has quit IRC00:00
*** spotz has quit IRC00:00
*** waj334 has quit IRC00:01
*** dstanek has quit IRC00:01
*** comstud has quit IRC00:01
*** mjb has quit IRC00:01
*** chris_hultin|AWA has quit IRC00:02
*** melwitt has quit IRC00:02
*** zeus has quit IRC00:02
*** odyssey4me has quit IRC00:02
*** jmccrory has quit IRC00:02
*** waj334 has joined #openstack-keystone00:05
*** ctracey has joined #openstack-keystone00:05
*** mancdaz has joined #openstack-keystone00:07
*** zeus has joined #openstack-keystone00:07
*** chris_hultin|AWA has joined #openstack-keystone00:07
*** mjb has joined #openstack-keystone00:08
*** zeus is now known as Guest6872400:08
*** chris_hultin|AWA is now known as chris_hultin00:08
*** melwitt has joined #openstack-keystone00:09
*** dstanek has joined #openstack-keystone00:09
*** ChanServ sets mode: +v dstanek00:09
*** jmccrory has joined #openstack-keystone00:09
*** spotz has joined #openstack-keystone00:09
*** comstud has joined #openstack-keystone00:09
*** melwitt is now known as Guest6807600:09
*** odyssey4me has joined #openstack-keystone00:11
*** chris_hultin has quit IRC00:12
*** Guest68076 is now known as melwitt00:12
*** wolsen has quit IRC00:13
*** wolsen has joined #openstack-keystone00:14
*** darrenc has quit IRC00:16
*** jamielennox|away is now known as jamielennox00:16
*** darrenc has joined #openstack-keystone00:17
*** lamt has quit IRC00:17
*** chris_hultin|AWA has joined #openstack-keystone00:18
*** chris_hultin|AWA is now known as chris_hultin00:18
*** _cjones_ has quit IRC00:24
*** _cjones_ has joined #openstack-keystone00:25
lbragstaddolphm we had a long talk about performance testing at the PTG, but I never captured it in the etherpad (not sure if it was out of session or not)00:25
lbragstaddolphm I remember us talking about the advantages and disadvantages of locust, and that led to defining what we need in a performance testing tool00:25
lbragstaddolphm do you remember what those things were?00:25
lbragstadI'm working on it here fwiw - https://etherpad.openstack.org/p/pike-ptg-keystone-testing00:25
*** _cjones_ has quit IRC00:30
*** edmondsw has quit IRC00:33
*** edmondsw has joined #openstack-keystone00:33
*** dstanek has quit IRC00:34
*** dstanek has joined #openstack-keystone00:34
*** ChanServ sets mode: +v dstanek00:34
*** hoangcx has joined #openstack-keystone00:36
*** edmondsw has quit IRC00:38
*** edmondsw has joined #openstack-keystone00:51
*** dave-mccowan has joined #openstack-keystone00:55
*** Guest68724 is now known as zeus`01:02
*** zeus` is now known as zeus01:03
*** zeus has joined #openstack-keystone01:03
*** ravelar has quit IRC01:04
*** martinlopes has quit IRC01:05
*** zhugaoxiao has quit IRC01:06
*** Administrator_ has quit IRC01:06
*** edmondsw has quit IRC01:08
*** guoshan has joined #openstack-keystone01:12
*** pramodrj07 has quit IRC01:14
*** MasterOfBugs has quit IRC01:14
*** martinlopes has joined #openstack-keystone01:21
*** thorst has joined #openstack-keystone01:26
*** dave-mccowan has quit IRC01:30
*** edmondsw has joined #openstack-keystone01:31
openstackgerritRon De Rose proposed openstack/keystone-specs master: Add API key credential  https://review.openstack.org/43876101:36
*** dave-mccowan has joined #openstack-keystone01:37
*** namnh has joined #openstack-keystone01:39
*** browne has quit IRC01:44
*** gyee has quit IRC01:45
*** adrian_otto has quit IRC01:51
*** liujiong has joined #openstack-keystone01:51
*** dave-mccowan has quit IRC01:59
*** edmondsw has quit IRC02:00
*** rderose has quit IRC02:01
*** chris_hultin has quit IRC02:04
*** chris_hultin|AWA has joined #openstack-keystone02:06
*** chris_hultin|AWA is now known as chris_hultin02:06
openstackgerritMerged openstack/keystone master: Exclusively use restore_padding method in unpacking fernet tokens  https://review.openstack.org/43820702:29
*** rderose has joined #openstack-keystone02:41
*** martinlopes has quit IRC02:42
*** thorst has quit IRC02:44
*** thorst has joined #openstack-keystone02:44
*** rderose has quit IRC02:44
*** rderose has joined #openstack-keystone02:47
*** thorst has quit IRC02:49
*** aasthad has quit IRC02:52
*** martinlopes has joined #openstack-keystone02:58
*** guoshan has quit IRC03:09
*** martinlopes has quit IRC03:10
*** tqtran has quit IRC03:19
*** _cjones_ has joined #openstack-keystone03:20
*** guoshan has joined #openstack-keystone03:28
*** ngupta has joined #openstack-keystone03:31
*** ngupta has quit IRC03:31
*** ngupta has joined #openstack-keystone03:31
*** guoshan has quit IRC03:44
*** thorst has joined #openstack-keystone03:45
openstackgerritJamie Lennox proposed openstack/keystoneauth master: Add an allow_version_hack flag to session and identity plugins.  https://review.openstack.org/43878803:47
*** thorst has quit IRC03:50
breton.цшт 2303:51
breton:(03:51
*** lucasxu has joined #openstack-keystone03:53
*** Dinesh_Bhor has joined #openstack-keystone03:59
*** _cjones_ has quit IRC04:17
jamielennoxmordred, notmorgan: ^04:17
*** _cjones_ has joined #openstack-keystone04:17
*** ngupta has quit IRC04:35
*** lucasxu has quit IRC04:54
*** adriant has quit IRC05:30
*** guoshan has joined #openstack-keystone05:33
*** jaosorior has joined #openstack-keystone05:41
openstackgerritMorgan Fainberg proposed openstack/keystone master: Use pdkfd_sha512 instead of sha512_crypt  https://review.openstack.org/43880805:46
*** rderose has quit IRC05:50
notmorganlbragstad: ^ there is the code fix, please take a look at it and the bug.05:51
*** guoshan has quit IRC06:03
*** guoshan_ has joined #openstack-keystone06:03
*** _cjones_ has quit IRC06:05
*** lamt has joined #openstack-keystone06:26
*** masuberu has quit IRC06:27
*** abhishekk has joined #openstack-keystone06:29
*** gk-1wm-su has joined #openstack-keystone06:33
*** gk-1wm-su has left #openstack-keystone06:33
*** richm has quit IRC06:43
*** thorst has joined #openstack-keystone06:46
*** thorst has quit IRC06:51
*** lamt has quit IRC06:52
*** tqtran has joined #openstack-keystone07:03
*** tqtran has quit IRC07:07
*** phalmos has quit IRC07:08
*** rcernin has joined #openstack-keystone07:11
*** zsli has joined #openstack-keystone07:13
*** tesseract has joined #openstack-keystone07:34
*** ctracey has quit IRC07:35
*** ctracey has joined #openstack-keystone07:36
*** guoshan has joined #openstack-keystone07:39
*** dtroyer has quit IRC07:40
*** dtroyer has joined #openstack-keystone07:40
*** guoshan_ has quit IRC07:41
*** h5t4 has joined #openstack-keystone07:47
openstackgerritColleen Murphy proposed openstack/keystone master: Add instruction to restart apache  https://review.openstack.org/43742307:55
*** gk-1wm-su has joined #openstack-keystone08:12
*** gk-1wm-su has left #openstack-keystone08:12
*** pcaruana has joined #openstack-keystone08:17
openstackgerritJamie Lennox proposed openstack/keystoneauth master: Add an allow_version_hack flag to session and identity plugins.  https://review.openstack.org/43878808:22
*** masber has joined #openstack-keystone08:24
*** zsli has quit IRC08:47
*** zsli has joined #openstack-keystone08:48
*** zzzeek has quit IRC09:00
*** zzzeek has joined #openstack-keystone09:12
openstackgerritAlfredo Moralejo proposed openstack/keystone master: Remove domains *-log-* from compile_catalog  https://review.openstack.org/43887509:33
*** zsli has quit IRC09:36
*** jaosorior has quit IRC09:39
*** jaosorior has joined #openstack-keystone09:40
*** lwiecek has joined #openstack-keystone10:00
*** hoangcx has quit IRC10:10
*** liujiong has quit IRC10:11
openstackgerritColleen Murphy proposed openstack/keystone master: Fix duplicate handling for user-specified IDs  https://review.openstack.org/43889610:21
*** guoshan has quit IRC10:23
*** mvk has quit IRC10:42
*** namnh has quit IRC10:43
lwiecekHello. I am trying to install keystone using a ready openstack-keystone-ansible-role and the keystone gets installed, however playbook fails at step: Ensure service tenant, which is adding service tenant. After investigation, I need to do following steps manually to make it work: 1. Install correct version of pysaml2 in virtualenv (I install 3.0.2, the role installs the newest. 2. I have to make 4 spaces that are missing10:47
lwiecek(in first line after <VirtualHost *:5000>) 3. Logs show that wsgi-module is not loaded properly. It seems that it /var/www/cgi-bin/keystone/main is executed by wrong python. I can manually fix it by entering virtualenv, sourcing keystone admin credentials and running it manually (python /var/www/cgi-bin/keystone/main). I used Ansible 2.2.1.0 (requirements specifies minimum 2.0 version). How can I fix this?10:47
*** thorst has joined #openstack-keystone10:48
*** thorst has quit IRC10:53
*** nicolasbock has joined #openstack-keystone11:09
*** mvk has joined #openstack-keystone11:14
*** richm has joined #openstack-keystone11:14
*** ayoung has joined #openstack-keystone11:21
*** ChanServ sets mode: +v ayoung11:21
lbragstadlwiecek that sounds like something the #openstack-ansible channel would be able to help with11:45
lbragstadlwiecek they are the folks that write and maintain those playbooks11:45
lbragstadnotmorgan awesome - i'll be sure to take a look11:45
*** zeus has quit IRC11:52
*** zeus has joined #openstack-keystone11:54
*** zeus is now known as Guest9124911:54
*** ildikov has quit IRC12:01
*** ildikov has joined #openstack-keystone12:03
*** johnthetubaguy has quit IRC12:04
lwiecekok thank You for answer. I will ask there12:07
*** fungi has quit IRC12:11
*** johnthetubaguy has joined #openstack-keystone12:14
*** Guest91249 has quit IRC12:17
*** fungi has joined #openstack-keystone12:17
dstaneklbragstad: can't sleep?12:22
lbragstaddstanek morning!12:22
dstanekgood morning12:22
lbragstaddstanek i wanted to finish up summarizing the PTG, but I didn't finish it last night12:23
*** zeus- has joined #openstack-keystone12:24
dstanekaye12:27
bretonso in auto-provisioning12:27
bretonwhat role are the users supposed to have in their own prjects?12:28
bretonfor example, what role userA should have in "Dev project for userA"?12:28
lbragstadbreton that's defined in the mapping, if the mapping contains a project it must also contain a role12:28
bretonlbragstad: yeah, i understand. But what should that role be? admin or member?12:29
lbragstadbreton i guess that's up to the deployment, if the deployment is already using the admin_project, then giving 'admin' might not hurt12:29
bretondoes devstack use admin_project?12:30
lbragstadhttps://github.com/openstack-dev/devstack/blob/7a30c7fcabac1cf28fd9baa39d05436680616aef/lib/keystone#L38312:30
lbragstadbreton doesn't look like it - https://github.com/openstack-dev/devstack/blob/7a30c7fcabac1cf28fd9baa39d05436680616aef/lib/keystone#L343-L34712:31
bretonalso12:34
bretonwhat is is_admin?12:34
lbragstadbreton in the token?12:34
bretonin policy.json12:35
lbragstadbreton oh - i want to say that is and old workaround for something12:36
lbragstadbreton i'm not completely sure what12:36
lbragstadI know we have something that take https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L124-L140 into account, but i'm not sure if that's one of them12:37
bretonlooks like for admin token12:38
*** Dinesh_Bhor has quit IRC12:39
*** zeus- is now known as zeus12:41
*** zeus is now known as Guest8399112:41
*** thorst has joined #openstack-keystone12:47
bretonso the problem today in devstack is that if i give user role admin in their own project, they can edit all flavors12:49
lbragstadhmm - that sounds like a nova policy bug12:49
bretoni'll file a report now12:50
bretonlets see how easy it will be to fix with their new policy in code :p12:50
lbragstadi want to say that the nova folks mentioned something about flavors and policy at the PTG - but i can't remember when/where it was12:50
dstanekbreton: they don't have an admin project concept or domain/project admin in nova?12:58
bretondstanek: https://review.openstack.org/#/c/384148 looks like no13:00
breton(why is gerrit giving me 502)13:00
dstanekbreton: i don't know how their stuff works, but maybe it's possible to do something like our cloud policy there13:02
*** edmondsw has joined #openstack-keystone13:05
-openstackstatus- NOTICE: restarting gerrit to address performance problems13:06
*** ChanServ changes topic to "restarting gerrit to address performance problems"13:06
*** dave-mccowan has joined #openstack-keystone13:25
-openstackstatus- NOTICE: ok gerrit is back to normal13:35
*** ChanServ changes topic to "ok gerrit is back to normal"13:35
*** rderose has joined #openstack-keystone13:36
rderoselbragstad: anything you want changed on this one: https://review.openstack.org/#/c/429912/13:38
lbragstadrderose nope - that looks good, stevemar's comment made sense13:40
rderoselbragstad: cool, thx13:41
*** spilla has joined #openstack-keystone13:42
*** ChanServ changes topic to "Meeting Agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Ocata goals: https://docs.google.com/spreadsheets/d/156q820cXcEc8Y9YWQgoc_hyOm3AZ2jtMQM3zdDhwGFU/edit?usp=sharing | Bugs that need triaging: http://bit.ly/2iJuN1h"13:42
-openstackstatus- NOTICE: gerrit is back to normal and I don't know how to use the openstackstaus bot13:42
lbragstadlol13:42
lbragstadI was wondering when our topic was going to come back ;)13:42
*** edmondsw_ has joined #openstack-keystone13:42
*** edmonds__ has joined #openstack-keystone13:43
*** lamt has joined #openstack-keystone13:45
*** edmondsw has quit IRC13:46
*** edmondsw_ has quit IRC13:47
*** lwiecek has quit IRC13:48
*** zhurong has joined #openstack-keystone13:51
*** edmondsw has joined #openstack-keystone13:59
*** edmonds__ has quit IRC13:59
*** openstackgerrit has quit IRC14:03
*** jaugustine has joined #openstack-keystone14:23
*** chlong has joined #openstack-keystone14:31
*** lamt has quit IRC14:37
*** Guest83991 is now known as zeus14:42
*** zeus has quit IRC14:42
*** zeus has joined #openstack-keystone14:42
*** ngupta has joined #openstack-keystone14:45
*** ngupta has quit IRC14:45
*** ngupta has joined #openstack-keystone14:46
*** thorst is now known as thorst_afk14:46
*** edtubill has joined #openstack-keystone14:46
*** lamt has joined #openstack-keystone14:52
*** ravelar has joined #openstack-keystone15:06
*** zhurong has quit IRC15:10
*** chlong has quit IRC15:11
*** lucasxu has joined #openstack-keystone15:15
*** openstackgerrit has joined #openstack-keystone15:18
*** lamt has quit IRC15:27
*** lamt has joined #openstack-keystone15:29
*** davechen has quit IRC15:42
*** davechen has joined #openstack-keystone15:42
*** adrian_otto has joined #openstack-keystone15:42
*** chlong has joined #openstack-keystone15:43
*** ediardo has quit IRC15:44
*** ediardo has joined #openstack-keystone15:46
*** ngupta has quit IRC15:48
*** ngupta has joined #openstack-keystone15:49
*** h5t4 has quit IRC16:00
*** jaosorior has quit IRC16:03
*** rcernin has quit IRC16:08
kukaczhi, we need to synchronize users+credentials from external source to Keystone via API having the password sent in hashed form16:19
kukaczcan that be implemented, or does Keystone API assume the password to be clear text only?16:20
*** ngupta has quit IRC16:20
*** ngupta has joined #openstack-keystone16:20
knikollao/16:23
*** edtubill has quit IRC16:30
*** pcaruana has quit IRC16:34
lbragstado/16:35
dstanekkukacz: keystone will assume clear text and will hash it again16:40
kukaczdstanek: hmm, I'm not sure I understand. are you talking about hashing it for storage in Keystone backend?16:42
dstanekkukacz: yes, keystone will take in passwords and then securely hash them for later use16:43
*** h5t4_ has joined #openstack-keystone16:43
kukaczok, in this request I'm not interested in the form Keystone is storing it16:44
kukaczrather I'm interested in the API communication between external source and Keystone16:44
kukaczsimply said - I won't get cleartext password from the external source16:44
kukaczI will only get some hashed form - not defined yet, we're in a design phase16:45
dstanekkukacz: if you pass your hash as the password for a user then keystone will assume the password is the hash16:45
dstanekkukacz: do you want to reuse that hash in keystone?16:45
kukaczhmm, maybe. I want the users to use their original password when interacting with OpenStack16:46
kukaczbut their password will be set by some external tool and stored in that external identity source16:47
*** aasthad has joined #openstack-keystone16:47
kukacz... from which I'll only get it in some hashed form16:47
dstanekkukacz: the only way that i know of to do that would be to stick it into the database directly and i don't think that's a good idea. there's also no guarantee that we ue the same hashing algorithms16:48
dstanekkukacz: any reason why you don't use an external identity store so you don't have to keep a copy of the password hash in keystone?16:48
dstanekldap, federation, etc.16:49
kukaczyes, federation as I understood from discussion here couple of weeks ago is not so mature in most of the clientside openstack libraries and tools16:50
kukaczand LDAP - we got quite bad experience being so dependent on it with all OpenStack operations16:51
kukaczanytime our LDAP was lagging, it had immediate effect on Openstack requests16:52
kukaczso I consider getting back to sql backend16:53
kukaczbut need to resolve the synchronization16:53
*** agrebennikov has joined #openstack-keystone16:53
*** _cjones_ has joined #openstack-keystone16:57
*** tqtran has joined #openstack-keystone16:59
openstackgerritRichard Avelar proposed openstack/keystone master: Policy in code  https://review.openstack.org/43560916:59
*** tqtran has quit IRC16:59
openstackgerritRichard Avelar proposed openstack/keystone master: Policy in code (part 2)  https://review.openstack.org/43575117:00
openstackgerritRichard Avelar proposed openstack/keystone master: Policy in code  https://review.openstack.org/43560917:00
dstanekkukacz: what are you synchonizing from?17:01
*** mvk has quit IRC17:02
ravelarca17:02
kukaczdstanek: the tool id not decided yet. out of my control. we're in a phase requesting the features17:03
openstackgerritRichard Avelar proposed openstack/keystone master: Policy in code (part 5)  https://review.openstack.org/43575717:04
kukaczmy request for cleartext password sync might be rejected17:04
*** nicolasbock has quit IRC17:04
dstanekkukacz: yeah, i can see what some would have a problem with it. but if it's just your provisioning tools doing the sync then you won't need to keep the real password around for long17:06
openstackgerritRichard Avelar proposed openstack/keystone master: Policy in code (part 4)  https://review.openstack.org/43575517:07
*** browne has joined #openstack-keystone17:07
*** nicolasbock has joined #openstack-keystone17:08
*** ngupta has quit IRC17:09
kukaczdstanek: sure, I'm starting from the most comfortable set of requirements - perhaps not best from security perspective though17:09
*** tesseract has quit IRC17:09
*** ngupta has joined #openstack-keystone17:09
kukaczof course we might switch to a method when the password will be set and synchronized by some frontend tool, being forgotten as soon as the sync completes17:10
dstanekkukacz: it also might be worth researching why your LDAP server was lagging and if you can do any sort of read-only caching17:10
kukaczhm, yes the lagging was resolved. I was not happy with that kind of dependency from a general design point. the LDAP became one of the most critical point of our openstack backend infra17:12
kukaczsimilar to openstack databases17:12
kukaczso it seemed to me easier to care of one such dependency (openstack db) instead of two17:13
kukaczdstanek: but the caching might be a help17:13
dstanekkukacz: sure, that's an architecture decision. just making sure i lay out some options :-)17:14
dstanekkukacz: and i agree about federation being something of a pain. this is something that we are hoping to make better17:14
kukaczregarding the caching - must say I have not explored that much. is there a solution possible to sustain minutes~hours disconnected from LDAP backend?17:14
notmorganlbragstad: going to need to write a back-ported SQL migration for password fields in the DB being way too short17:15
notmorganlbragstad: expect something later today(ish)17:15
lbragstadnotmorgan awesome - thanks for the update17:15
lbragstadnotmorgan do you have a migration for master started?17:15
notmorgannot at all.17:15
notmorganjust saw the fails for the recent patch17:15
notmorganit's because the kfd hashing results in > 128char strings17:16
notmorganhave to look into the string lengths and select an appropriate sized column next17:16
*** ngupta has quit IRC17:20
*** ngupta has joined #openstack-keystone17:20
*** h5t4_ has quit IRC17:22
*** h5t4_ has joined #openstack-keystone17:24
*** thorst_afk is now known as thorst17:27
bretonoh wow, max's coal pizza charged me twice17:33
bretonboth times $1617:33
lbragstadhuh...17:34
* lbragstad remembers to check expenses17:34
dstanekkukacz: in past apps we've used an ldap server for our authentication that was a mirror of our corporate ldap.17:36
dstanekkukacz: IT handled the sync process and we were given our own dedicated pool of ldap servers17:37
notmorganlbragstad: what was the reason for the password truncation code again?17:38
notmorganstevemar, dstanek: ^ cc17:38
notmorgani can't remember17:39
lbragstadI thought it was because of sql column limits?17:39
lbragstadbut i'd have to go dig through the code again17:39
notmorganexcept.. we use a hash functoon17:39
notmorganit should result in the same length password data regardless17:39
notmorgannow, with bcrypt (afaict), anything beyond the 55th character is lost due to the inability to consume that entropy17:39
notmorganbut sha512_crypt... i though that resulted in a simple sha512 hash17:40
notmorganoh.17:41
notmorganFFS.17:41
notmorganits because people were complaining about slow authn17:41
dstaneknotmorgan: i think it was just helping people be lazy....i don't really remember though17:42
notmorgandstanek: yep. "OMG 4096 character passwords are slow to auth"17:43
*** jaugustine has quit IRC17:43
notmorganit's a DOS mitigation issue17:43
notmorganwhich... makes keystone massively less secure.17:43
notmorganwell then...17:43
notmorganjust found the bug17:43
notmorganhttps://bugs.launchpad.net/keystone/+bug/117590617:43
openstackLaunchpad bug 1175906 in OpenStack Identity (keystone) "passlib: long passwords trigger long checks" [High,Fix released] - Assigned to Morgan Fainberg (mdrnstm)17:44
notmorganheck i even wrote code for it.17:44
dstaneknotmorgan: also https://review.openstack.org/#/c/77325/17:44
dstanekbreton: was it that good?17:44
notmorganoh no dolphm did, i just submitted code to gerrit17:45
stevemarlbragstad: dammit, i forgot about expense report17:45
bretondstanek: yep. You were there too17:45
* notmorgan needs to do expense report.17:45
dstanekbreton: i know. i was there twice :-)17:45
lbragstadrderose do we have a spec or bug report for account linking?17:45
lbragstadrderose i assume the api-key stuff is going to be dependent on that17:45
lbragstadi haven't found a bug for it yet17:46
dstaneklbragstad: i think they are orthogonal issues17:46
dolphmnotmorgan: bcrypt can't handle passwords > 55 chars?17:46
notmorgandolphm: it fails to use the entropy beyond 55 characters17:46
notmorgandolphm: so most systems pre-hash down to ~5517:46
rderoselbragstad: hmm... why17:46
notmorganthen do the kdf17:46
lbragstaddstanek i thought we wanted to finish decoupling authentication from user accounts before doing api keys?17:47
notmorgandolphm: this is resolved with scrypt.17:47
rderoselbragstad: the data model supports account linking17:47
lbragstadah - we just don't have a any support for the actual linking yet17:47
rderoselbragstad: yeah, we don't have a way to do via the api17:47
rderoseyet17:47
rderoselbragstad: but with ravelar's patch we will17:48
kukaczdstanek: I'm sure this can work in many scenarios. I'm maybe too conservative :-)17:48
*** ChanServ sets mode: +o lbragstad17:48
notmorgandolphm: bcrypt is still a stronger hashing algo than pbkdf2 as it is easily breakable with GPGPU and ASICs, bcrypt is mostly fast-brutable with FPGAs simpley because ASICs usually do not have enough ram, scrypt is both Memory and CPU intensive (exponentially), which breaks down the FPGA advantage17:48
lbragstadrderose but that won't be the only way to link accounts, will it?17:48
lbragstadthat will only work for federated users and local users, right?17:48
rderoselbragstad: correct17:48
lbragstad(what about linking accounts from LDAP to local users? we currently don't have anything in the pipe for that do we?17:48
rderoselbragstad: I don't think you would need account link between ldap and local users17:49
notmorganthe initial fix for the insecure hashing will be move to pbkdf2, which is better than plain sha512, significantly. In Pike we'll support bcrypt and scrypt. I'll work up a pre-hash if needed for > 55 character passphrases17:49
notmorganfor bcrypt17:49
rderoselbragstad: at least I can't think of a good use case for that17:49
lbragstadwhoa whoa whoa whoa whoa17:50
notmorganand in pike we'll default to bcrypt.17:50
lbragstad... what's @17:50
* lbragstad doesn't move17:50
notmorganlbragstad: Operator17:50
notmorganlbragstad: it means you can ban people from the channel etc17:50
lbragstaduh oh17:50
dolphmlbragstad: it's more like a target on your back17:50
*** ChanServ sets mode: +o notmorgan17:51
notmorgan<-- can do it too17:51
notmorgani just don't have it set to auto-op or auto-voice anymore17:51
rderosenotmorgan: ++17:51
*** notmorgan sets mode: -o notmorgan17:51
notmorganit's mostly the whole I try and hide in the mix of people in the channel17:52
* lbragstad tries pealing of the target17:52
lbragstadoff*17:52
notmorganif you don't want to be opped i can fix it17:52
* notmorgan didn't set it17:52
rderoselbragstad: so ravelar's patch will enable account linking between federated and ldap/local user (depending on your identity backend)17:52
lbragstadnotmorgan it's all good - i expect to be in here all the time anyway :)17:53
rderoselbragstad: and like I said, I don't think their is a need for linking local user to ldap (yet anyway)17:53
dolphmi +O'd lbragstad, and was thinking to change myself and stevemar to +o ?17:53
lbragstadrderose ok17:53
notmorgandolphm: that is typically my view17:53
lbragstaddolphm what's the difference between those/17:53
notmorganlbragstad: auto op17:53
notmorganvs on-demand op17:54
dolphmlbragstad: you'll always appear as the channel op, we can act as backups and manually take op17:54
notmorgan(+o means neededing to ask chanserv)17:54
lbragstadaha - cool17:54
notmorgan+O means chanserv auto sets it for you when you join17:54
* notmorgan doesn't see a need to be op all the time, it has been needed ... 2 times total?17:54
notmorganit does make it easier to change the channel topic, but you could do that anyway by messaging chanserv17:55
notmorgansince cores all have +t17:55
notmorganiirc17:55
notmorganrderose: is not registered with nickserv so i can't giv ehim the super power to change the topic17:56
rderosenotmorgan: what!17:56
rderosenotmorgan: thought I did that17:56
rderoseI'm on it17:56
notmorganhehe17:57
*** henrynash has joined #openstack-keystone17:57
*** ChanServ sets mode: +v henrynash17:57
notmorganalso lbragstad should change the topic to remove the ocata goals...17:58
dolphmnotmorgan: davechen rderose rodrigods are missing17:58
notmorgandolphm: will fix that17:58
dolphmrderose: you might be registered but not authenticated17:58
stevemardolphm: i'd be OK with +v TBH17:58
dolphmstevemar: i was just following notmorgan's lead, but me too17:59
obedmrhey folks, quick question, is keystone officially supporting Python3 or it's still under review/voting?17:59
dstanekkukacz: i'm an engineer :-) i build stufff without regard to operations all the time.17:59
notmorgani just dropped +V as well :P17:59
* notmorgan likes hiding17:59
notmorgandstanek: IVORY TOWER ENGINEERING!17:59
*** lbragstad changes topic to "Meeting Agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Bugs that need triaging: http://bit.ly/2iJuN1h"18:00
dstanekobedmr: part of what i want to do this cycle is make sure that we support python3. right now i don't know that to be the case.18:00
obedmrdstanek: ok, got it, thanks for the clarification18:00
*** ChanServ sets mode: -o dolphm18:00
rderosedolphm: ah18:00
dstanekobedmr: if you use it i'd love to hear your experience. i'm mostly worried about how we'd really deal with more that just ascii.18:01
dstanekobedmr: if you just use ascii then you'd be all good18:01
notmorgandolphm: i set -O on you and doing it on steve, you both have +o still18:01
notmorganso you can /msg chanserv op #openstack-keystone <your nick>18:01
notmorganif needed18:01
obedmrdstanek: ohh, I see, sure, I'll share the experience, thanks18:01
*** ChanServ sets mode: -o stevemar18:03
*** ngupta has quit IRC18:04
*** ngupta has joined #openstack-keystone18:05
*** chlong has quit IRC18:06
*** jaugustine has joined #openstack-keystone18:13
*** henrynash has quit IRC18:14
*** ngupta has quit IRC18:14
*** ngupta has joined #openstack-keystone18:14
*** henrynash has joined #openstack-keystone18:19
*** ChanServ sets mode: +v henrynash18:19
*** agrebennikov_ has joined #openstack-keystone18:27
*** agrebennikov has quit IRC18:28
*** agrebennikov__ has joined #openstack-keystone18:28
*** henrynash has quit IRC18:29
*** agrebennikov_ has quit IRC18:32
*** agrebennikov_ has joined #openstack-keystone18:33
*** lucasxu has quit IRC18:34
*** agrebennikov__ has quit IRC18:35
*** thumpba has quit IRC18:40
openstackgerritRichard Avelar proposed openstack/keystone master: Extend User API to support federated attributes  https://review.openstack.org/42644918:43
*** henrynash has joined #openstack-keystone18:45
*** ChanServ sets mode: +v henrynash18:45
openstackgerritRichard Avelar proposed openstack/keystone master: Policy in code  https://review.openstack.org/43560918:53
dstaneklbragstad: quota discussion in -dev19:02
*** henrynash has quit IRC19:05
*** lucasxu has joined #openstack-keystone19:06
*** lucasxu has quit IRC19:08
*** thumpba has joined #openstack-keystone19:10
*** thumpba has quit IRC19:10
bretonoh well, max's pizza refunded the $1619:11
*** henrynash has joined #openstack-keystone19:13
*** ChanServ sets mode: +v henrynash19:13
*** henrynash has quit IRC19:23
*** chlong has joined #openstack-keystone19:25
gagehugobreton: thats good19:27
lbragstaddstanek that makes sense to me19:32
lbragstaddstanek does that change our stance on project/domain tags?19:32
lbragstaddstanek we will still need those, right?19:32
lbragstadwe just won't be using them for limits19:32
*** lucasxu has joined #openstack-keystone19:45
dstanekamazon is killing me19:50
gagehugoAWS S3 seems to be having issues19:53
gagehugolbragstad I thought the limits would need to be k/v?20:00
dolphmgagehugo: just a bit :P20:00
lbragstadgagehugo yep20:03
*** henrynash has joined #openstack-keystone20:04
*** ChanServ sets mode: +v henrynash20:04
notmorganuh20:04
notmorganrderose, lbragstad, dstanek, dolphm: so...20:05
dstaneklbragstad: you were thinking about notmorgan's solution for code options20:05
notmorganif i need to change the length of a column...20:05
notmorganhow the heck am i supposed to do that with the no-downtime upgrade thing20:05
dstaneknotmorgan: what will mysql do if you just resize as part of the expand?20:06
notmorgandstanek: lock the table afaik20:06
notmorgandstanek: and cause issues if you're actively trying to read20:06
dolphmnotmorgan: create a new column, migrate data over, drop old column?20:06
notmorgandolphm: ok password is going to get stupid ugly then20:07
dstanekpassword_220:07
notmorgan128char is not enough space20:07
dstanekpassword_second_try20:07
*** h5t4_ has quit IRC20:07
notmorgandstanek: i want to just break this no-downtime-upgrade and say "sorry, this is a bad feature you're demanding"20:07
notmorganRDBMS does a poor job of this20:07
notmorganit works a lot better with the NoSQL dbs.20:08
*** belmoreira has joined #openstack-keystone20:08
notmorganbecause at this point i am looking at a backport story that is extremely ugly and having to fix past migrations too.20:08
notmorganbasically pbkdf2_sha512 results in a 130character hash20:09
dstanekwould you have to fix past migrations? can't use a placeholder?20:09
notmorganand scrypt (future looking) can be upwards of 1500 characters.20:09
notmorganno, can't because this is back to mitaka20:09
notmorganand if we "fix" mitaka and passwords are migrated (data migrations) to the new table20:09
notmorganit would fail if the column (old) size is > 12820:09
notmorganso need to use the placeholders *and* fix old migrations20:10
dstaneknotmorgan: that's a lot of suckage20:12
notmorgandstanek: yep. and then add in the no-downtime upgrades and needing to tack in code for N and O for basically "password_2" column20:12
notmorganbecause changing a table definition is not "safe".20:13
dstaneknotmorgan: can you use placeholders for M, N and O - and have them know to look for the size before they resize? so basically the same migration with several different filenames20:13
*** agrebennikov_ has quit IRC20:13
notmorgandstanek: it nope, since the migration M->N in migrate_repo does the data migration20:13
notmorganit's a lot of duplicated work and has to be in both places20:13
* notmorgan sighs.20:14
notmorganthe other option is we say "screw it" and don't backport the change in hashes20:15
notmorganand just issue an OSSN that says "sorry, this isn't being backported, we know it is insecure" because you need the values from the db to brute force it20:15
*** harlowja has quit IRC20:15
notmorganit doesn't fix Pike uglyness needing multiple password columns20:15
*** harlowja has joined #openstack-keystone20:16
notmorganbecause the db abstraction is weird.20:16
*** adrian_otto has quit IRC20:16
* notmorgan somewhat wishes for the days of being the only one running an application so changes like this can be planned/staged in a way that doesn't need to be "universal" for a ton of various environments20:17
notmorgandstanek: i just don't know what the best way forward is atm.20:21
notmorgandstanek: i prefer a full backport, but this might be difficult enough that it's not worth it20:22
notmorganok. i 'm going to just exempt this from the restriction because 20-60seconds of delay [and no data loss, we're expanding the table] is worth it for security20:36
notmorganit's not like we're changing data types here.20:36
notmorgandstanek, rderose, dolphm: ^20:36
*** mvk has joined #openstack-keystone20:37
* notmorgan conversed with some MySQL experts on this before making that decision20:37
dolphmnotmorgan: keystone will not be able to claim the zero downtime tag for the entire release, then20:41
notmorgandolphm: then the tag is poorly written20:42
notmorganit doesn't require a downtime.20:42
notmorganit is minimally invasive and might cause slower auth, and a short window of no user-creation20:42
dstaneknotmorgan: where did the 20-60 number come from?20:43
notmorgantalking w/ some mysql folks20:43
notmorganit should be very narrow unless the password table is exceptionally large20:43
notmorgansince it is alter column 128 length -> 256 length20:44
notmorganerm 25520:44
notmorganit doesn't even change page utilization20:44
dolphmnotmorgan: performance degredation is allowed by the zero-downtime tag, but not by zero-impact upgrades20:44
dolphmwhich is a more difficult, subsequent tag20:44
notmorgandolphm: for security fixes, i'd say ditch zero-impact20:45
notmorganin fact, i would never ever ever apply for zero-impact20:45
dolphmbut if auth fails, even due to a reasonable client-side timeout, then that's downtime20:45
*** chris_hultin is now known as chris_hultin|AWA20:45
notmorganit is stupid.20:45
notmorganit should cause an internal copy of the db20:45
notmorganbut not prevent reads20:45
notmorgansince it's innodb20:45
notmorgandolphm: anyway i still think the whole no-downtimeupgrade with the way we're approaching is is insane.20:46
notmorganand poorly designed and poorly implemented20:46
notmorgan(keystone specific)20:46
dstaneknotmorgan: in what way?20:46
rderosenotmorgan: wow, tell us how you really feel20:47
rderose:)20:47
notmorgantriggers to begin20:47
notmorganall the reasons we discussed when it was implemented20:47
dstaneknotmorgan: yeah, but that doesn't impact what you are doing20:47
notmorganit does if we do zero-impact20:47
notmorganand if dolphm is worried about auth failures and i have to do the rotating tables, it does20:47
*** lamt has quit IRC20:47
dolphmno project is ready to pursue zero-impact, yet20:48
*** lamt has joined #openstack-keystone20:48
*** chris_hultin|AWA is now known as chris_hultin20:49
notmorganso ... the question is do we need password.password and password.password_2_because_we_have_security_issues (<-- no real table name, but indicative of the reason we're doing this)20:50
notmorganif that is the case, i'm not sure i actually have the time to do a whole series of backports for this and might just punt this to an OSSN instead of OSSA20:51
notmorganand only fix master20:51
notmorgansimply too much to do.20:51
notmorganit does mean all past releases of keystone have an insecure password hash algorithm since it's not PBKDF2/bcrypt/scrypt20:53
notmorganbut it is no different than what we've dealt with until now20:53
dolphmnotmorgan: what bug number is this?20:54
notmorganoh crap. bigger issue, if we use pbkdf2 we can't write to the old location, we have to re-hash it as sha512_crypt for old keystones *wince*20:54
notmorganbecause new keystones would update the hash to something verifyable by old keystones20:55
dolphmthat's just rolling upgrades, nevermind zero-downtime20:55
notmorgandolphm: yep20:55
notmorganmeans sha512_crypt has to be supported for the <roll> window20:56
notmorganwhat is the roll window20:56
notmorgan1 cycle?20:56
dolphmnotmorgan: yes20:56
notmorgan(for writing both sha512_crypt and bcrypt)20:56
* notmorgan sighs.20:56
dolphmand only during the expand and migration phases20:56
notmorganhttps://bugs.launchpad.net/keystone/+bug/1668503 and https://bugs.launchpad.net/keystone/+bug/154304820:56
openstackLaunchpad bug 1668503 in OpenStack Identity (keystone) pike "sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing" [High,In progress] - Assigned to Morgan Fainberg (mdrnstm)20:56
openstackLaunchpad bug 1543048 in OpenStack Identity (keystone) "support alternative password hashing in keystone" [High,In progress] - Assigned to Morgan Fainberg (mdrnstm)20:56
notmorgansha512_crypt is the bigger issue20:57
dolphmerr, actually, only after the migration phase and before the contract phase20:57
notmorganand moving to pbkdf2_sha512 is the most backportable answer20:57
notmorganbcrypt and scrypt cannot be backported20:57
notmorgancontinuing hashing with sha512_crypt is *really* not good, as it provides very little to next-to-zero protection for bruteforcing the hash even with 10k rounds on modern platforms20:58
notmorganpbkdf2 at least requires ASIC, FPGA, or GPGPU type cracking most of the time20:58
notmorganand bcrypt/scrypt narrow that further20:58
*** gyee has joined #openstack-keystone20:59
dolphmare you somehow planning to re-encrypt passwords during the upgrade?21:00
notmorganyou cannot re-encrypt hashes21:00
dolphmright...21:01
*** ngupta has quit IRC21:01
notmorganthe plan was on password change, new hashing is used21:01
notmorganso an operator could force all passwords to be changed.21:01
dolphmnotmorgan: i'm not sure i understand the proposal in the bug... why keep the same default as today?21:01
notmorganor just wait.21:01
*** ngupta has joined #openstack-keystone21:01
*** jaugustine has quit IRC21:01
notmorganso, what we need to do is going forward, hash passwords securely21:01
notmorganbut still allow auth for users that have old passwords21:02
notmorganrecommendation is to force a password change across the board if you use keystone for passwords21:02
notmorganthe thought was: all updates -> new hashing, fall back on old-hash-verify as needed21:03
*** ngupta has quit IRC21:03
*** ngupta has joined #openstack-keystone21:03
dolphmexpand (new pbkdf2 column), no migration, no contraction. new code writes to new password column and, as applicable, nulls old password values.21:03
notmorgansince you can tell what hash was used based on the ident ($scrypt$/$b2[ab]$/$6$)21:03
notmorganold keystones could not auth then21:04
notmorgansince old keystones don't understand pbkdf221:04
notmorganor scrypt/bcrypt21:04
notmorganpasslib is smart, but not *that* smart. it requires the user to identify the hasher used21:04
dolphmnotmorgan: so, new code writes to both columns for an entire release?21:04
notmorganin two different password formats21:05
notmorganhash-formats.21:05
notmorganif we support rolling upgrades21:05
notmorganwhich, i might add, is not fixing the issue at all21:05
notmorgansince the password would still be hashed in the db insecurely21:05
notmorganuntil we stop writing it in the old-format21:06
notmorganand backporting new config options is mostly a no-no21:06
dolphmnotmorgan: correct, but it's fixing a long term issue in the long term21:06
notmorganfrom a security perspective, if the db is exposed, expect your passwords to be crackable from the hashes.21:07
notmorganwith sha512_crypt21:07
dolphmtoday?21:07
notmorgantoday21:07
dolphmnotmorgan: so, if i send you a sha512_crypt ciphertext, you can send me back the plaintext in the near future?21:08
notmorgansome of the big data breaches are only realatively safe because they used bcrypt vs something less secure.21:08
*** abhishek_k has joined #openstack-keystone21:08
notmorgandolphm: if i setup jack the ripper or similar tools, likely21:08
notmorgandolphm: sha512_crypt isn't password-based key derivation21:09
dolphmi would say vulnerable passwords are no more vulnerable today than they were yesterday, then21:09
dolphmsha512_crypt is not inherently broken, it's just not as secure as a more secure option21:09
dolphmnotmorgan: is that incorrect?21:10
*** abhishekk has quit IRC21:11
notmorgansha512_crypt simply doesn't provide real protection21:11
dolphmthat depends on whether your password is "password" or "we4t9ogh04t6h80we", correct?21:11
notmorganthe advantages of pbkdf hashing is that is has better resource demands on time-complexity21:11
notmorgandolphm: somewhat, the fact that i can hash millions-10s of millions of strings a second on my home GPU in sha512_crypt means the time-complexity is low21:12
notmorgandolphm: "password" would probably be caught by a rainbow table21:12
notmorganfwiw21:12
*** adrian_otto has joined #openstack-keystone21:13
notmorganthe latter password is unlikely to be rainbowtabled.21:13
dolphmsure, but sha512_crypt still safely protects strong passwords. pbkdf2 offers much better protection for weak passwords.21:13
*** dave-mccowan has quit IRC21:13
notmorganfrom rainbow tables.21:13
notmorgansomewhat21:13
notmorganbut with todays commodity (and cloud-accesible hardware)21:14
notmorganit isn't hard to brute force sha512_crypt21:14
notmorgandolphm: if you want i'll produce a demo for you showing what hashcat and similar tools can do21:15
notmorganit simply comes down to sha_512 is significantly less secure from modern tools than pbkdf_sha512.21:18
notmorganand likewise bcrypt is better than pbkdf2_sha51221:18
*** belmoreira has quit IRC21:18
notmorgans/pbkdf_sha512/pbkdf2_sha512/21:18
notmorganafaict21:19
dolphmi believe i understand the risk, and don't see a strong reason to push an emergency fix, or even bother with a backport. new release of keystone begins rolling migration to stronger algorithm, future release drops support for old algorithm entirely.21:19
*** belmoreira has joined #openstack-keystone21:20
dolphmeveryone will be glad to see the improvement in security, certainly21:21
*** henrynash has quit IRC21:22
*** gyee has quit IRC21:22
*** gyee has joined #openstack-keystone21:23
notmorgani'm fine with a moving forward OSSN instead of an OSSA21:23
notmorganjust want to make sure we know the risk(s) involved21:23
dolphm(i actually can't remember the difference between the two)21:24
dolphmboth communicate the risk... what's the difference? advisories come with backports?21:24
notmorganOSSA has backports21:25
notmorganall supported releases are fixed21:25
notmorganOSSN is a lot less noticable21:25
dolphmmy suggestion would be OSSN + release notes, then21:25
notmorgannow... to be fair, sha256/512_crypt is "secure" in somuch as unix uses it in the shadow file21:26
*** henrynash has joined #openstack-keystone21:26
*** ChanServ sets mode: +v henrynash21:26
dstaneknotmorgan: not saying we should do this, but would it be possible to mitigate the risk with older versions using larger salts (if we had to)21:26
notmorganit's just that you still don't wnat your shadowfile exposed and web apps are more likely to see exposure of info than shadow21:26
dolphmdstanek: that's an interesting idea21:26
notmorganyou can use larger salts21:26
notmorganit's not a huge win in the case of sha[512|256]_cryupt21:27
*** chlong has quit IRC21:27
dolphmwhat's the default salt now?21:27
notmorganin the case of scrypt is makes a huge difference21:27
notmorganwe do auto-gen salt21:27
notmorganwhich is a fixed size in passlib21:27
notmorganfor sha..._crypt21:27
*** belmoreira has quit IRC21:27
dstaneknotmorgan: if you increase the salt size they you'd have to do that much more hashing to find a password right?21:27
notmorganmax salt_size is 16bytes21:28
notmorganin shaXXX_crypt21:28
dolphmhow big are the default salt values?21:28
dolphmthe autogenerated ones21:28
notmorganand i think it autofens 16bytes21:28
dolphmi assume 16 bytes?21:28
dstanekwell that's garbage21:28
notmorganautogens*21:28
notmorganyeah21:28
notmorganscrypt is the only one where you can configure explicit salt-size for autogen21:28
notmorganup to 1024bytes21:28
dstaneki want a 64b salt!21:28
notmorganthe default for scrypt is also 16bytes21:29
dstanekso a slower hash is better for hiding passwords, but worse for webapps21:29
notmorganbut you can create a ~1500 character hash with 1024 bytes of salt with scrypt, and with ~20rounds, in python i'm seeing ~2-5s at that point on my laptop to validate the password21:30
notmorganyes.21:30
dstanekyou would think a faster hash with a much larger salt would be better for webapps without risking too much protection21:30
notmorganit's about going with a more time-complextiy algo21:30
notmorganlike bcrypt21:30
notmorganor scrypt which is both time-complexity and memory-compexity21:30
notmorganthe additional salt data isn't a huge deal21:31
notmorganmost ASICs and FPGAs can handle it21:31
notmorganbut when you start requiring 10s of KB+ of space or more, they fall to the side21:31
notmorganand GPGPU isn't great at bcrypt/scrypt [better than CPU]21:32
dstanekthe extra salt makes the average number of required caluculations higher21:32
dstaneki'm curious if there's any research on that21:32
notmorganslightly higher, but since ASICs are being built for scrypt now (sigh) because of bitcoin...21:32
notmorgans/altcoin21:32
notmorganit helps a little, but not a lot.21:33
notmorganmodern hardware is pretty impressive in comparison to 1999 and even 2009 stuff21:33
dstaneki wonder what the break even point would be. is it still significantly faster to process a 16kb salted hash for example21:33
notmorgan1999 -> bcrypt introduction, 2009 -> scrypt21:33
* dolphm has to run21:34
*** agrebennikov_ has joined #openstack-keystone21:34
notmorgandstanek: oh pbkdf2 allows for variable salt_size21:34
notmorganas well21:34
notmorganwith a max of 1024 similar to scrypt21:35
notmorganand bcrypt must have a salt of 22 characters (i'm sure there is a cryptographic reason for that)21:35
notmorganIf specified, it must be 22 characters, drawn from the regexp range ``[./0-9A-Za-z]``21:36
*** henrynash has quit IRC21:36
notmorganor maybe because of the era of computation it was created in21:36
notmorganso anyway21:36
notmorganin short. if we increase the column size for password to 255, we can support up to ~128 bytes of salt in scrypt/pbkdf221:37
notmorganand sha512 and bcrypt21:37
notmorgankeystone will have to write both fields.21:37
notmorgancan't be done in a trigger21:37
notmorganthis will be an OSSN21:37
notmorganand i'll add an option that will [in ... uh.. whatever post pike is]21:38
notmorganwill be removed and we will stop writing in sha512 in the old location and no longer support new hashes in sha51221:38
notmorganannnnnnd can simply be disabled (sha512) if folks do not want to utilize the insecure hash for rolling upgrades21:39
* notmorgan sighs at this whole ick21:39
notmorganto think we almost used bcrypt instead to start. and this would have been a non-issue21:39
*** chris_hultin is now known as chris_hultin|AWA21:39
*** chlong has joined #openstack-keystone21:39
notmorgandstanek: i'll support pbkdf2, bcrypt, and scrypt as "new" hash forms and we'll default to bcrypt simply because that is the industry standard.21:40
*** thorst has quit IRC21:41
*** thorst has joined #openstack-keystone21:42
*** thorst has quit IRC21:46
*** lucasxu has quit IRC21:46
*** lucasxu has joined #openstack-keystone21:49
*** ngupta has quit IRC21:55
*** ngupta has joined #openstack-keystone21:55
*** chlong has quit IRC21:58
*** spilla has quit IRC22:07
*** edmondsw has quit IRC22:17
*** henrynash has joined #openstack-keystone22:18
*** ChanServ sets mode: +v henrynash22:18
*** henrynash has quit IRC22:20
*** adriant has joined #openstack-keystone22:21
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Remove microversions spec from backlog  https://review.openstack.org/43919022:22
*** henrynash has joined #openstack-keystone22:23
*** ChanServ sets mode: +v henrynash22:23
*** henrynash has quit IRC22:24
*** ngupta has quit IRC22:25
*** ngupta has joined #openstack-keystone22:25
*** phalmos has joined #openstack-keystone22:27
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Remove the fernet key store spec from backlog  https://review.openstack.org/43919422:28
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Remove centralized policy delivery spec from backlog  https://review.openstack.org/43919522:31
*** chris_hultin|AWA is now known as chris_hultin22:36
*** phalmos_ has joined #openstack-keystone22:42
*** phalmos has quit IRC22:46
*** adrian_otto has quit IRC22:50
*** chris_hultin is now known as chris_hultin|AWA22:50
*** ngupta_ has joined #openstack-keystone22:56
*** edmondsw has joined #openstack-keystone22:58
*** ngupta has quit IRC23:00
*** edmondsw has quit IRC23:01
*** ngupta_ has quit IRC23:01
*** edmondsw has joined #openstack-keystone23:01
*** phalmos has joined #openstack-keystone23:03
*** phalmos_ has quit IRC23:06
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Clarify bits of the alembic backlogged spec  https://review.openstack.org/43920523:08
*** lucasxu has quit IRC23:15
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Remove centralized policies fetch cache spec  https://review.openstack.org/43920823:15
*** gyee has quit IRC23:15
openstackgerritOpenStack Proposal Bot proposed openstack/keystone master: Updated from global requirements  https://review.openstack.org/43921923:18
*** edmondsw has quit IRC23:18
*** edmondsw has joined #openstack-keystone23:19
*** lamt has quit IRC23:27
*** lamt has joined #openstack-keystone23:28
*** phalmos_ has joined #openstack-keystone23:30
*** phalmos has quit IRC23:31
*** lamt has quit IRC23:40
notmorganwell then....23:44
notmorganthis has slowed the tests suite down massssssively23:44
* notmorgan will need to tweak some settings...23:44
*** edmondsw has quit IRC23:45
*** edmondsw has joined #openstack-keystone23:46
*** edmondsw has quit IRC23:50
*** dave-mccowan has joined #openstack-keystone23:57

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!