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