Thursday, 2014-06-12

*** sbfox has quit IRC00:04
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Hide details of HTTP 409 erros unless in debug
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Hide details of HTTP 409 errors unless in debug
*** oomichi_sleeping is now known as oomichi00:09
*** dstanek is now known as dstanek_zzz00:10
*** dims__ has quit IRC00:11
*** dims has joined #openstack-keystone00:11
jamielennoxmorganfainberg: do you know how the oslo.config example generator works00:18
jamielennoxi seem to remember it being you who did that in keystone00:18
morganfainbergjamielennox, i have a decent idea of it00:18
morganfainbergjamielennox, whats up with it?00:18
jamielennoxcomment here:
jamielennoxah, on another read after checking out the code that does make a bit more senes00:19
morganfainbergjamielennox, he's just saying make sure you've got all the options loaded before returning00:20
morganfainbergjamielennox, since it could put different options in depending on the ways (and times) it's called00:21
*** dims has quit IRC00:21
*** rodrigods_ has joined #openstack-keystone00:21
jamielennoxmorganfainberg: so part of the reason to make the register function standalone was that it could be called globally, and then load would get called in process later00:21
jamielennoxobviously that's not sufficient though00:21
morganfainbergjamielennox, right and you need to do the entrypoint thing to ensure the stuff is caught by the sample config generator00:22
morganfainberg(how keystone does it)00:22
morganfainbergdoes that make sense?00:23
jamielennoxso why do i need to do the entrypoint thing? if you call register() then the CONF object knows about those options00:23
morganfainbergbecause the way the generator works is it looks for lists of objects00:24
jamielennox(also from his comment i think this is a problem for people using this code not for that review)00:24
jamielennoxso it doesn't actually populate a CONF object and read it from there?00:24
jamielennoxthat seems... dumb00:24
morganfainbergit does some of that, but the guessing part is really ugly00:25
morganfainbergthe entrypoint bit is a lot cleaner imo00:25
morganfainbergit also eliminates the need to register opts on import00:25
morganfainbergyou can do it with a method (like this)00:26
morganfainbergi assume this is called at runtime, not at import, right?00:26
*** zhiyan_ is now known as zhiyan00:27
jamielennoxregister is designed to be called at import00:27
jamielennoxload is at runtime00:27
*** dims has joined #openstack-keystone00:27
morganfainbergso register is called when you import the session (e.g. import session, then session.register(groupname) ) ?00:27
*** dstanek_zzz is now known as dstanek00:28
jamielennoxoh, kindof00:28
jamielennoxi look at this as a replacement for defining your own list of options00:28
morganfainbergor is it import session... then somewhere at runtime .register_conf()00:28
morganfainbergin a function/method/etc00:28
jamielennoxso you would session.Session.register() in a global or something00:28
*** praneshp has quit IRC00:28
jamielennoxat the same time as you were registering all your other conf options00:29
morganfainbergwell keystone does't register options except at runtime, ever00:29
morganfainbergare we the unique snowflakes here?00:29
*** ncoghlan has joined #openstack-keystone00:30
morganfainbergthat is what made the extra work for the sample config generator for us00:30
jamielennoxoh - huh00:30
jamielennoxi thought that we did registered that on import00:31
morganfainbergwe used to, but it caused all sorts of bad code behavior00:31
jamielennoxauth_token certainly does:
morganfainbergi would recommending doing register at runtime00:32
morganfainbergnot at import time00:32
jamielennoxso i'm in general not a fan of oslo.config providing a global object00:32
morganfainbergbecause i think generate_sample will puke00:32
jamielennoxbut that would be the ONE advantage of that approach00:32
morganfainbergi _think_ i needs options to be in a [] of options to work00:33
jamielennoxok, not the only - but a REALLY BIG advantage to the global config is you can register whenever you like00:33
morganfainbergso [] and then register that []00:33
jamielennoxso dhellmann seems to have gone - but do you think simply returning opts is sufficient there?00:34
jamielennoxis it still ok to do the actual register on behalf of the service or shouuld i always just return a list and let the service register it00:34
morganfainbergwell, you'd need the other service to provide the entrypoint for it then (still)00:35
jamielennoxi considered that initially as a way to let the service set it's own deprecations00:35
jamielennoxi think that's going to have to happen anyway00:35
morganfainbergbut if you just returned a list, i _think_ you could at import say session_opts = session.Session.get_opts(group)00:36
morganfainbergif that returns a list00:36
morganfainbergor uh, you know what i mean00:36
morganfainbergsession_opts = session.session.get_opts()00:36
morganfainbergthen they can register it however they want00:36
morganfainbergit's their business.00:36
morganfainbergthat would solve the need for the entrypoint00:37
jamielennoxit kind of kills the aesthetics of it00:37
jamielennoxalso why does it remove the need for an entrypoint - you stil lhave that list defined in an external library00:37
morganfainbergthe entrypoint is needed because you don't end up iwth these options in a list in a module00:38
morganfainbergyou register it on behalf of the consumer00:38
morganfainbergso that consumer needs a method to expose these options (in the group(s) it will want them registered) to the sample_config generator00:38
morganfainbergthe consumer would have a method called uhmm .session_entry_point_opts00:39
*** richm has left #openstack-keystone00:39
morganfainbergwhich would get the list of your opts you're providing and do what keystone is doing (essentially)00:39
*** rodrigods_ has quit IRC00:39
morganfainbergin either case you'd need to split the definition of the opts to a second method that could extract them separately from registering them00:39
morganfainbergdoes that help?00:40
morganfainbergit's kinda hard to explian00:40
jamielennoxis it a problem though to register and return - or not worth the effort?00:41
morganfainbergi dunno if it's worth the effort.00:42
morganfainbergthe more straightforward everything is, the better.00:42
morganfainbergbut i do like providing a helper to "hey go register this for this group"00:43
morganfainbergit's... convienient?00:43
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Properly invalidate cache for get_*_by_name methods
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Session loading from conf
jamielennoxmorganfainberg: ^^00:44
jamielennoxi like the symmetry of Session.register_opts(CONF, group) Session.load_opts(CONF, group)00:44
morganfainbergsure. the consuming project will still need an entrypoint i think00:45
jamielennoxyea - i think even if i just return the list they will need an entrypoint right?00:45
morganfainberglook at how list_opts works in keystone00:46
morganfainbergwill need to return (group, [opt, opt, opt]) i it looks like00:46
jamielennoxyea, but group is defined by the consumer in our case00:46
morganfainbergoh ha yeah00:47
morganfainbergso the consumer will provide the entrypont00:47
morganfainbergand append group info to it00:47
morganfainbergerm make the (group, opts) tuple list thing00:47
jamielennoxyea, that's what i got from dougs comment, the consumer would need to provide an entrypoint to the function that did all the option registering00:50
jamielennoxi don't know if it matters if the same function actually registers the options so long as it returns them00:50
jamielennoxso eg heat would have a function that says load_client_config_opts() that registered all the options and returned the list00:51
jamielennoxthat should be able to be the same function that they use internally to actually register them00:51
morganfainbergexcept i think registering might cause issues for the sample_generator00:53
morganfainbergwith the entrypoint00:53
jamielennoxbut then any other project who was registering options at import time would fail00:54
morganfainbergas an entrypoint it works slightly differently00:54
morganfainbergbut i don't think you want to muck with the conf object00:54
*** jdennis has joined #openstack-keystone00:54
jamielennoxso if i can't register in the function called by the endpoint then i have to provide a seperate list and a register - but that's ok because the service wouldn't be able to use the same function to do the registering either00:56
morganfainbergjamielennox, right00:57
morganfainbergjamielennox, you should check w/ dhellmann on that, but i _think_you want to avoid registerting and listing in one shot00:57
jamielennoxit's just whether it's worth providing the register function at all - because looking at it now it's just doing really basic oslo.config commands that the service would know how to do anyway00:58
* morganfainberg grumbles, ... Rangers up 1-0, 3 mins left in the 1st period.00:58
jamielennox(Rangers is what sport again)00:58
morganfainbergice hockey00:58
morganfainbergplayoff finals00:59
morganfainbergkings are up 3 games to 0 in the series (best 4 of 7 wins the series)00:59
jamielennoxlol, the history to 4 of 7 that would be intersting01:00
jamielennoxit's like one of those kids things where you kept uping the number of games you needed until you won01:00
jamielennoxi bet it started as 2/301:00
jamielennoxor possible 101:01
*** jdennis has quit IRC01:04
*** mberlin1 has quit IRC01:10
*** gokrokve has joined #openstack-keystone01:14
*** PritiDesai has quit IRC01:18
*** jdennis has joined #openstack-keystone01:18
*** PritiDesai1 has joined #openstack-keystone01:18
*** PritiDesai1 has quit IRC01:22
*** mberlin has joined #openstack-keystone01:25
*** gyee has quit IRC01:28
*** jdennis has quit IRC01:28
*** gokrokve has quit IRC01:30
*** gokrokve has joined #openstack-keystone01:30
*** gokrokve has quit IRC01:35
*** sbfox has joined #openstack-keystone01:37
*** rwsu has quit IRC01:42
*** jdennis has joined #openstack-keystone01:46
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Session loading from conf
*** ncoghlan is now known as ncoghlan_afk01:55
*** ncoghlan_afk is now known as ncoghlan01:56
*** ncoghlan is now known as ncoghlan_afk02:13
*** browne1 has quit IRC02:16
*** jdennis has quit IRC02:16
*** nsquare has quit IRC02:23
*** jdennis has joined #openstack-keystone02:31
*** sbfox has quit IRC02:34
*** dims has quit IRC02:40
*** jdennis has quit IRC02:45
*** dstanek is now known as dstanek_zzz02:50
*** gokrokve has joined #openstack-keystone03:05
*** dims_ has joined #openstack-keystone03:07
*** ncoghlan_afk is now known as ncoghlan03:10
*** dims_ has quit IRC03:12
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Unversioned endpoints in service catalog
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Add invalidate doc string to identity plugin
*** xianghui has quit IRC03:16
*** praneshp has joined #openstack-keystone03:18
*** xianghui has joined #openstack-keystone03:23
*** dstanek_zzz is now known as dstanek03:25
*** stevemar has joined #openstack-keystone03:26
*** zhiyan is now known as zhiyan_03:30
jamielennoxmorganfainberg: ahh, lands right in the middle of what i was looking at03:37
morganfainbergwill fix in next patch03:38
morganfainbergworking on the cache invalidation one now.03:39
morganfainbergran into an interesting inconsistency03:39
jamielennoxno rush03:39
*** praneshp_ has joined #openstack-keystone03:39
jamielennoxi still don't have a good solution for the general body case03:39
*** stevemar has quit IRC03:40
morganfainbergstart somewhere, right? :)03:41
*** zhiyan_ is now known as zhiyan03:41
morganfainbergactually. ugh03:41
morganfainbergjust thought of something03:41
*** praneshp has quit IRC03:41
*** praneshp_ is now known as praneshp03:41
morganfainbergcan't use raw sha103:41
morganfainbergthat is a valid hash for tokens now.03:41
morganfainbergmaybe hashlib.sha1().update('Token Obscuring Hash') then update w/ the token_id ?03:42
*** Ackowa has quit IRC03:45
*** dstanek is now known as dstanek_zzz03:45
*** sbfox has joined #openstack-keystone03:48
*** xiej has quit IRC03:51
morganfainbergjamielennox, is there a better way of doing this?
jamielennoxmorganfainberg: if you are going to update() then there is no point doing the hash is there?03:54
*** ayoung has quit IRC03:54
morganfainberg.update combines doesn't it?03:54
jamielennoxoh, you want to know that it's the same token03:54
jamielennoxjust not what that is03:54
jamielennoxyou could just do a rand() or something globally and use that03:55
jamielennoxthese things are only going to be useful within 1 run right03:55
morganfainbergjamielennox, it needs to be consistent, because they want to know if the same token is used in multiple requests03:55
morganfainbergat the moment tokens are valid for 1hr (default)03:56
morganfainbergthey could be reused03:56
morganfainbergit might help to know if a token was explicitly reused (and maybe expired along the way)03:56
jamielennoxand we need the output value to be the same across multiple runs of a client?03:56
jamielennoxpossible i guess03:56
jamielennoxi'd change {SHA1} to {OBSCURED} or something03:57
morganfainbergSalted SHA103:58
*** amcrn has joined #openstack-keystone03:58
morganfainbergbut i'm ok iwth making it "obscured"03:58
jamielennoxit is sha1 but that would imply that i can sha1 a token i know about SHA1 it and compare it to the debug03:58
morganfainbergso {obscured}? SSHA? SSHA1? {thisisnotarealtokenbutahashdealwithit}?03:59
jamielennoxmorganfainberg: maybe we should do04:00
jamielennox32 * '*' + token[:32]04:01
jamielennoxhow big is uuid again - i was going for 6404:01
jamielennoxok, maybe just04:02
jamielennoxX-Auth-Token: ****token[8:]04:03
morganfainbergi think you're going to run into hash collisons there04:03
morganfainbergor well... much higher chance04:03
jamielennoxmeans you can mostly verify a token you know, but not use it to auth04:03
morganfainbergfor uuid tokens04:03
morganfainbergfor pki meh04:03
jamielennoxi'm just trying to indicate that all but the last 8 characters are obscured04:03
morganfainbergoh oh i see04:03
morganfainbergthat "kinda" works04:04
morganfainbergand for PKI though, it might be guessable04:04
jamielennoxnot really04:04
jamielennoxyou can't take those 8 characters and use them for anything04:04
morganfainbergMII<somethingx8><rest of token>04:05
morganfainbergit's only 5 urlsafe b64 characters04:05
morganfainbergeven 8.04:05
jamielennoxyea, i changed it to [8:] always take the last ones04:05
morganfainbergnot much to bruteforce04:05
morganfainbergi'd rather hash it04:05
jamielennoxis that going to be the same on PKI? i didn't think so04:05
morganfainbergyeah this is on at the same time as PKI04:05
morganfainbergthis would show whatever is in X-AUTH-TOKEN04:06
jamielennoxi mean will there be any repetition in the last 8 chars of a PKI token04:06
jamielennoxlike how they all start with MII04:06
morganfainbergcould be04:06
morganfainbergseriously, i'd rather just hash it and not "guess" about good-enough04:06
jamielennoxup to you, i think so long as your not providing the whole thing you're fairly secure04:06
jamielennoxfor debug you really don't care much04:06
jamielennoxand the infra guys will be happy with anything short04:07
morganfainbergthere is care to know within a good deal of certainty sure a token was reused.04:07
jamielennoxmorganfainberg: but not for this audience04:08
jamielennoxall we need to do is print something on screen for debug logging04:08
jamielennoxit doesn't matter if you just --REDACTED-- the whole thing04:08
morganfainbergno i was specifically asked not to do --REDACTED-- by infra04:08
morganfainbergwell sdague04:09
morganfainbergspecifically for debugging if a token was reused across requests04:09
jamielennoxthat's my current thought for preventing logging of auth packets, i'm just going to say don't log at all then log it in the plugin seperately04:09
morganfainbergjamielennox, im fine with that (Re auth packets)04:10
morganfainbergmaybe the best bet is to do token[:8] + token04:11
morganfainberghash that04:11
morganfainbergit will ensure we get different hashes each time.04:11
morganfainbergbut it wont be a native sha104:11
jamielennoxi think you're over thinking it, hash collisions in debug output aren't going to matter04:12
jamielennoxso to get around the sha1 is a valid thing just hash it twice04:13
jamielennox.update(token * 2) - i wonder which is faster04:14
*** harlowja is now known as harlowja_away04:16
jamielennoxmorganfainberg: no - that's way off04:17
jamielennoxyou reduce the input space before expanding it again - you loose all actual benefit of the hash04:17
jamielennoxdo the double update above04:17
morganfainberghow am i reducing the input space?04:18
jamielennoxif you want to do a hash - othrewise just show the last X digits04:18
jamielennoxsorry didn't see the + thought it was just the [:13]04:18
morganfainbergfirst 13 bytes + the whole id04:18
morganfainberg= consistent hash, not predictable (within reason)04:18
morganfainberg3 characters [MII] + 1004:19
jamielennox.. still think just do the double04:19
morganfainbergoh update(bit) then update(bit2)?04:20
morganfainbergi see.04:20
morganfainbergdouble hash the token04:20
jamielennoxit looks kinda nicer too as you can do if k == 'X-Auth-Token': v = hashlib.sha1(token * 2).hexencode()04:20
jamielennoxi don't know if token * 2 is the same output as update twice - i guess it should  be04:20
morganfainberg>>> '1234567890'*204:21
jamielennoxso *2 and update twice gives the same result - makes sense04:22
morganfainbergjamielennox, might fall back to that (the double updatE)04:24
morganfainbergi'll post a comment on the review saying that is the alternate option and see what other feedback we get04:24
jamielennoxi think it's easier than trying to guess that the first [:13] are unique - but again for debug output i don't think anyone cares04:25
morganfainbergi actually am doing [-13]:] now04:29
morganfainbergup to the last 13 bytes04:29
openstackgerritMorgan Fainberg proposed a change to openstack/python-keystoneclient: Do not expose Token IDs in debug output
jamielennoxdo for key, val in headers:    if key.lower() == 'x-auth-token': val = hashstuff04:34
jamielennoxlet the string_parts stuff be common04:35
jamielennoxalso, i think pull it out to a function, historically it was called http_log_req
jamielennoxmorganfainberg: lol, just noticed
morganfainbergyeah that is where a lot of this comes from04:36
jamielennoxyea, but i extracted session mostly from keystoneclient04:37
*** dstanek_zzz is now known as dstanek04:37
jamielennoxso it's not necessarily the same04:37
*** Abhijeet_ has joined #openstack-keystone04:43
*** dstanek is now known as dstanek_zzz04:47
*** gokrokve has quit IRC04:53
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements
*** Abhijeet_ has left #openstack-keystone04:56
morganfainbergjamielennox, oooh
morganfainbergi got the _islogginenabledfor thing wrong04:57
morganfainbergbut only for py33?04:58
jamielennoxmorganfainberg: wtf is that04:58
morganfainbergno idea04:58
jamielennoxa bug in logging ?04:58
jamielennoxthat'd be fun04:58
morganfainbergname resolution fail on one of the tempests will recheck when it finishes04:59
morganfainbergit'll resolve itself.04:59
morganfainbergand be really transient04:59
jamielennoxmorganfainberg: oh - no it's your fault05:00
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements
jamielennoxlogging.debug is the function logging.DEBUG is the level05:00
openstackgerritMorgan Fainberg proposed a change to openstack/python-keystoneclient: Do not expose Token IDs in debug output
morganfainbergthere we go05:02
jamielennoxmorganfainberg: uggh
jamielennoxyay other people doing session based stuff, but wow05:10
morganfainbergdid they... just...05:11
jamielennoxalthough some of this can be blamed on neutronclient being another special flower05:11
morganfainbergthis is why i think all the *clients need to roll up into a single library05:12
jamielennoxbut i don't even think that would work05:12
morganfainberg.identity .compute .network .whatever05:12
morganfainbergand the have some common code for everyone to share05:12
jamielennoxthe SDK is always looking for more people05:12
jamielennoxi haven't had time to touch it recently05:12
morganfainbergbut SDK isn't really... as far as i understand, meant to supplant the *clients05:13
morganfainbergit's meant more for .. uhm.. something else?05:13
* morganfainberg didn't get their mission05:13
*** dstanek_zzz is now known as dstanek05:13
jamielennoxif you want everything in one place - that's going to be the place05:14
jamielennoxit was only recently i realized how bad some of these clients were that i started to agree05:15
jamielennoxi was sure if i provide some common framework stuff everyone will do the right thing05:15
*** ncoghlan is now known as ncoghlan_afk05:23
*** dstanek is now known as dstanek_zzz05:23
*** deep has joined #openstack-keystone05:25
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Properly invalidate cache for get_*_by_name methods
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Make sure domains are enabled by default
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Only emit disable notifications for project/domain on disable
deepHello, I have configured swift with keystone(Active Directory), while creating container i am getting error in syslog "Jun 11 22:52:36 node1 proxy-server: Unexpected response from keystone service: {u'error': {u'message': u'Could not find role, swift.', u'code': 404, u'title': u'Not Found'}} Jun 11 22:52:36 node1 proxy-server: Authorization failed for token 9ece2e7637704563fc61eff8d53e0508 Jun 11 22:52:36 node1 proxy-server05:27
deepany idea what is missing ?05:27
*** ncoghlan_afk is now known as ncoghlan05:27
*** daneyon_ has quit IRC05:29
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Only emit disable notifications for project/domain on disable
*** henrynash has joined #openstack-keystone05:51
*** oomichi has quit IRC05:58
*** stevemar has joined #openstack-keystone05:58
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex
openstackgerritAndre Naehring proposed a change to openstack/python-keystoneclient: Added help text for the debug option
*** dstanek_zzz is now known as dstanek06:15
*** praneshp has quit IRC06:16
*** stevemar has quit IRC06:18
*** dstanek is now known as dstanek_zzz06:25
*** Ackowa has joined #openstack-keystone06:27
*** jaosorior has joined #openstack-keystone06:49
*** oomichi has joined #openstack-keystone07:04
*** ncoghlan has quit IRC07:09
*** sbfox has quit IRC07:09
*** BAKfr has joined #openstack-keystone07:14
*** dstanek_zzz is now known as dstanek07:16
*** dstanek is now known as dstanek_zzz07:26
*** marekd|away is now known as marekd07:26
*** leseb has joined #openstack-keystone07:45
*** jkappert has quit IRC07:45
*** jkappert has joined #openstack-keystone07:45
*** leseb has quit IRC07:56
*** leseb has joined #openstack-keystone07:57
*** leseb has quit IRC08:01
*** oomichi has quit IRC08:05
*** leseb has joined #openstack-keystone08:12
*** dstanek_zzz is now known as dstanek08:16
*** dstanek is now known as dstanek_zzz08:26
*** afazekas has joined #openstack-keystone08:42
openstackgerritliusheng proposed a change to openstack/python-keystoneclient: Set the iso8601 log level to WARN
*** dims_ has joined #openstack-keystone08:49
*** rodrigods_ has joined #openstack-keystone08:50
*** dims_ has quit IRC08:54
*** jkappert has quit IRC08:57
*** jkappert has joined #openstack-keystone08:58
*** henrynash has quit IRC09:04
*** dstanek_zzz is now known as dstanek09:17
*** zhiyan is now known as zhiyan_09:23
*** amcrn has quit IRC09:24
*** dstanek is now known as dstanek_zzz09:27
marekdis it acceptable for class property to raise exception?09:53
*** oomichi has joined #openstack-keystone09:54
*** henrynash has joined #openstack-keystone10:00
*** rodrigods_ has quit IRC10:01
jaosoriora class property to raise an exception? what context?10:02
marekdobj = A(); and in case property is not yet ready an exception is raised.10:03
marekdhm, actually I think it's is :-)10:03
marekdit's like standard obj.idontexist where AttributeError is raised :-)10:04
marekdaha, this 'property' is a method decorated with @property ofcourse.10:04
marekdthat was my point.10:04
marekdjaosorior: ^^10:05
jaosoriorI think it could work, yet, why would it be a property then? why not have a getter method that returns None or raises the exception?10:07
jaosoriorI would assume that if a variable is accessible as a property it would be available at the point the class is created10:07
*** leseb has quit IRC10:14
*** leseb has joined #openstack-keystone10:15
*** alexknith has joined #openstack-keystone10:16
*** dstanek_zzz is now known as dstanek10:18
marekdI have a class where ater successful auth you have a token10:19
*** leseb has quit IRC10:19
*** ajayaa has joined #openstack-keystone10:20
*** dims_ has joined #openstack-keystone10:23
*** NM has joined #openstack-keystone10:24
*** amcrn has joined #openstack-keystone10:24
marekdeh, maybe i am complicating it a bit...10:25
*** dstanek is now known as dstanek_zzz10:28
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Implement SAML2 ECP authenticatio
*** NM has quit IRC10:41
*** leseb has joined #openstack-keystone10:46
*** henrynash has quit IRC10:48
deepHello, Any idea about this error : "Jun 12 03:18:42 node1 proxy-server: Authorization failed for token e2e6e8b09916ac22dd714e3dbc155902 Jun 12 03:18:42 node1 proxy-server: Invalid user token - deferring reject downstream"10:50
*** leseb has quit IRC10:51
*** NM has joined #openstack-keystone10:59
*** henrynash has joined #openstack-keystone11:01
*** dstanek_zzz is now known as dstanek11:19
*** dstanek is now known as dstanek_zzz11:29
*** leseb has joined #openstack-keystone11:30
*** kun_huang has joined #openstack-keystone11:33
*** jdennis has joined #openstack-keystone11:34
*** kun_huang has quit IRC11:48
*** nsquare has joined #openstack-keystone11:52
*** lbragstad has quit IRC11:59
*** juanmo has joined #openstack-keystone12:03
openstackgerritA change was merged to openstack/identity-api: Document GET /v3
*** dstanek_zzz is now known as dstanek12:19
*** xianghui has quit IRC12:22
*** dims_ has quit IRC12:22
*** deep has quit IRC12:23
*** dims_ has joined #openstack-keystone12:23
*** dims_ is now known as dims12:25
*** gordc has joined #openstack-keystone12:29
*** dstanek is now known as dstanek_zzz12:29
*** xianghui has joined #openstack-keystone12:33
*** chandan_kumar has joined #openstack-keystone12:41
openstackgerritJohn Dennis proposed a change to openstack/keystone: Add missing docstrings and 1 unittest for LDAP utf-8 fixes
*** chandan_kumar has quit IRC12:44
*** amcrn has quit IRC12:46
*** openstackgerrit has quit IRC12:46
*** NM has joined #openstack-keystone12:47
*** openstackgerrit has joined #openstack-keystone12:47
*** oomichi has quit IRC12:49
*** CaioBrentano has joined #openstack-keystone12:51
*** chandankumar has joined #openstack-keystone12:52
*** dims_ has joined #openstack-keystone12:55
*** dims has quit IRC12:56
openstackgerritsarad patel proposed a change to openstack/keystone: Fixes typo error in Keystone
*** lbragstad has joined #openstack-keystone12:57
*** nkinder has quit IRC13:09
*** ajayaa has quit IRC13:12
*** bklei has quit IRC13:13
*** ayoung has joined #openstack-keystone13:19
*** dstanek_zzz is now known as dstanek13:20
*** ajayaa has joined #openstack-keystone13:27
*** tristanC has joined #openstack-keystone13:42
*** nkinder has joined #openstack-keystone13:43
*** raildo has quit IRC13:48
*** tellesnobrega has quit IRC13:49
*** rodrigods has quit IRC13:49
*** thiagop has quit IRC13:50
*** bknudson has joined #openstack-keystone13:50
*** jkappert has quit IRC13:52
*** jkappert has joined #openstack-keystone13:52
*** kun_huang has joined #openstack-keystone13:57
*** kun_huang has quit IRC13:58
*** rodrigods has joined #openstack-keystone14:00
*** rodrigods has joined #openstack-keystone14:00
*** kun_huang has joined #openstack-keystone14:01
*** hrybacki has joined #openstack-keystone14:01
*** tellesnobrega has joined #openstack-keystone14:01
*** jsavak has joined #openstack-keystone14:03
*** gordc has quit IRC14:06
*** tellesnobrega has quit IRC14:08
openstackgerritDavid Stanek proposed a change to openstack/keystone: Middleware tests now run under Python3
*** rodrigods has quit IRC14:10
*** tellesnobrega has joined #openstack-keystone14:12
openstackgerritDavid Stanek proposed a change to openstack/keystone: Debug messages don't need translations
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds a newline for pep8 compliance
openstackgerritDavid Stanek proposed a change to openstack/keystone: Stops overriding a builtin for pep8 compliance
*** rodrigods has joined #openstack-keystone14:13
*** rodrigods has joined #openstack-keystone14:13
*** ajayaa has quit IRC14:20
*** richm has joined #openstack-keystone14:23
*** davlaps has joined #openstack-keystone14:24
*** PritiDesai has joined #openstack-keystone14:27
*** topol has joined #openstack-keystone14:30
*** kun_huang has quit IRC14:30
*** radez_g0n3 is now known as radez14:34
*** kun_huang has joined #openstack-keystone14:34
*** topol has quit IRC14:41
*** leseb has quit IRC14:42
*** leseb has joined #openstack-keystone14:42
*** gordc has joined #openstack-keystone14:43
ayoungrodrigods, yep14:47
*** leseb has quit IRC14:47
rodrigodsayoung, I remember to read something about a policies service, but I'm not finding the wiki page anymore =/14:47
rodrigodsayoung, as I recall, you were the author...14:48
ayoungrodrigods, hmmmm...blueprints?14:48
ayounghrybacki, in here, please...14:48
rodrigodsayoung, a wiki page, I think14:49
hrybackiayoung: can you explain to me how token caching works as it stands and how, if it all, revocation events change things?14:49
rodrigodsa proposal for a policy service that would centralize the authorization of all components14:49
*** thedodd has joined #openstack-keystone14:52
ayounghrybacki, sure14:55
ayounghrybacki, are you familiar with memcached?14:56
hrybackino, but I've been seeing it a lot in the code14:56
ayounghrybacki, read up on memcached14:57
hrybackiayoung: nods14:57
ayounghrybacki, short of it:   it is a key value store14:57
ayoungnon persisted14:57
ayoungshared between proceese14:57
ayoungused in Apache and comparable web servers for session type stuff14:58
*** leseb has joined #openstack-keystone14:59
marekdmorganfainberg: afternoon15:00
morganfainbergmarekd, :)15:00
marekdmorganfainberg: :)15:01
rodrigodsayoung, just found: =)15:02
*** vhoward has left #openstack-keystone15:09
*** PritiDesai has quit IRC15:09
*** bklei has joined #openstack-keystone15:15
*** andreaf has quit IRC15:16
*** daneyon has joined #openstack-keystone15:18
openstackgerritayoung proposed a change to openstack/keystone: Block delegation escalation of privilege
hrybackiayoung: worth a chuckle15:28
*** gyee has joined #openstack-keystone15:30
*** jsavak has quit IRC15:30
*** jsavak has joined #openstack-keystone15:30
*** stevemar has joined #openstack-keystone15:33
hrybackiayoung: okay -- I've got a better handle on memcached15:40
dstanekayoung, hrybacki: and the most important piece of info from a dev perspective is that you are not guaranteed to get back what you put in15:47
*** bklei has quit IRC15:47
*** bklei has joined #openstack-keystone15:49
*** daneyon has quit IRC15:50
*** daneyon has joined #openstack-keystone15:51
stevemaranyone have any strong feelings about
stevemarI'm uploading a new version soon, and want to get any comments addressed :)15:53
*** CaioBrentano has quit IRC15:54
*** gokrokve has joined #openstack-keystone15:54
*** daneyon_ has joined #openstack-keystone15:55
*** daneyon has quit IRC15:55
ayoungstevemar, can we please just integrate audit with policy?15:55
ayounginstead of "audit this" and then "that"...15:56
ayounglets just emit the audit events from policy enforcement15:56
ayoungI mean...your BP is right on, except that we need to audit other things too.15:56
*** NM has quit IRC15:57
stevemarayoung, hmm, i see what you mean, but it's almost a complete redesign in a sence15:58
bknudsonwas looking at the discussion on the -dev ml about dropping postgresql from the gate15:58
*** marcoemorais has quit IRC15:58
bknudsonseems like we should have a gate-keystone-postgresql that runs the unit tests with a live postgresql15:59
bknudsonsame for mysql15:59
bknudsonand db215:59
*** rodrigods has quit IRC16:00
morganfainbergso... is there any reason we can't make the API bounce out short-id tokens if we only use PKI?16:01
morganfainberge.g. pki provider means you can't use the short-hash token (keystone says nope)16:01
morganfainbergjust not on the API front.16:02
bknudsonone reason is that it works today so that wouldn't be backwards compat16:03
*** bklei has quit IRC16:04
morganfainbergbknudson, the multi-hash configurations + short-id support means we have to do something "clever" to obscure the data in the logs (X-Auth-Token) because we can't assume SHA1 wont net us a "usable" token16:04
bknudsonmorganfainberg: lol16:05
morganfainbergbknudson, we can salt the token, but ... we need to add a whole load of documentation around it - qa/infra/etc want to have a consistent way to identityf tokens used across multiple calls (timeout cause token timed out?) and not put bearer tokens in the logs themselves16:05
bknudsonmorganfainberg: I wasn't expecting anyone would pick sha1 for the new hash.16:06
*** gordc has quit IRC16:06
morganfainbergbknudson, but someone could. meaning ... we can't use it as the obscuring hasih in debug16:06
bknudsonconsidering sha256 is available16:07
morganfainbergbknudson, maybe we just explicitly deny sha1 in the cms config bits?16:07
morganfainberg"raise EUseSomeBetterHashThanSHA116:07
bknudsonI wouldn't have a problem with that16:07
morganfainbergbknudson, ok cool. that makes my life waaaaay easier.16:08
bknudsonseems like we're going overboard with this to me16:08
bknudsoncould see it as a feature16:08
bknudsonif you want to have valid tokens in your logs just set the hash algorithm to sha116:08
bknudsonwouldn't it be double sha1d ?16:08
morganfainbergbknudson, LOL someone would have a feild day with that :P16:08
bknudsonoh, this is pki->sha1(pki)16:09
morganfainbergit's... annoying :P16:09
bknudsonwell, the other suggestion was truncate it16:09
bknudsonrather than sha116:09
morganfainberghow far do you truncate it?16:09
morganfainbergand what is the likelyhood of having 2 tokens look the same in the debuglog then?16:10
bknudsonwell, they all start with MII so 3 chars isn't enough16:10
bknudsonI would go 9?16:10
morganfainbergremember we need to also truncate correctly for UUID/short-id tokens16:10
bknudson9 might be too much for UUID16:11
bknudsonmaybe remove the first 3 chars and take the next 616:11
morganfainbergyeah, thats why i just want a simple "go hash this one way" mechanism16:11
marekdwhen patchset A depends on patchsest B they should have different Change-Id values, right?16:11
morganfainbergmarekd, yes16:11
bknudsonof course, if someone's using the admin token that might be the whole token.16:11
morganfainbergbknudson, yep.16:11
morganfainbergbknudson, lets stick with silly hashing :P16:11
bknudsonhow about a double-sha1?16:12
bknudsonthat wouldn't match if they used sha1 for token hash16:12
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Scope unscoped saml2 tokens.
ayoungbknudson, I'd sooner drop mysql from the gate than postgres16:12
morganfainbergsure, but that comes back to lots of documentation16:12
bknudsonmorganfainberg: why do we need to document?16:12
bknudsonoh, so they can figure it out16:13
ayoungI think we should give tokens human read able names16:13
ayounglike George16:13
bknudsonone thing is that this is open source. We could make it easy to change the hash by changing the code16:13
bknudsonso we don't need yaco (yet another config option)16:13
morganfainbergbknudson, i was planning on making this non-configurable :P16:14
morganfainbergbknudson, you get this method of obscuring. period16:14
bknudsonand I don't think "sha1(sha1(token))" is much harder to document than sha1(token)16:14
morganfainbergbknudson, sure but sha1 is easily represented as {SHA1}<token>16:14
morganfainbergshould we do {SHA1}{SHA1}<token>?16:14
morganfainbergor {SHA1x2}<token>16:15
morganfainbergthey didn't like sha1(token) cause it looks like a method16:15
bknudsonmaybe there's some other prefix that's standard?16:15
morganfainbergi proposed the LDAP-ish way (e.g. {SSHA} {MD5} etc)16:15
morganfainbergwait a minute...16:16
*** leseb has quit IRC16:17
openstackgerritSteve Martinelli proposed a change to openstack/keystone-specs: Audit support for federation spec
morganfainbergcan you use the admin token to interact with services behind auth_tokne?16:19
morganfainbergor only keystone16:19
bknudsonmorganfainberg: only keystone16:20
morganfainbergthen maybe we just use the swift thing and just do the 1st 16 bytes... whatever16:20
morganfainbergi'm just done wanting to think about this16:20
*** sbfox has joined #openstack-keystone16:20
bknudsonI think sha1 will work fine.16:20
bknudsonI don't have a problem disabling it as configurable option for token hashing16:21
morganfainbergthat works for me. i'll submit a couple patches for that.16:21
morganfainbergi'll include the disable of sha1 in ksc with my patch for this obscuring16:22
morganfainbergand i'[ll submit the keystone version today16:22
*** alexknith has quit IRC16:22
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Implement SAML2 ECP authentication
*** davlaps is now known as devlaps16:25
stevemarmorganfainberg, dolphm gyee dstanek henrynash ayoung bknudson lbragstad jamielennox marekd ... i'd appreciate some eyes on
lbragstadstevemar: added to my queue16:28
stevemarlbragstad, yay16:28
marekdstevemar: sure. BTW did you manage to decrypt saml2 assertion locally (ref. e-mail)16:29
stevemarmarekd, that got postponed for a day or two, something has come up16:29
marekdstevemar: ok16:29
stevemarmarekd, but hopefully soon16:30
marekdstevemar: it worked for me so will work for ya. you can play with your own assertions.16:30
gyeestevemar, sure, that one seem like a no-brainer, I'll go through it16:31
hrybackiayoung: can you point out when and where tokens are getting cached during the middleware tests?16:32
stevemargyee, yeah, hoping thats the case, just some clean up needed16:32
*** gokrokve has quit IRC16:33
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Scope unscoped saml2 tokens.
*** gordc has joined #openstack-keystone16:36
*** openstackgerrit has quit IRC16:38
*** marcoemorais has joined #openstack-keystone16:41
*** marcoemorais has quit IRC16:42
gyeestevemar, I don't have any major concerns, a bit more detail on the proposed change section would be awesome16:42
*** marcoemorais has joined #openstack-keystone16:42
marekdstevemar: what CADF notifications are currently implemented?16:42
marekdgyee: ++16:42
*** BAKfr has quit IRC16:44
*** browne has joined #openstack-keystone16:46
*** nsquare has quit IRC16:47
*** amcrn has joined #openstack-keystone16:47
*** jsavak has quit IRC16:48
*** leseb has joined #openstack-keystone16:48
morganfainbergchmouel, ping16:50
morganfainbergchmouel, re: token masking16:50
morganfainbergchmouel, when you have a bit16:50
*** leseb has quit IRC16:53
*** harlowja_away is now known as harlowja16:54
hrybackiayoung: we are only concerned with checking revocation events for tokens stored in the cache, yeah?16:54
nkindermorganfainberg: are we avoiding having a config option for logging the whole token (as was suggested in the review)?16:55
morganfainbergnkinder, i don't want to open that door really16:55
nkindermorganfainberg: I really don't think we should log the token, even with some "insecure" settings16:55
morganfainbergnkinder, :)16:55
morganfainbergnkinder, i am going to fight against logging the token at all16:56
nkinderjust wanted to know if you were standing your ground :)16:56
morganfainbergnow if OSC wants to offer full curl output w/ token16:56
morganfainbergi don't care16:56
morganfainbergbut anything that is going into logs from services16:56
morganfainbergand i have a say about it...16:56
morganfainbergHEEEEELLLLL no :)16:56
nkinderyes, logs should not have an option16:56
morganfainbergnkinder, :)16:56
nkindermorganfainberg: I know that jamielennox has been looking at the password logging16:56
morganfainbergi think he has the right answer, make the plugin log it16:57
*** jsavak has joined #openstack-keystone16:57
morganfainbergdon't log anything from the session16:57
morganfainbergspecifically for auth packets16:57
nkindermorganfainberg: you mean if someone wants it, they write a plugin?16:57
morganfainbergeach auth plugin is responsivle for logging the info about the auth request it is going to handle16:58
morganfainbergso for auth packets, the plugin does the logging (and sanitizes things) instead of session needing to figure out what the heck to sanitize16:58
*** erecio has quit IRC16:58
morganfainbergwhat if it's XML? what if the secure field is "<pancakes>SECURE DATA</pancakes>"16:58
morganfainbergeasier if the plugin does the "smart" thing there.16:59
*** erecio has joined #openstack-keystone16:59
*** rwsu has joined #openstack-keystone17:00
*** radez is now known as radez_g0n317:00
morganfainbergnkinder, we still have the issue with sanitizing the debug on the returned token for an auth_request. but small steps, right?17:00
nkindermorganfainberg: there is code in oslo for obscuring the password part at least17:01
nkindermorganfainberg: it seems like it would be easy to use that17:01
*** marcoemorais has quit IRC17:02
nkindermorganfainberg: it would also be possible to tell that to mask the token17:02
morganfainbergi'll work on fighting that next bit of the battle once we get this stuff settled i think :)17:02
morganfainbergi need to take a look at what jaimielennox is doing to see what will be needed for the response data. but yeah shouldn't be too bad17:03
ayounghrybacki, no17:04
ayounghrybacki, when a new request comes in, regardless of whether the token is cached or not, we need to check to see if the associated token is revoked17:05
hrybackiayoung: got it17:05
morganfainbergnkinder, i added you to both ksc and keystone changes for this part of token obscuring17:06
*** erecio has quit IRC17:06
ayounghrybacki, you good?17:07
hrybackiayoung: am I reading this wrong or does the revoked_list only get checked against cached tokens requests?17:07
ayounghrybacki, it gets checked elsewhere17:08
ayoungwe only check explicitly on revoked tokens there. but...17:08
ayoungself.verify_pkiz_token(user_token, token_ids17:08
morganfainbergdstanek, you're saying just ensure that we never exceed passlib's max here: ? part of the concern was that someone could set passlib (env var?) to a different value that the configuration.17:08
ayounghrybacki, and comparable for the others.17:08
hrybackiah, got it.17:09
ayounghrybacki, have the opportunity to unify the call for this code17:09
*** erecio has joined #openstack-keystone17:09
morganfainbergdstanek, so you would advocate that we just say 'max is passlib max even if the operator set it to > than passlib max?17:09
ayoungthe difference is that when revoking by ID, you do not need to unpack the token first17:09
hrybackiayoung:  in is_signed_token_revoked() ?17:09
ayoungso...make the config option for revocation_events skip the failure logic in17:09
*** marcoemorais has joined #openstack-keystone17:10
ayounghrybacki, it all resolved to calls to _is_token_id_in_revoked_list(token_id):17:10
ayounghrybacki,  so make the config option skip the check in that function17:10
ayoungand then add an additional function that checks if the token is revoked via the events.17:11
ayoungOr...refactor the code first, so that you can swap it out in a single place17:11
ayounghrybacki, ^^ might be a good first step:  just make sure all of the existing unit tests run and you should be able to refactor17:12
hrybackiayoung: thanks, on it!17:12
nkindermorganfainberg: ok, great.  I'll review them.  I've looked over one of them, but I want to go through it in more detail.17:12
* ayoung trying to remember why that is a list17:12
morganfainbergnkinder, ++17:12
ayounghrybacki, ah...ok17:13
ayoungyou don't need to worry about multiple token_ids for evetns17:14
ayoungbecause that is dealing with MD5, sha1, sha256 whatever hashing algorithm is used for the token17:14
dstanekmorganfainberg: yes, because it's not possible to go higher even if they want that ability17:17
morganfainbergdstanek, the concern in the original ticket was someone would set passlib to 1, and then all passwords are truncated to 1, even if the keystone option was set to say 50.17:18
*** PritiDesai has joined #openstack-keystone17:18
*** mfisch has quit IRC17:18
morganfainbergdstanek, i don't mind making those two always in lockstep (well if passlib < keystone configured length)17:18
morganfainbergperhaps a warning issued at the same time?17:19
dstanekmorganfainberg: right, but your fix is to catch the case where keystone is configured to allow a password bigger than what passlib allows17:19
dstanekmorganfainberg: i was just saying that we should cap that number using oslo.cofig17:19
morganfainbergdstanek, correct. i was solving it from a "give reasonable feedback vs ISE" w/o changing the truncation length17:19
morganfainbergis .. that even doable?17:20
dstanekmorganfainberg: yes, integers in oslo.config can have a max value17:20
marekdafter the authentication I get *something* in the HTTP header, hidden under 'X-Subject-Token', and a JSON in the response's body. Which should be called a 'token'?17:20
morganfainbergdstanek, hm. so you'd just say max=passlib.whateverthatpropertyis?17:20
dstanekmorganfainberg: you may be to specify the type, i don't recall17:21
*** gokrokve has joined #openstack-keystone17:22
morganfainbergdstanek, i'll look at it.17:22
*** gyee has quit IRC17:23
ayoungmorganfainberg, dstanek  that was just made public.  Can you guys move that along?  Still waiting on the jenkis run for the backports17:24
dstanekmorganfainberg: yeah, pretty sure we can just add a max since we are using an IntOpt17:25
dstanekayoung: sure17:25
morganfainbergayoung, no changes in the code from the bug ticket right?17:25
morganfainbergayoung, it looks the same17:25
morganfainbergayoung, +2.17:26
ayoungmorganfainberg, only reason the hash is different is because of rebase17:26
morganfainbergayoung, didn't even look at the hash17:26
morganfainbergayoung, was looking at the change and didn't see any differences.17:26
morganfainbergayoung, but wanted to 2x check w/ you17:26
ayoungmorganfainberg, I actually did a git am of the patch to make sure I knoew I was getting the right version17:26
morganfainbergayoung, ++17:26
*** topol has joined #openstack-keystone17:27
topoldolphm, you there?17:27
dolphmtopol: o/17:29
*** nsquare has joined #openstack-keystone17:30
*** rwsu has quit IRC17:30
*** praneshp has joined #openstack-keystone17:31
*** rwsu has joined #openstack-keystone17:32
topoldolphm, so how good does my audit spec need to be by end of today?17:33
dolphmtopol: you don't have a deadline on that today17:33
topoldolphm, cause folks wants details that I thought we would do iteratively17:33
topoldolphm, whats my deadline?17:33
dolphmtopol: juno-3?17:33
topoldolphm, you always cut me slack :-)17:33
topoldolphm, what has a jun-1 deadloine? api changes17:34
*** marcoemorais1 has joined #openstack-keystone17:34
*** marcoemorais1 has quit IRC17:34
dolphmtopol: api-impacting changes have a deadline of juno-217:34
*** marcoemorais has quit IRC17:34
dolphmtopol: so unless you want to make the argument that notifications are a first class API ... in which case i'd agree with you ...17:34
*** marcoemorais has joined #openstack-keystone17:35
topoldolphm, Im good with juno3 and will stop asking questions ... :-)17:35
dolphmtopol: juno-1 isn't normally a major milestone, but things like refactors and deprecations typically land before then17:35
dolphmtopol: aim for juno-2 :)17:36
dolphmtopol: 6 weeks!17:36
topoldolphm, will do!17:36
*** marekd is now known as marekd|away17:37
*** lbragstad has quit IRC17:39
tristanCHello folks! we are about to release an OSSA for Master and Icehouse patches are waiting for approval, but then havana backport have a unit-test failure on TestTrustAuth.test_delete_trust_revokes_tokens17:39
uvirtbotLaunchpad bug 1324592 in keystone "[OSSA 2014-018] Trust scope can be circumvented by chaining trusts (CVE-2014-3476)" [Critical,In progress]17:39
*** mfisch has joined #openstack-keystone17:42
*** mfisch has quit IRC17:42
*** mfisch has joined #openstack-keystone17:42
*** rodrigods_ has joined #openstack-keystone17:44
morganfainbergayoung, you looking at ^ or want me to?17:44
ayoungmorganfainberg, the test failure?  I'm on it17:46
morganfainbergayoung, ++ k17:46
ayoungmorganfainberg, I thought I had addressed that one, basically the test is failing in setuop, as sokmething that was legal before is no longer legal17:46
ayoungAppError: Bad response: 404 Not Found (not 200)17:46
*** afazekas has quit IRC17:47
*** lbragstad has joined #openstack-keystone17:49
*** leseb has joined #openstack-keystone17:49
*** rodrigods_ has quit IRC17:50
*** sbfox has quit IRC17:52
ayoungmorganfainberg, ah...somehow had bleedover from later patches:   was testing against the revoke events...sloppy backport17:54
*** leseb has quit IRC17:54
*** stevemar has quit IRC17:54
*** daneyon_ has quit IRC17:55
morganfainbergayoung, doh! I thought i ran this against my local system when i reviewed it17:57
ayoungmorganfainberg, same here...there was some ugliness with running specific unit tests due to the _   issue from excpetions, but I didn't see that this time.  I was pretty certain I did a complete run.17:57
morganfainbergayoung, i guess it happens at least we can solve it quickly17:58
ayoungmorganfainberg,  has +1 from jenkins17:59
morganfainbergdstanek, i'm not seeing where i put the max value for an IntOpt17:59
morganfainbergayoung, +1 on that from me.17:59
*** sbfox has joined #openstack-keystone17:59
dstanekmorganfainberg: jas, looking17:59
morganfainbergdstanek, what i'm seeing is we initialize the opt, but don't set any of the values for the type. (the type can have min/max)18:02
*** jsavak has quit IRC18:05
*** praneshp_ has joined #openstack-keystone18:05
*** jsavak has joined #openstack-keystone18:06
*** praneshp has quit IRC18:06
*** praneshp_ is now known as praneshp18:06
*** nsquare has quit IRC18:08
dstanekmorganfainberg: getting you an example now18:10
*** stevemar has joined #openstack-keystone18:11
*** nsquare has joined #openstack-keystone18:11
*** openstackgerrit has joined #openstack-keystone18:13
*** leseb has joined #openstack-keystone18:13
*** leseb has quit IRC18:14
morganfainbergdstanek, thanks!18:14
*** leseb has joined #openstack-keystone18:14
dstanekmorganfainberg: doesn't seem to enforce it - i may have to dig a little deeper18:14
morganfainbergdstanek, the min/max code looks a little odd18:15
*** jsavak has quit IRC18:15
*** leseb has quit IRC18:19
ayoungdstanek, bknudson dolphm care to move this one along?   Its for the trusts backport
bknudsonayoung: I thought the embargoed fixes were typically just +Ad by ttx18:23
ayoungbknudson, Me, too18:24
ayoungtristanC, ^^ why is this go round different than in the past?18:24
bknudsonfor example,
bknudsonwe can't approve in stable anyways18:24
tristanCayoung: Well we prefer to release the OSSA once we are confident patches won't get reworked, so yes +A are kind of required18:27
tristanCayoung: and for stable, ttx is ready to approve18:28
*** jaosorior has quit IRC18:32
*** PritiDesai has quit IRC18:32
*** PritiDesai1 has joined #openstack-keystone18:32
*** erecio has quit IRC18:34
*** erecio has joined #openstack-keystone18:34
tristanCThanks you folks, this one went nicely :) After jenkins +1 the stable/havana patch, I'll send the OSSA!18:37
morganfainbergtristanC, great18:40
*** jsavak has joined #openstack-keystone18:51
openstackgerritA change was merged to openstack/keystone: Use code-block for curl examples
*** erecio has quit IRC18:53
*** devlaps has quit IRC18:58
*** erecio has joined #openstack-keystone19:03
*** radez_g0n3 is now known as radez19:05
hrybackiayoung: added config, refactored those methods, confirmed tests still work, and set up a mock test to call the new _is_token_in_revocation_events()19:07
ayounghrybacki, run  tox -epep819:08
ayoungand then19:08
ayoung tox -epy2719:08
*** nsquare has quit IRC19:08
ayoungif those both run clear, post what you have for review.19:08
ayounghrybacki, are you familiar enought with git ?   Make sure you commit what you have now.19:09
ayoungyou can always rewrite history before you post for review19:09
ayounggit status will show what you've modified19:10
ayounggit add  keystoneclient19:10
ayoungwill add the files you've modified.19:10
ayoungassuming you've changed nothing higher up in the tree than that...19:10
ayoungI often have some file from an IDE or something in the git root19:10
ayounggit commit and make sure the top line of the commit is a succinct summary19:11
ayoungin this case, something like19:11
ayoungcheck revocation by events in auth_token middleware19:12
*** Ackowa has quit IRC19:21
*** leseb has joined #openstack-keystone19:25
*** leseb has quit IRC19:29
*** PritiDesai1 has quit IRC19:30
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: Link to docstrings in using-api-v3
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: Imports to fix build warnings
dstanekmorganfainberg: so my idea for using oslo.config won't work - oslo.config can only validate options when you are first used19:50
*** praneshp has quit IRC19:52
openstackgerritHarry Rybacki proposed a change to openstack/python-keystoneclient: check revocation by events in auth_token middleware
*** radez is now known as radez_g0n320:07
*** leseb has joined #openstack-keystone20:15
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: Docstrings for usability.
bknudsontip of the hat to anyone who's ever actually gotten something to work with keystoneclient, since there's no docs20:17
bknudsondstanek: so use the config option20:17
*** boris-42 has quit IRC20:18
*** morganfainberg has quit IRC20:18
*** boris-42 has joined #openstack-keystone20:18
*** morganfainberg has joined #openstack-keystone20:18
*** sets mode: +o morganfainberg20:18
openstackgerritSteve Martinelli proposed a change to openstack/keystone-specs: Audit support for federation spec
dstanekbknudson: yeah, i was thinking that, but if felt strange20:25
bknudsondstanek: add a comment and it won't be so weird20:26
dstanekbknudson: i was hoping to do something like using changes in oslo.config like
dstanekbknudson: jas, i have it stashed20:26
bknudsondpaste is dstanek's paste?20:27
bknudsondstanek: that change makes sense to me20:28
bknudsonbut as dhellmann says, a plugin can add new config options.20:28
bknudsonso you'd have to find a spot to do it20:28
dstanekbknudson: no mine, just what i've always used20:29
dstanekbknudson: why would a plugin be loaded after the main server loop starts?20:29
bknudsonI don't think we have a case of this, but it could be loaded only when the endpoint is hit.20:30
dstanekas an architect that goes against my desire to have a system fail at the earliest possible point20:31
bknudsondon't you want the system to also only use what it needs to?20:33 stash isn't working anymore20:33
*** radez_g0n3 is now known as radez20:33
dstanekno, it leads to nondeterministic behavior20:34
dstanekif there is a chance for it to be used i would rather have it initialized so i know it will work20:35
*** openstackgerrit has quit IRC20:35
*** hrybacki has quit IRC20:35
*** praneshp has joined #openstack-keystone20:35
dstanekah, i still needed my oslo.config patch20:35
bknudsonmultithreading leads to nondeterministic behavior20:35
*** openstackgerrit has joined #openstack-keystone20:35
dstaneki can only eliminate what i can eliminate :-)20:36
*** marcoemorais has quit IRC20:36
*** nsquare has joined #openstack-keystone20:36
*** marcoemorais has joined #openstack-keystone20:36
dstanekbut that only works when oslo.config is fixed20:37
bknudsonwhat's wrong with oslo.config?20:37
bknudsonalso, where's the test?20:37
bknudsonreturn ValueError20:38
bknudsonthat's a good one20:38
bknudsonthanks, python20:38
dstanekto be fair in one of my paste's i return a list of exceptions20:38
bknudsonthere should be a generator for calling a bunch of functions and storing the exception20:40
*** gyee has joined #openstack-keystone20:42
*** __afazekas is now known as afazekas20:43
lbragstadso, to anyone using next-review... are the stackforge/puppet-keystone reviews included by default when projects = keystone,keystone-specs,python-keystoneclient ?20:47
*** dims_ has quit IRC20:47
openstackgerritMatthieu Huin proposed a change to openstack/keystone: PoC external auth using user mapping
*** bknudson has quit IRC20:50
*** erecio has quit IRC20:53
openstackgerritA change was merged to openstack/identity-api: Add detail to credential API documentation
stevemarbknudson, there are docs, doesn't jamielennox 's blog count as docs?20:59
openstackgerritOpenStack Proposal Bot proposed a change to openstack/identity-api: Updated from global requirements
*** gokrokve_ has joined #openstack-keystone21:02
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements
*** PritiDesai has joined #openstack-keystone21:04
*** gokrokve has quit IRC21:05
*** juanmo has quit IRC21:08
*** sbfox has quit IRC21:08
*** sbfox has joined #openstack-keystone21:09
*** PritiDesai has quit IRC21:14
*** PritiDesai has joined #openstack-keystone21:14
*** PritiDesai has quit IRC21:22
*** hrybacki has joined #openstack-keystone21:22
henrynashmorganfainberg: ping21:25
morganfainberghenrynash, pong21:26
henrynashhi, question on conceptual models for controller -> manager communication…..21:26
henrynash(this is for the multi-backend uuids)21:26
morganfainberghenrynash, sure thing21:27
henrynashwe need to change the current code since the controller creates a UUID for an ID for the user/group it is creating and then passes this to the manager layer - create_user(user_id user_ref)21:28
*** jsavak has quit IRC21:29
henrynashwhat I had planned was to make the manager responsible for ID generation….so the controller would just call create_user(user_ref) and the manager would put the ID in it, and then call the driver with the tradtional create_user(user_id, user_ref) API21:29
morganfainberghenrynash, this is the _assign_unique_id code, right?21:29
henrynashyeah, basically the controller would never call this for uses and groups21:29
morganfainbergyou could push the _assign_unique_id logic down a level21:29
henrynashindeed, so that’s the alternative...21:30
morganfainbergsounds reasonable, you probably can't remove the "id" bit from the controller21:30
henrynashteh controller could call a method in the manager to get the ID, then pass it back into the manager on the create cal21:30
morganfainberghenrynash, oh was thinking assignment not id21:30
morganfainberghenrynash, nvm /me was wrong21:31
morganfainberghenrynash, hm. or we could just break the identity_api.create_xxxx method's signature21:31
henrynashpushing the assign_id (for users and groups) into the manager is the smallest change….21:32
morganfainbergis there a reason we _ever_ would want something to create an id and have the identity_api blindly follow that? or we always want to control this.21:32
morganfainbergi'd probably push assign_id down to manager, tbh21:33
henrynashmy gut feeling is that if we are imlementing mapping in the manger layer, then this seems the layer that should own and assign the ID…..who knows what we might wnat to do with it in the future21:33
morganfainbergcontroller is more about web_request -> python data imo21:33
morganfainbergwe've made a concerted effort to move a lot of the buisiness logic down to the managers from the controllers21:34
morganfainbergi'm happy to continue with that pattern21:34
henrynashi quuite like teh controller passing the manager the ref (without an ID) and if teh create is succesful the ref returned has the ID in21:34
morganfainberghenrynash, i would also like to see the 'enabled' sanitization stuff move down to the manager as well then21:34
morganfainbergbasically controllers (imo) should be about converting web-requests to data structures and emitting sane serialized data21:35
*** hrybacki has quit IRC21:35
henrynashso in my follow on patch…I moevd the ID generation as described…the pnly issue is that I had to do a LOT of mechanical change sto all our unit tests (‘cause the assign an ID like ‘fake1’ and pass it to teh manager)!!!21:35
morganfainbergany/all extra business logic should be at the manager, so in the case extension wants to create a user... it works the same as if the controller does it21:35
morganfainberghenrynash, yep, lots of mechanical changes.21:36
morganfainberghenrynash, i would almost make that change the 1st of the string (if that makes sense)21:36
morganfainbergrestructure where id's come from, then layer in the multi-id stuff21:36
henrynashI’ll see how hard it is to pull all that apart….21:37
morganfainberghenrynash, does that make sense?21:37
henrynashsince there are some othe subtle unit test changes needed21:37
morganfainberghenrynash, i mean... happy to help you need any.21:37
morganfainberghenrynash, but it might be easier to invert it in this case. :)21:38
henrynashbut if we are agreed on the direction…then I’ll plan how we do it21:38
morganfainbergyeah. i think moving that down to the manager makes a ton of sense21:38
henrynashok, great…agreed21:38
morganfainbergfor the most part, controllers don't do multi-manager cruft anymore21:39
morganfainbergidentity controllers almost exclusively talk to identity_api21:39
morganfainbergi really like that.21:39
henrynashyep, me too21:39
henrynashcool..we have a plan21:39
morganfainberghenrynash, ++21:39
morganfainberghenrynash, i'll take up the follow-on moving all the enabled sanitization stuff down a layer if needed.21:39
henrynashi’ll update the spec as well, just to be clear what we are doing (and to say that sha1 will be teh only genrator)21:40
morganfainbergoh wait.. not that is already there. phew21:40
morganfainberghenrynash, ++ sounds great21:40
*** nkinder has quit IRC21:42
*** topol has quit IRC21:46
*** lbragstad has quit IRC21:50
*** radez is now known as radez_g0n321:50
*** hrybacki has joined #openstack-keystone21:54
*** kun_huang has quit IRC21:55
*** marcoemorais has quit IRC21:56
*** marcoemorais has joined #openstack-keystone21:56
*** dims_ has joined #openstack-keystone21:57
*** praneshp_ has joined #openstack-keystone21:57
*** jamielennox is now known as jamielennox|away21:58
*** einarf has joined #openstack-keystone21:58
*** praneshp has quit IRC21:59
*** praneshp_ is now known as praneshp21:59
*** PritiDesai has joined #openstack-keystone22:02
*** amcrn has quit IRC22:06
*** gordc has quit IRC22:07
*** stevemar has quit IRC22:11
*** PritiDesai has quit IRC22:18
*** rodrigods has joined #openstack-keystone22:19
*** andreaf has joined #openstack-keystone22:20
*** dstanek is now known as dstanek_zzz22:23
*** dstanek_zzz is now known as dstanek22:24
*** hrybacki has quit IRC22:26
*** hrybacki has joined #openstack-keystone22:29
*** gokrokve_ has quit IRC22:32
openstackgerritayoung proposed a change to openstack/keystone: Kerberos as method name
*** PritiDesai has joined #openstack-keystone22:36
*** leseb has quit IRC22:36
*** leseb has joined #openstack-keystone22:36
*** andreaf has quit IRC22:36
*** nkinder has joined #openstack-keystone22:37
*** thedodd has quit IRC22:39
*** rodrigods has quit IRC22:40
*** leseb has quit IRC22:41
*** gokrokve has joined #openstack-keystone22:46
*** ayoung has quit IRC22:49
*** PritiDesai has quit IRC22:49
*** PritiDesai has joined #openstack-keystone22:51
*** hrybacki has quit IRC22:52
*** hrybacki has joined #openstack-keystone22:56
*** rodrigods has joined #openstack-keystone22:57
*** rodrigods has joined #openstack-keystone22:57
*** dstanek is now known as dstanek_zzz22:59
*** hrybacki has quit IRC22:59
morganfainbergdolphm, been talking to sdague, looks like we're going to try this to help get us from 1 in 10k to like 1 in 100k+ hopefully it works.23:00
morganfainbergdolphm, ephemeral port.23:00
*** dims_ has quit IRC23:01
*** jamielennox|away is now known as jamielennox23:05
*** dstanek_zzz is now known as dstanek23:09
*** rodrigods has quit IRC23:16
*** amcrn has joined #openstack-keystone23:23
*** rodrigods has joined #openstack-keystone23:25
*** sbfox has quit IRC23:26
gyeemorganfainberg, just added my comment
*** praneshp_ has joined #openstack-keystone23:34
morganfainberggyee, ok so MD5 is the current default23:36
morganfainbergwe can't use that23:36
morganfainberggyee, and no one _really_ is expected to use SHA1 (bknudson even said he never expected a person to do SHA1) instead of Sha256 or so23:36
morganfainberggyee, Tokens are also not really "short lived throw away" at the moment. They last for 1hr default (and in a lot of environments longer). services do re-use tokens a good deal.23:37
*** praneshp has quit IRC23:37
*** praneshp_ is now known as praneshp23:37
*** richm has left #openstack-keystone23:37
morganfainberggyee, so we still want to know if the same token is used in debug, but we don't want to leak token ids to the world.  while the token is active it has roughly the same capabilities as someone using a username/password combo23:38 some cases you could even change your password with a token :P (think admin level and user update) causing a bigger issue if a lower-priv individual could grab the token id23:38
*** gokrokve has quit IRC23:39
morganfainberghonestly, if the default had already been sha1, i'd have picked md523:39
gyeemorganfainberg, I like the random salt idea23:40
gyeeyour original idea is much better I think23:40
morganfainberggyee, sure, but this is easier to communicate23:40
morganfainberg{sha1}<token id>23:40
morganfainbergpeople still want to be able to determine if it was _their_ token used, just not be able to derive someone else's token23:41
morganfainbergsay it's salted is saying "go look at the implementation and figure out the salt mechanism and then hash your token"23:41
morganfainberganyone who isn't content with md5 token hashes wont be content with sha1, it's considered broken by those who would care23:42
*** PritiDesai has quit IRC23:43
gyeemorganfainberg, but if we publish the salt value we should be fine right?23:43
morganfainberggyee, the complaint is the volume of documentation and headaches to explain it.23:43
gyeejust a matter of sha1(tokenid + salt)23:43
morganfainbergand i sortof agree.23:43
*** dstanek is now known as dstanek_zzz23:43
gyeemorganfainberg, "debug" message are reviewed by technical guys23:43
morganfainbergi'd rather it be dead simple to hash the id23:43
morganfainberghey it's just a sha1 of whatever your token is.23:43
morganfainbergright now debug kinda = what verbose should be in openstack23:44
morganfainbergcould be used for a deployer vs a developer23:44
morganfainbergdebug should _probably_ be developer only, but we're not there yet23:44
gyeewith the money technical guys making these day, they better damn sure how to handle a simple salt value :)23:44
morganfainberggyee, it's a communication issue. i already was receiving pushback from people (technical) on it being not a dead simple sha123:45
gyeeits a simple salt scheme23:45
morganfainbergi asked brant, and he basically said why would anyone who cares it's MD5  use Sha1?23:45
morganfainbergif md5 isn't good enough, neither will sha1 be23:45
morganfainberganyone who cares will use sha25623:46
gyeeexcluding sha1 in cms just for that reason doesn't seem right23:47
*** leseb has joined #openstack-keystone23:47
gyeeor any hash algorithm in that matter23:47
morganfainbergand i'd argue that we should have said you can have MD5 or sha25623:47
morganfainbergand not make it "any hashing you want"23:47
*** xianghui has quit IRC23:47
morganfainbergbecause anyting > sha256 will break SQL token backend :P23:48
morganfainbergand anything less than sha256 is widly considered insufficient for anyone who cares.23:48
uvirtbotLaunchpad bug 1329554 in keystone "Setting token hashing to sha512 will not work with the SQL token backend" [Medium,New]23:48
morganfainbergthere fixed the description23:49
gyeewell, sha1 is still widely used23:49
morganfainberggyee, sure, but not in the cms system23:49
morganfainbergwe have23:49
morganfainbergwe still use MD5, and MD5 is the default23:49
morganfainberg*shrug* i really don't want to fight a ton to get a simple "lets not leak privileged information out" and there is already acceptance for obscuring with sha123:50
morganfainbergand there is already code in the wild (novaclient) that does sha1 (committed)23:50
gyeesure, but with that patch, we basically excluded sha1 in cms23:51
gyeebad tradeoff IMO23:51
morganfainberggyee, ok, besides principal, who cares if we eliminated sha1?23:51
*** leseb has quit IRC23:51
morganfainbergs/principal/on principle/23:52
gyeemorganfainberg, dunno, maybe somebody from distribution list will tell us23:52
morganfainbergso far dev list has been insupport of this (when not complaining that they can't copy-paste the curl line from the message)23:53
gyeetry putting a PKI token in curl and see how much fun it is :)23:53
morganfainbergyou still can copy/paste the line from the debug message23:54
morganfainbergit just sucks :P23:54
morganfainberghey my first pass was basically saying --REDACTED--23:54
morganfainbergbut people want to know if a token has been used across muliple requests23:54
gyeeI really like the salted hash idea, that solution have little risk23:55
gyeelog aggregation is usually done by a script anyway23:56
morganfainbergdoesn't mean token ids should be in them23:57
gyeemorganfainberg, anyway, not trying to make a big deal because it is not, but given up sha1 just for log sanitation sound like a bad tradeoff23:57
morganfainberglogstash, rsyslog, splunk, etc23:57
morganfainberggyee, i'd agree if i wasn't told at every corner that sha1 sucks (by the crypto folks) and that we shouldn;t use it for anything because it's "broken".23:58
*** sbfox has joined #openstack-keystone23:58
gyeemorganfainberg, what I mean is we can easily do the token ID hashing in scripts to look for a match23:58
*** sbfox has quit IRC23:59

Generated by 2.14.0 by Marius Gedminas - find it at!