18:01:49 #startmeeting keystone 18:01:50 Meeting started Tue Apr 8 18:01:49 2014 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:51 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:53 The meeting name has been set to 'keystone' 18:01:59 o/ 18:02:00 #topic Reminder: Design summit session proposals open until April 20th 18:02:11 o/ 18:02:28 so, we've got 21 proposed sessions the last i counted, and i'm aware of two more that are on their way to being proposed 18:02:36 we have 8 timeslots at the summit. 18:02:52 we need a longer summit 18:02:58 bknudson: i don't think we do :) 18:03:12 by my count, we should be able to fill those 8 nicely, by merging them 18:03:21 several proposals are near dupes, or closely related 18:03:22 i haven't proposed anything related purely to keystoneclient (or seen anyone else do it) - i take it we are expecting one/ 18:03:34 jamielennox: please do! 18:03:52 jamielennox: i'm planning for *something* client side to be one of those 8 18:04:07 ooh we got 8 slots? 18:04:09 dolphm: i have less that is related purely to keystoneclient rather than all clients, but i'll propose and people can add to it 18:04:21 is one of the slots for the deployer feedback? 18:04:29 jamielennox, keystoneclient seems like a good fit for cross-project, from integration standpoint 18:04:35 we should also have some dedicated space in the dev-lounge type area, so we can take certain topics there as well for smaller discussions 18:04:48 bknudson: so far, yes 18:05:10 gyee: cross-project track deadline is this week 18:05:12 for proposals 18:05:13 client, tokens, Federation (and LDAP) , Hierarchy (to include Policy), 18:05:24 gyee: i did one that was cross-project: http://summit.openstack.org/cfp/details/205 18:05:32 bascially, I made a bunch of proposals that were supposed to be buckets 18:05:44 (i need to do a better job of wording it) 18:05:46 Didn't make a client one 18:06:13 if there's not actual items that need to be designed / discussed, it won't be worthy of a session 18:06:16 Tokenless Keystone Operations that one was for gyee 18:06:26 client * middleware, especially middleware, auth_token is screaming out for refactoring 18:06:26 so a bucket alone isn't worth consideration without meaningful topics to fill it 18:06:46 gyee: "refactor" isn't something we need to fuss over at the summit, either 18:06:52 we were going to pull middleware to its own repo? 18:06:54 gyee: oh there is plenty to do on the client - it's just what really needs discussing 18:07:04 bknudson: that came up somewhere recently as well 18:07:19 bknudson, was goign to bring that up specifically at the end of the meeting today since we're early in a cycle we could do it. 18:07:22 bknudson: there's clearly some desire to - i'd be worried that we'd have to create a fourth repo as well, for things like cms 18:07:22 dolphm, right...those were the ones I knew we had something to talk about...feel free to close mine if there is a comparable other submission that is more explicit 18:07:26 dolphm, jamielennox, I would like to see auth_token not putting stuff in the headers anymore 18:07:36 should stash them into the environ 18:07:43 we'd end up with keystone, python-keystoneclient, keystonemiddleware, and keystonelib or something 18:07:48 dolphm: I don't think we've got a circular dependency 18:08:03 dolphm, that isn't a bad breakdown imo 18:08:07 python-keystoneclient, would be deprecated, as we are moving to unified cli? 18:08:09 ohh, I guess keystoneclient would import middleware until it's moved. 18:08:19 bknudson, ++ 18:08:26 everything would depend on keystonelib in that breakdown 18:08:44 ayoung: not yet; it'd be deprecated by python-openstacksdk if anything 18:08:45 dolphm: what would keystonelib be as seperate from client? 18:08:47 although I might suggest that keystonelib should be keystoneclient, if only to keep the git history 18:08:57 jamielennox: keystone.common.cms for example 18:09:01 because if it's session and auth plugins then it's more generic that that 18:09:17 sounds like we're having the client design session now :) 18:09:22 wouldn't python-keystone client still be required since it is used but the unified client? 18:09:27 pretty much - this is a worthwhile summit session :) 18:09:30 stevemar, yes sir indeed 18:09:31 jamielennox, anything that is common between client and keystoneserver I would think 18:09:39 lbragstad, yes, but it wouldn't be the same as the CLI it currently is 18:09:45 ok - i'll put up a summit session for client today 18:09:47 lbragstad: yes, if/until it's replaced by python-openstacksdk 18:09:52 jamielennox: thanks 18:10:04 morganfainberg: dolphm ok, makes sense 18:10:10 We also have cross-project summit sessions, right? 18:10:15 ayoung: yes 18:10:36 http://summit.openstack.org/cfp/details/95 is Python OpenStack SDK. 18:10:55 dolphm, who make the decision on x-project sessions? PTLs? 18:10:55 http://summit.openstack.org/cfp/details/205 is Jamies 18:11:05 python-*client standardization 18:11:06 gyee: good question, i'm not sure 18:11:14 ayoung: there's also the one that jamielennox already mentioned (http://summit.openstack.org/cfp/details/205) 18:11:28 gyee: i don't even have access to moderate keystone sessions yet - it's still too early 18:11:28 nkinder, beat ya too it 18:11:30 I'm hoping/assuming that there will be plenty of -sdk talk, i still haven't figured out what they want to be 18:11:30 heh 18:11:55 gyee: probably, yes, though 18:11:59 jamielennox: from the latest discussion sounded like the current clients just in one lib 18:12:00 dolphm, k, please update us if you have more info on that, I'll try to dig around too 18:12:17 jamielennox: i think "everything to everyone" is the answer :-/ 18:12:54 We might be able to punt on a Keystone specific talk in favor of "Hierarchical Multitenancy in Every Project" 18:13:00 openstacksdk has a loonnnggg ways to go 18:13:06 gyee: in the mean time, comment on sessions you're interested in, or not. feedback on summit.openstack.org (and the mailing list, etc) is really important for the whole selection process 18:13:14 bknudson: yea i have been following but they are talking dolphm's everything approach and i don't think it's sustainable 18:13:32 dolphm, thanks, will do that this week 18:14:17 that's also why it's too early to make too many guesses about what sessions will be accepted/merged/rejected -- there's not enough feedback yet for many sessions, and there are yet-to-be-proposed sessions to consider as well 18:14:49 on that note ... 18:14:51 moving on :) 18:14:54 #topic Reminder: Review Icehouse release notes 18:15:07 just a quick reminder to take a pass at: 18:15:08 #link https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse 18:15:21 there's been a few things added, and there's a few TODO's noted that need to be fleshed out 18:15:29 if you're familiar with those features, contributions very much welcome :) 18:15:40 most of them are in Upgrade Notes 18:15:46 dolphm, do contribution have to pass a bknudson code review? 18:15:54 ayoung: yes? 18:16:01 only ayoungs... 18:16:10 topol, ++ :P 18:16:27 I will probably fix speling errors if I see them. 18:16:49 i'll fix wiki syntax :P 18:16:53 bknudson, urban dictionary words ok? 18:16:57 any TODOs that are egregious? 18:17:03 so is there just a place toa dd comments on the wiki or we all have edit access? 18:18:10 ayoung: see for yourself? nothing crazy IMO 18:18:25 dolphm, yeah, nothing jumped out at me.... 18:18:26 topol: everyone should have edit access with an LP account 18:18:34 s/an/a/ 18:18:54 anyway, let's talk about something more exciting! 18:18:57 #topic Security review 18:18:57 dolphm, K 18:18:59 nkinder: o/ 18:19:32 nkinder: have a link to your mailing list discussion? i'm coming up empty handed 18:19:43 dolphm: sure... 18:20:13 http://lists.openstack.org/pipermail/openstack-dev/2014-April/032046.html 18:20:20 nkinder: thanks! 18:20:34 nkinder: i noticed that the wiki page was showing the source of algorithms as passlib. is that intentional? passlib actually uses the hashlib implementation if I remember correctly 18:20:35 hopefully everyone saw this, this is obviously a worthwhile effort :) 18:20:50 dstanek, that rings true 18:20:53 dstanek: PassLib does both 18:21:11 I read the code, and they implement their own rc4, etc. 18:21:18 ...but they do use hashlib too 18:21:23 http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/utils.py#n26 18:21:36 i don't think they implement sha* though 18:21:46 dstanek: correct 18:21:52 http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/utils.py#n110 18:22:03 sha512 18:22:17 for the "Potential improvements" -- we're not planning to do those for icehouse? 18:22:18 and http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/utils.py#n125 18:22:40 http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/utils.py#n117 salted sha is ugly, but necessary for the LDAP simple bind approach. Ideally, that would be replaced, but I think the only viable alternative is Kerberos 18:22:48 nkinkder, is this an OSS initiative? 18:22:58 dstanek: perhaps it's not clear, but I was trying to point out that sha1 is used by PassLib (not necessarily implemented by) 18:23:01 bknudson, we are plannign on imporvindg from Eventlet to Apache HTTPD 18:23:13 ok, let's talk about it at a high-level instead of specific crypto details 18:23:15 dstanek: passlib does use hashlib, for example https://code.google.com/p/passlib/source/browse/passlib/handlers/md5_crypt.py 18:23:42 I'm trying to get projects interested in gathering and maintaining this sort of info from release to release 18:24:05 nkinder, ++ 18:24:06 nkinder: ++ oslo has a bunch of stuff too.. which may or may not get used in other projects 18:24:09 This is useful for OpenStack deployers of course, but it's also really good from a development standpoint 18:24:09 nkinder: is there any reason why this shouldn't be tracked in tree, and code reviewed along with the impacting changes? 18:24:09 ldap_hash_password ... I assume that was only called if you create a user via the LDAP backend, which is not someth8ing I would expect a real deployment to do, but I've been surprised before. 18:24:38 Instead of just saying "we should all do this", I audited Keystone myself first to show how I think it might look. 18:24:53 dolphm: in doc/source ? 18:25:06 bknudson: yes. nkinder: wiki sounds like a decent place to get these docs moving, but we can enforce their maintenance in gerrit 18:25:08 dolphm: in tree is fine too 18:25:17 I like that 18:25:24 me too, 18:25:25 dolphm: so first I want to see if there is interest from each project. Sounds like there is for Keystone. 18:25:30 nkinder++ that is an important initiative youa re driving 18:25:40 Second is what form should the info be kept in (in git, wiki, etc.) 18:25:43 people are always asking for this info 18:25:50 nkinder: absolutely, it sucks not being able to refer people to docs like these :-/ (until now!) 18:25:56 wiki seems good enough for now 18:25:58 anyone can screw with the wiki, so it's not the best place for authoritative info 18:26:04 yeah, good for now though 18:26:09 tree is good for some stuff - but if you continue down this track we'll have a while bunch of attack vectors we need to document 18:26:27 dstanek: that's an interesting point... 18:26:31 there's another effort for the threat analysis 18:26:39 Security bugs got in Launchpad until we have a fix, obviously 18:26:49 yeah, this is more of a high-level instead of a full threat analysis 18:26:54 this effectively becomes a release deliverable if it's in-tree, rather than a best-effort community thing 18:27:07 so far this is really just code level implementation, but i can see whating to document lots of other stuff too 18:27:08 dolphm: well, I'd like to make it a release deliverable 18:27:09 I think it would be important to keep it simple right off the bat, description of why we need the encryption, names of the hashes used, maximum key length/strength, is it end user configurable? 18:27:12 dolphm, good point 18:27:16 "go in" man my typing is worse than usual today 18:27:23 lbragstad: +1 18:27:30 something in a chart form 18:27:34 it'll be available here if in doc/source -- http://docs.openstack.org/developer/keystone/ 18:27:37 Keep it simple so we can actually acheive the goals 18:27:44 lbragstad ++ 18:27:45 It would be nice if we had ethercalc for charts 18:27:48 someone can look up if pycrypto is used, and if an end-user can bump up the key strength 18:27:57 lbragstad: keeping it simple in the long run is important for maintainability :) 18:28:09 nkinder do we have any provenance information on what crypto libraries are used and who dveeloped them? 18:28:13 The tables shoudl really say what is used, and why (by what feature) 18:28:17 dstanek, even if it's in tree, it's not like we don't neglect the docs :( 18:28:30 stevemar: :-) 18:28:49 topol: all we really have is what I've collected on that page so far 18:28:55 nkinder, K 18:28:57 what about something under Anne Gentle's team instead of under keystone? Seems like a cross product doc effort? 18:29:11 ayoung: for publishing, that would likely work 18:29:15 there's a security guide... 18:29:18 in-tree would probably be fine, but i can definitely see things that audit logs and other artifacts out of tree 18:29:24 s/that/like/ 18:29:24 ayoung: they're already responsible for publishing keystone/docs 18:29:35 ayoung: but each project should own the info on their own project and keep it up to date as code changes are made 18:29:37 http://docs.openstack.org/security-guide/content/ 18:29:44 then lets do it in tree 18:29:44 nkinder: ++ 18:29:47 nkinder: right, 18:30:04 We can then use that info to populate the Security Guide if we want to provide an overview of used crypto 18:30:21 ok, so in tree it is. Any suggestions on format? 18:30:30 does anyone have any criticism of what's available on https://wiki.openstack.org/wiki/Security/Icehouse/Keystone currently? 18:30:31 markdown? something else? 18:30:44 dolphm: I do :) 18:30:46 nkinder: docs/ uses RST already 18:30:55 dolphm: some things are missing or need to be filled in more 18:31:30 dolphm: but we can discuss those on IRC outside of this meeting 18:31:44 nkinder: i'd like to see Potential Improvements filed as Wishlist bugs and tagged with 'security' 18:31:55 nkinder: when do we plan to have a format up? 18:32:14 dolphm: great idea - i'll start posting those after this meeting 18:32:16 nkinder: you can then link this doc to https://bugs.launchpad.net/keystone/+bugs?field.tag=security - rather than duplicating those in the doc 18:32:21 So the other thought is that we can use the security-impact keyword to flag when a code change requires an update 18:32:32 idea are flooding in :-) 18:32:46 dolphm: +1 on filing the improvements. Those were just items that I had ideas on, so feel free to chime in with others. 18:33:03 nkinder: i'd rather the code change include the doc update AND include SecurityImpact ;) 18:33:07 lbragstad: I can work on a format, though I'm not familiar with RST 18:33:24 dolphm: yes, both in one patch would be ideal 18:33:32 nkinder: here's the link I use -- http://docutils.sourceforge.net/rst.html#user-documentation 18:33:34 nkinder: ok, cool. I can help out with that too. 18:33:36 dolphm: then we can -1 changes that skipped updating the doc. 18:33:44 nkinder: ++ 18:33:48 lbragstad: that would be much appreciated 18:34:15 did most of my audit look accurate to everyone? Is there anything important that I missed? 18:34:22 lbragstad: we've got scans for the other projects, too? 18:34:42 bknudson: not yet. I need to go around and evangelize that... 18:35:01 nkinder: only thing confusing to me where what implementation was used for algorithms 18:35:12 other than that i thought it was great 18:35:19 bknudson: I'm really hoping to get buy-in from everyone such that this can be a part of our normal release process 18:35:29 hrm, i also just realized this encompasses both keystone and keystoneclient (and some of this would be moved to keystonelib if that existed) 18:35:30 nkinder++ 18:35:35 dstanek: any suggestions on how it could be represented to be more clear? 18:35:41 nkinder, as I mentioned before, the "Self signed certificates" approach needs to die 18:35:52 dolphm: yeah, they are kindof wrapped together 18:36:21 nkinder: i can't tell if we are using three different sha1 implementations or if there are three different wrappers to the same implemenation 18:36:27 dolphm, whys that an issue? 18:36:31 nkinder: this one wiki page should be split into python-keystoneclient/docs and keystone/docs then -- and probably cross-linked to each other since they're so closely related 18:36:41 stevemar, auditability 18:36:42 dstanek: ah, yeah. The wiki table made that odd. 18:36:46 stevemar: because a client change shouldn't require docs in the keystone/ repo to be updated, for example 18:36:59 you want to make sure that, if there is an known issue in an implementation, you've updated the vulnerability 18:37:00 dstanek: it's all just sha1 (hashlib), but it was for threee different usages 18:37:07 we'll probably have a lot of duplication 18:37:12 updated beyond the vulnerability 18:37:28 stevemar: in what regards? between projects? 18:37:57 if we split the wiki contents to keystone/docs and keystoneclient/docs 18:38:18 stevemar: yeah, that's why I avoided it and just called out the source files. 18:38:49 ...but it's going to have to be split if we keep the docs in tree 18:39:04 i guess so :) 18:39:19 can we backport doc updates? 18:39:27 ok, well next steps seem to be to work on the formatting, then we can decide how to organize it between repos. 18:39:36 nkinder: yeah, something like that works 18:39:40 bknudson: yes 18:39:53 bknudson: not sure if they'd be consumed that way though 18:40:11 dolphm, rc2 window is closed, right? 18:40:15 dolphm, whats the criteria for backporting doc updates? Just critical; stuff? 18:40:21 ayoung, yes 18:40:23 ayoung: yes 18:40:33 we can use wiki for Icehouse, and in-tree for Juno 18:40:35 dolphm, when do we expect rc2 announced, then? 18:40:49 Icehouse will largely be going back and reviewing what we've already done anyway 18:40:55 I don't know if we can get to havana keystone developer docs. 18:40:59 topol: there's no precedence in keystone, afaik - but i'd happily propose doc corrections & additions to stable-maintenance 18:41:19 ayoung: it was released this morning 18:41:23 http://docs.openstack.org/havana/ just links to http://docs.openstack.org/developer/keystone/ 18:41:27 Ah... 18:41:31 need to catch up on email 18:41:32 ayoung: i meant to mention it at the beginning of the meeting, but forgot to put it on the agenda 18:41:44 bknudson: mostly the keystone docs are common and embedded 18:41:44 ayoung: http://lists.openstack.org/pipermail/openstack/2014-April/006468.html 18:42:00 bknudson, then no need to backport! 18:42:15 bknudson: http://docs.openstack.org/admin-guide-cloud/content/ch-identity-mgmt-config.html 18:42:17 So....that is probably Icehouse.... 18:42:32 bknudson: oh sorry you're talking about dev docs 18:42:45 annegentle: ++ 18:43:01 annegentle: well, we had discussed whether to put the security notes in dev docs or other docs. 18:43:19 annegentle: yeah, this is security guide related as well. 18:43:27 annegentle: we're discussing backports for openstack/keystone/docs to stable/ branches, for the purpose of documenting security-relevant topics 18:43:42 annegentle: we're talking about having some security info from each project feed into the Security Guide. 18:43:47 annegentle: (for docs that don't exist in-tree yet, just on the wiki) 18:43:47 ah you won't get point-in-time publishing of dev docs 18:43:59 nkinder: cool, great. 18:44:17 annegentle: are you aware of any distros or anyone doing anything with stable/ dev docs? 18:44:35 dolphm: the only stable/relname docs are in openstack-manuals and it's just the install guide and the config ref. We could add the security guide though, just a matter of deciding on it 18:44:45 annegentle: I can chat with you offline about the idea to get your recommendations on the best way to do that from a format perspective (it's sort of the same thing we need to figure out for OSSNs). 18:44:54 nkinder: sure 18:45:20 annegentle: ok, I'll shoot you an e-mail on it. 18:45:20 I like the dev docs because it's easy to update with the code. 18:45:27 also, we can look at them on github 18:45:29 ++ 18:45:35 bknudson: +1. It will help to keep it in sync 18:45:39 bknudson: but security affects all of openstack and is more of an integrated project set of issues 18:45:45 bknudson: ++ 18:46:03 bknudson: nkinder: prioritization and discipline around it keeps it in sync 18:46:06 I do want to see what other projects think as well, as they may have different ideas 18:46:40 annegentle: well, I also like the security guide because it's going to be consumed outside of developers 18:46:50 nkinder: if they have better ideas, please share :) 18:46:57 nkinder: definitely bring this up at the barbican meeting as well :D 18:47:01 ++ 18:47:02 dolphm: will do! 18:47:21 I'm happy to see all of the interest in it! 18:47:37 sounds like we have some agreement here for now, and there's nothing left on the agenda for today, so: 18:47:43 #topic open discussion 18:48:02 12 free minutes 18:48:03 Quick plug 18:48:17 sql collapse: https://review.openstack.org/#/c/78169/ this needs some feedback on the fk/constraint/index naming etc 18:48:52 +395, -4758 18:48:58 morganfainberg: i wanted to run db_sync 36 with and without that patch on mysql & postgres prior to +2'ing -- have you done either of those and compared sqldumps? 18:49:01 i'd like to implement consistent naming across the board, which requires a migration to sync all prodiuction deployments, but i want to get it right in that review as the base 18:49:04 bknudson: auto +2 18:49:16 dolphm, i did that when developing this. 18:49:31 dolphm, but... the FK / constraint / etc names are difference 18:49:41 and with SQLA and postgres there are oddities that require explicit naming 18:49:45 morganfainberg: if you have a diff handy, could you paste one? 18:50:01 dolphm, i'll need to re-run it, the diff came pre icehouse 18:50:06 dolphm, so i'll re-run and post the diffs 18:50:16 i have a request for some client reviews please - they are stagnating again, we are back to the point where there are a few difficult ones to process so come find me if you are unsure of any reasoning 18:50:22 morganfainberg, whats the magic that allows you to compress so much??? 18:50:36 topol: dropping support 18:50:37 re-reading that it was way to gentle: do client reviews! 18:50:48 jamielennox, i expected less gentle this time :P 18:50:50 morganfainberg, did you run that against livetests for both mysql and postgresql? bknudson can one of you IBMers confrim the DBishness of that smooshing? 18:50:51 topol: for essex and folsom 18:51:06 dolphm, thats awesome. so much less code to look at 18:51:13 topol: and less to maintain! 18:51:14 ayoung, i had no issues with the migrations working under mysql and postgres, that seems like all the _live_tests do 18:51:21 jamielennox, I'll take a look 18:51:33 dolphm, I may actually look in that folder now :-) 18:51:35 I also commented on the configurable hash algorithm review https://review.openstack.org/#/c/80401/ 18:51:35 topol: this also means faster tox run times :) 18:51:38 ayoung, but before i went too much further i wanted to snag people for the FK / ix / ixu naming 18:51:40 topol: ha 18:51:48 morganfainberg, yeah....need to take another look at getting out sql unit tests running against the real databases again 18:51:49 we need to embed the algorithm into token data 18:51:56 ayoung: I'll try it out with my db2 setup. 18:52:05 has anyone run the unit tests against mysql? i was having a bunch or problems with it 18:52:05 dolphm, not much faster. we don't migrate for most tests now we use sqlite reflection in memory 18:52:09 morganfainberg, FK naming should be in a DBMS specific manner, I think 18:52:19 dstanek, I have not tried in over a year 18:52:21 gyee: I'll take a look at embedding the algorithm. 18:52:29 gyee: why is that necessary? 18:52:31 ayoung, except that we can't use reflection if needed to interact with it then 18:52:36 we need to keep a record of the patch that replaces a huge chunk of code with a smaller replacement. And that person gets a prize every release 18:52:41 jamielennox: you need more of a mean-streak... ;) 18:52:44 ayoung, mysql would be _ibfkXX posgres is _fkey, etc 18:52:49 bknudson, otherwise, it will break rolling upgrade 18:52:50 bknudson: you don't seem to be impacting /v3/OS-REVOKE/ ? 18:52:57 morganfainberg, yes, and its ug-ga-lee.... 18:53:01 ayoung, a consistent naming convention would be good. 18:53:02 Sort of like the hourly high poker hand at the card room 18:53:15 dolphm: I haven't looked at OS-REVOKE... will do 18:53:17 ayoung, and there are times reflection use is important (notably in some migrations) 18:53:17 err, that's not where the revocation *list* lives... 18:53:30 dolphm: does it have token hashes? 18:53:37 morganfainberg, I'm ok with reflection use, I was not the one that protested it. 18:53:44 ayoung, i know. 18:53:50 bknudson: /v2.0/tokens/revoked is completely undocumented - ayoung: do we expose the token revocation *list* on v3? 18:53:57 ayoung: or just events? 18:53:58 BTW...if we change the token hash algorithm...all old tokens should be revoked.... 18:54:06 there's no revocation list on v3... we've got the certs 18:54:13 dolphm, I thought just v2....let me confirm 18:54:31 ayoung, but anyway, i want something we can programatically interact with / validate if we choose. anyway topic to be continued on gerrit review post meeting 18:54:46 bknudson: if there's no existing docs to update, go ahead and +A the client-side review 18:54:53 dolphm, V3 as well: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/controllers.py#n457 18:55:09 http://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/routers.py#n37 18:55:19 dolphm: I'm going to look into the hash algorithm in the tokens... does the middleware care? 18:55:29 it tries to hash the token right away to see if it's in the cache 18:55:30 bknudson, yes it cares 18:55:47 bknudson, ^^ what he says 18:55:48 but this is before it's even validated it. 18:55:49 bknudson, might not be a real issue 18:56:05 this is before auth_token has validated the pki token 18:56:32 the revocation list will have the hash algorithm 18:56:36 if the middleware hashes the token...it would be wierd for anything other than a local memcached look up. In theory, middleware could skip PKI validation and do a remote verification 18:57:15 bknudson, middleware should get the algorithm from token data, not configurable 18:57:24 that would take an explicit setting of a config value. So if it hashed to MD5, but the serve was doing sha256, token validation would fail 18:57:27 ayoung: just ran against mysql and had over 2200 failures (can't create federation tables and unicode won't work) 18:57:27 ok, middleware gets a token hash -- it doesn't know what algorithm was used. 18:57:56 dstanek, ran what against mysql? morganfainberg 's patch? 18:58:15 ayoung: the unit tests on master 18:58:18 bknudson, you can tell be the length 18:58:21 ayoung: the hash algo. mismatch would be solved if we do what gyee suggests though, right? 18:58:38 ah...that might be as expected, dstanek but good to know....starting point for Juno cleanup 18:58:46 nkinder, yep 18:58:52 gyee: you could, though that's a bit hackish 18:58:54 if middleware gets a token hash it validates against the server. 18:58:55 nkinder, except that it would never fetch the revoc ation list 18:59:02 I don't think it cares about the hash then? 18:59:03 that is only done for PKI validation 18:59:08 time's up! 18:59:23 thanks! 18:59:26 nkinder, if we only have to hash string, that's best we can do :) 18:59:27 thanks alL! 18:59:32 ayoung: https://bugs.launchpad.net/openstack-api-site/+bug/1304606 18:59:33 s/to/the/ 18:59:34 Launchpad bug 1304606 in openstack-api-site "Identity API v3 OS-PKI extension is undocumented" [High,Triaged] 18:59:34 #endmeeting