16:02:09 #startmeeting openstack-oslo 16:02:10 Meeting started Mon Nov 14 16:02:09 2016 UTC and is due to finish in 60 minutes. The chair is amrith. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:13 The meeting name has been set to 'openstack_oslo' 16:02:15 #chair harlowja 16:02:16 Current chairs: amrith harlowja 16:02:21 harlowja, ping 16:02:28 you have a meeting -2 minutes from now ... 16:03:09 who'd like to run the meeting (since harlowja appears to be currently not around) 16:03:38 o/ 16:04:01 let's give harlowja 1 minute then we can get started 16:05:00 courtesy ping for amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dims 16:05:00 courtesy ping for dougwig, e0ne, flaper87, garyk, gcb, GheRivero, haypo 16:05:00 courtesy ping for HenryG, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz 16:05:00 courtesy ping for lifeless, lintan, lxsli, Nakato, ozamiatin, rbradfor, redrobot 16:05:00 courtesy ping for rpodolyaka, sergmelikyan, sileht, spamaps, sreshetnyak, sreshetnyak, stevemar 16:05:01 courtesy ping for therve, thinrichs, toabctl, viktors, zhiyan, zzzeek 16:05:11 o/ 16:05:17 amrith: hola 16:05:27 amrith: you're running the meeting now :O 16:05:43 hi stevemar I'd wanted to discuss something today and no one else started the meeting :) 16:05:50 still waiting for our fearless leader 16:06:13 But since he's not here and it is five minutes past the top of the hour 16:06:15 #topic Red flags for/from liaisons 16:06:42 Nothing to report in LBaaS land 16:06:43 i have nothing from trove 16:07:31 nothing from ironicland 16:07:32 oslo.db master breaks nova unit test , Fixing in https://review.openstack.org/397144 ,so need skip oslo.db release this week 16:08:00 #info (from gcb) oslo.db master breaks nova unit test , Fixing in https://review.openstack.org/397144 ,so need skip oslo.db release this week 16:08:46 any others ... also still looking for an alternate chair; any oslo cores wishing to drive, please let me know. 16:09:29 Any other red flags from liaisons? 16:09:51 amrith, I can help go through the agenda 16:10:02 #chair gcb 16:10:03 Current chairs: amrith gcb harlowja 16:10:07 gcb has the con 16:10:14 go ahead gcb 16:10:45 #agenda https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_Template 16:11:06 #topic Releases for Ocata 16:11:29 Does anyone need oslo.* release this week ? 16:12:51 ok, I will talk with harlowja to check if we need release something this week 16:13:34 #topic Ocata specs 16:13:38 https://review.openstack.org/#/q/status:open+project:openstack/oslo-specs,n,z 16:14:32 Is there any spec or commit which needs review ? 16:15:59 #topic Open discussion 16:16:13 I have one ... 16:16:26 #link https://review.openstack.org/#/c/394667/ 16:16:29 amrith , it's your turn 16:16:34 thx gcb 16:16:52 so we discussed having a more intrusive way of doing message checksum in the meeting last week 16:17:24 and the consensus was that the oslo team did not want to implement message checksum for the use-case that I have and instead suggested that I use a decorator on *ALL* API methods 16:17:34 and pass a signature down as a formal parameter to the RPC call. 16:17:45 this is very disruptive to the code in the consuming project (like trove) 16:18:00 and so I was hoping I could minimize the disruption by wrapping the dispatcher as proposed in https://review.openstack.org/#/c/394667/ 16:18:27 sileht observes that the dispatcher is not in __all__ and while it has no _ in the name it is still considered private 16:18:46 wrapping the dispatcher in this way is very beneficial to trove as we can localize the change for signing messages into two places. 16:19:04 one on the caller side, where we can wrap cast() or call() and one on the server side where we wrap the dispatcher. 16:19:22 the dispatcher wrapper as shown in this change will verify the signature and pop the signature argument 16:19:31 therefore requiring no further code on the server side 16:20:17 sileht ^^ 16:21:04 amrith , method with prefix '_' will not be allowed in the future . Do you want kgiusti and silent's more input here ? 16:21:14 yes please 16:21:20 would like a decision one way or the other 16:21:32 I'd of course prefer that the decision be to allow this kind of wrapping 16:21:44 as it would make o.m.rpc easier to use 16:22:13 especially because the project (oslo) has not shown an interest in taking on the bigger project of implementing message signing. 16:22:58 kgiusti ^^ 16:23:05 So what's the argument against making dispatcher public? Or at least some small base class of dispatcher with the methods exposed? 16:23:27 kgiusti, other than what sileht said in the comments on the review, I have heard of none 16:24:02 On Nov 8, 1:38pm he wrote "What if this object is modified outside ? I don't think we want to support that." 16:24:17 to be clear, I don't agree with the point of view; just relaying it since he isn't here. 16:24:40 o/ 16:24:50 hi sileht 16:25:09 the code about disallowing private method in oslo.messaging, https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/dispatcher.py#L103 16:25:22 this is not the first time people want to have a custom Dispatcher 16:25:48 I'm not against making it private, but that need some works because we can't expose it as-is 16:26:01 amrith , you still can pass LegacyRPCAccessPolicy to make private method exposed 16:26:03 In question (for Trove) is the issue that if this dispatcher wrapping is not allowed, I have to decorate over 100 individual API calls and will have to deal with version mismatches in a more painful way than if I could abstract it into oslo. 16:26:25 sorry gcb I don't think that's the same thing. 16:26:51 Because the 'incoming' parameter of the method dispatch is a 'driver' object and must not be exposed outside 16:26:54 sileht, how do we do that additional work to make this expose'able. 16:27:34 I have no idea, I just don't want to expose it until driver stuff are correclty hidden 16:27:35 could we then provide a callback that would only get the arguments and allow the callback to manipulate those? 16:27:42 can IncomingMessage present both context and message in it's original form as published by the user? 16:27:55 the arguments (and context) are not driver stuff ... 16:28:30 so could we agree to register a callback that would receive args and context which it can modify and the RPC dispatcher would then dispatch with those modified parameters and context 16:28:39 and if no callback is provided, proceed as currently 16:28:45 i.e no change 16:28:46 Have a minimal public incomingmessage, internally wrap it per driver impl? 16:29:26 kgiusti, that the idea a object with only ctxt/message without driver method 16:29:48 sileht: gotcha - encoding the meth+args in internal 16:29:58 is internal I mean 16:30:29 but again this allows to sign only a subset of what will be passed to rabbit... 16:31:20 but since oslo isn't doing the signing (the client is) what is oslo's issue with what actually is signed? 16:31:26 the message have also a serialisation format, a version... 16:31:33 if oslo wants to stipulate what is signed, fine. let oslo do the signing and verification 16:31:40 also only the call will be signed not the answer ... 16:32:02 but barring that, the client is the one doing the signing (not oslo) and so whatever the client can do is all that it can do. 16:34:09 so currently we are here: the client sign a partial msg, the server check the sig on part of the message, send a unsigned reply, the client accept it 16:34:19 this is not want I call security ... 16:34:22 can the serializer/deserializer play a role here? 16:35:11 sileht, let me see if I can restate this. oslo doesn't want to implement signing in the library (o.m.rpc) but wants to question the level of signing that the client can implement with the limited resources at the clients disposal? 16:35:34 kgiusti, yes it can but that would be implementing signing and verification in the library. 16:35:48 which it seemed like no one wanted to sign up for in the two times that it has come up so far. 16:36:07 not if the application provides serialization/deserialization 16:36:08 yet, no one seems to object if the client uses a decorator to verify signatures. 16:36:49 kgiusti, the serialization and deserialization are (if I recall correctly) per argument and for the context at this point. 16:36:50 unfortunately that wouldn't protect the protocol headers added by the driver 16:36:56 not for the whole lot in a single call. 16:37:14 therefore computing signatures in the serialization/deserialization layer may be problematic. 16:37:21 we have two layer of serialization, the one we expose to the API to get serializable object 16:37:39 and the one driver use to send the msg to the network (json/msgpack/...) 16:40:28 so where do we go from here? 16:41:12 I don't known, I'm open to proposal, I will just take care that we do not expose internal stuffs 16:41:58 well, I've made two proposals and so far I've been told 'not that one, not that one' 16:41:58 I don't want to question the level of signing, I just raise 'warning' about this falsy secure thing 16:42:40 well, yes, I know that. but the proposal to do the signing in oslo was not acceptable (see last weeks meeting). 16:42:43 I known I see your effort to find a solution 16:42:57 I haven't enouth time to thing about his unfortunatly 16:43:16 me either, sadly.... 16:43:58 Did anyone ever write a formal spec on adding message signing in o.m.? 16:44:12 a couple of years ago, yes. markmc 16:44:56 I'd like to take a look at that - understand the reasons it was rejected. 16:45:13 signing was implemented as experimental before oslo.messaging exists and dropped during the creation of the new lib 16:45:30 and infortunatly nobody I have reintroduce this 16:45:39 the implementation there was RPC message signing per the RFC 16:46:56 the old/previous oslo-rpc layer was offer hook to sign messages 16:47:00 so what's the collective wisdom of the group? y'all have no time, I have the time and inclination to do this but I'd need some direction because clearly I can't come up with something that meets your approval. 16:47:56 and the project 'kite' was implementing this hooks (this project was abandoned, end of the story) 16:49:23 I'd still be in favor of having the actual signing and verification happen "outside" the library.... somehow. 16:50:24 managing the security creds and such - is that something the library proper should do? 16:50:37 me too, I think the best way is to refactor the dispather and expose a hook that take only the ctxt, method, args 16:50:50 sileht: +1 agreed 16:50:53 guys, I proposed that last week and I was told no. 16:51:23 I guess I'll wait for y'all to come up with a proposal of how to do this and I'm happy to implement it. 16:51:28 if you want. 16:51:28 amrith, no for the current implementation, not for the idea itself 16:52:01 I think the argument against was that only the app data would be verified, other fields could be hijacked. 16:52:19 well sileht that wasn't what was said last week. it was go away and implement it as a decorator like your sample showed. but no matter, if you are open to having the library do it with callbacks or hooks, let me know how you'd like it done and I'll write it 16:52:42 kgiusti, yeah but if the app what to do not secure sign with this hook, do we care ? 16:52:45 kgiusti, verifying other fields would mean exposing internals; you decide what you want :) 16:53:40 amrith, this why using oslo.messaging for a secure thing sucks and you should not 16:53:49 using it for this 16:54:14 amrith, and we have recommanded to use REST API last week too 16:54:23 great, that's the other answer I got. don't use o.m and you won't have this problem. easy for you to say, that was decided 4 years ago by some other people who converted from RPC to oslo.messaging. 16:54:24 but that a much bigger change 16:54:50 so yes, the answer I've been getting is consistently that the problem is something trove is doing, so go do it some other way. 16:54:53 fine, I'll do that. 16:55:10 I have my answer. thanks sileht 16:55:45 I'm done with this issue, does anyone else have something for open discussion? 16:55:52 if not, maybe we can end the meeting early 16:56:31 gcb said he'd have to step away as it is close to midnight his time. 16:56:48 if there's nothing else for this meeting, I propose we end ... 16:57:40 going once 16:58:01 going twice 16:58:28 thanks all 16:58:29 #endmeeting