Thursday, 2014-09-11

« Wednesday, 2014-09-10 Index Friday, 2014-09-12 »
*** rose has quit IRC00:06
*** juantwo has quit IRC00:15
*** SheenaG1 has joined #openstack-barbican00:15
*** gyee has quit IRC00:18
*** juantwo has joined #openstack-barbican00:29
*** juantwo has quit IRC00:29
*** juantwo has joined #openstack-barbican00:29
*** bdpayne has quit IRC00:51
*** jorge_munoz has joined #openstack-barbican01:03
*** alee has quit IRC01:28
*** alee has joined #openstack-barbican01:28
*** juantwo has quit IRC01:33
*** woodster_ has quit IRC01:35
*** jorge_munoz has quit IRC01:46
*** jorge_munoz has joined #openstack-barbican01:48
*** jorge_munoz has joined #openstack-barbican01:53
*** jorge_munoz has quit IRC01:54
*** juantwo has joined #openstack-barbican01:56
*** jorge_munoz has joined #openstack-barbican01:58
*** juantwo has quit IRC01:58
*** juantwo has joined #openstack-barbican01:58
*** lisaclark1 has joined #openstack-barbican02:26
*** akoneru has quit IRC02:35
*** kebray has joined #openstack-barbican03:09
*** kebray has quit IRC03:17
*** ajc_ has joined #openstack-barbican03:25
*** lisaclark1 has quit IRC03:26
*** lisaclark1 has joined #openstack-barbican03:26
*** jorge_munoz has quit IRC03:33
*** jorge_munoz has joined #openstack-barbican03:40
*** lisaclark1 has quit IRC03:50
*** jorge_munoz has quit IRC03:52
*** ayoung has quit IRC04:05
*** jaosorior has joined #openstack-barbican05:46
*** juantwo_ has joined #openstack-barbican08:16
*** juantwo has quit IRC08:20
*** d0ugal has quit IRC10:08
*** d0ugal has joined #openstack-barbican10:08
*** SheenaG1 has quit IRC11:16
*** SheenaG1 has joined #openstack-barbican11:20
*** alee has quit IRC12:04
*** woodster_ has joined #openstack-barbican12:09
*** woodster_ is now known as woodster12:10
*** ajc_ has quit IRC12:48
*** nkinder has quit IRC13:12
*** ayoung has joined #openstack-barbican13:14
*** juantwo_ has quit IRC13:37
*** juantwo has joined #openstack-barbican13:37
*** alee has joined #openstack-barbican13:40
*** samuelbercovici has joined #openstack-barbican13:58
*** SheenaG1 has quit IRC14:01
*** jorge_munoz has joined #openstack-barbican14:07
*** lisaclark1 has joined #openstack-barbican14:13
*** nkinder has joined #openstack-barbican14:16
*** ametts has quit IRC14:27
*** lisaclark1 has quit IRC14:30
*** SheenaG1 has joined #openstack-barbican14:30
*** SheenaG1 has left #openstack-barbican14:30
*** usimha has joined #openstack-barbican14:32
*** lisaclark1 has joined #openstack-barbican14:35
rm_workreaperhulk / redrobot / woodster / hockeynut / jvrbanac / others: who would I talk to about Postern? :P14:37
jvrbanacrm_work, pull request accepted? ;)14:37
rm_workhehe14:37
jvrbanacrm_work, no one has really worked on Postern yet.14:38
rm_workam I looking at the right repo here? https://github.com/cloudkeep/postern14:38
rm_workIE, it is still totally unstarted?14:38
hockeynutlooks like jraim was the last one to get his paws on it14:39
hockeynutnew owner = rm_work ?14:39
rm_worklol, awesome14:39
rm_workT_T14:39
jvrbanacrm_work, pretty much. I think there was a POC somewhere at some point that was used, but it need a lot of work.14:39
jvrbanacrm_work, well, it really needed a fresh start14:40
rm_workyeah14:40
rm_worknot sure that I'm your man for that particular job though :P14:40
rm_workmy security background with respect to actually implementing anything hardened is … somewhat lacking14:41
*** paul_glass has joined #openstack-barbican14:44
*** samuelbercovici has quit IRC14:51
*** atiwari has joined #openstack-barbican14:58
*** lisaclark1 has quit IRC15:02
*** paul_glass1 has joined #openstack-barbican15:02
*** kebray has joined #openstack-barbican15:04
*** paul_glass has quit IRC15:05
*** lisaclark1 has joined #openstack-barbican15:06
jaosoriorrm_work: sorry, I wasn't able to review your stuff at the office, I had too much unexpected stuff there. At home I'll do it though15:09
rm_workjaosorior: np15:09
*** dolphm has left #openstack-barbican15:11
*** juantwo_ has joined #openstack-barbican15:13
*** juantwo has quit IRC15:16
*** juantwo_ has quit IRC15:21
*** juantwo has joined #openstack-barbican15:21
redrobotrm_work I htink it's weird that the Containers have a type property15:21
rm_workredrobot: I think you're weird15:21
redrobotrm_work I was expecting the type to be implied by the object type15:22
rm_workredrobot: well, kinda15:22
rm_workredrobot: it's helpful to be able to get an explicit type, I think15:23
* redrobot shrugs15:23
rm_workit's not like the user has to set it if they use the typed objects15:24
rm_workthey don't HAVE to read it, either :P15:24
redrobotso you'd my_container.type == "blah" instead of type(my_container) == SomeClass ?15:25
rm_workeh15:25
rm_workpossibly15:25
redrobotif I wanted to check they container type for some reason15:25
rm_workbut internally it is useful because we need to pass a string type to the API :P15:26
rm_workI could "not expose it" but15:26
rm_workit's still necessary internally15:26
rm_workand exposing it allows people to create containers of any type using the generic Container class if they really want15:26
redrobotso Container(type="rsa") woud return an RSAContainer?  That doesn't feel right to me15:29
rm_workredrobot: no15:30
rm_workbut it would create one15:30
redrobotright, so Container.save() would create an RSA container, but then getting it again would give you an RSAContainer?15:30
rm_workyes15:31
redrobotstill doesn't seem right.15:31
rm_workI mean, the alternative is just arbitrary restriction15:31
rm_workI can see times when writing code that it would be much easier to do it that way15:31
redrobotrm_work I think that it's weird that the thest in this code block is false: http://paste.openstack.org/show/110180/15:35
redrobots/thest/test/15:35
*** atiwari has quit IRC15:35
rm_workI mean, i get it15:35
rm_workI just don't see the problem15:36
*** lisaclark1 has quit IRC15:37
*** gyee has joined #openstack-barbican15:37
redrobotrm_work I don't really see a benefit to stringly-typed containers15:37
*** lisaclark1 has joined #openstack-barbican15:37
rm_workstringly or strongly? :P15:37
redrobotstringly15:37
rm_workhmm15:38
redrobotbecause you pass a string to define the type :-P15:38
rm_workyes15:38
rm_workI get it :P15:38
rm_workso....15:38
rm_workone thing I could do15:39
rm_workhmm15:39
rm_workwell15:39
rm_workI guess I could have an internal dictionary of Class to String15:40
redrobotyeah, I was thinking the client code would just instantiate the appropriate class, then we'd figure out the right string to send to Barbican15:40
rm_workso when we go to actually save() I could pull from self._type_mapping[type(self)] or something like that15:40
redrobotthat way client code doesn't need to know what the magic strings are15:40
rm_workwell, the client doesn't really15:41
rm_work*doesn't NEED to15:41
rm_workif they create via the Typed Objects, or are actually just doing a generic container, they don't need to know a string15:41
rm_workit's all automatic15:42
*** lisaclark1 has quit IRC15:42
redrobotwhat if I want to create a new RSA container client side... I could do it either by instantiating the RSAContainer class or by passing "rsa" to the Container class?15:43
rm_workyes15:43
redrobotif I choose to pass the "rsa" string, the the consumin code now has to know what that string is15:43
rm_workso if you don't know the magic string, just use RSAContainer()15:43
rm_workredrobot: err15:43
rm_workwat15:43
redrobotso if we change it in Barbican proper, client code would have to change also15:43
rm_workwell, that's always going to be the case15:43
redrobotclient code here = an app using barbicanclient15:43
rm_workoh, no? why would it have to change15:44
rm_workwell, i mean, if they're using the string -- but they don't HAVE to use the string :P15:44
redrobotright, but I think it'd be even better if they never get the choice to use it15:44
rm_workyou just want less options?15:44
rm_workI mean, I could take "type" out of the passed args15:44
rm_workthat'd be the only code change15:45
rm_workto facilitate that15:45
redrobotyeah, I think that'd be awesome15:45
redrobotand remove the type property15:45
rm_workI think it's limiting :P15:45
rm_workbut15:45
rm_workI can do it15:46
rm_workI need the type property though15:46
rm_workbecause I need to read what type it is to generate the right kind of object when we GET a container15:46
rm_workbut it could be read-only15:47
rm_workalso for listing containers15:47
rm_workit is necessary15:47
rm_worksince in a list they are all displayed generically15:47
rm_workwith a type field15:47
redrobotcan you make it _private?15:47
rm_workI don't see the point <_<15:48
rm_workif it's read-only15:48
redrobotit's so that people don't write code around it15:48
rm_workyou accomplish your goal of "people won't use it for creates", you really that badly don't want them to see it at all?15:48
redrobotyeah, I want it to be able to change if needed, without breaking too much stuff15:49
jvrbanacrm_work, ping15:49
rm_workjvrbanac: yes I am here :P15:49
rm_workbah i didn't upgrade my pycharm license on this machine15:50
jvrbanacrm_work, quick question. Is there a reason why you're overriding the reserved name "type" in https://review.openstack.org/#/c/113393/14/barbicanclient/containers.py15:50
rm_workheh15:50
rm_workI thought about if it mattered / if i cared, and the answer I came up with was "nope"15:50
* redrobot thinks jvrbanac is late to the party15:50
redrobot:-P15:50
rm_workif you want me to change it just because it is "bad practice" or something, I don't have a specific objection15:50
rm_workbut yes, if redrobot gets his way, it will disappear entirely15:51
rm_workso your concern won't even be valid :P15:51
*** arunkant_work has joined #openstack-barbican15:51
redrobotI don't think it's shadowing type in this context15:51
redrobotit's always self.type()15:51
rm_workright15:51
jvrbanaclawls.... I just read the logback on the channel... woops15:51
rm_workheh15:51
rm_workyes, I thought your interjection was humorous :P15:51
rm_workjvrbanac: i opted for "clear meaning in the current context"15:52
rm_workinstead of trying to come up with a new name for what is literally "type" in the API JSON15:52
rm_worksince it didn't actually interfere with the type keyword at any point15:53
*** atiwari has joined #openstack-barbican15:53
rm_workpycharm still gives me smells for it constantly but I pointedly ignore it15:53
rm_workbut15:53
rm_workthat said, redrobot wants type() gone15:54
rm_workso your complaint is barely relevant in that context :P15:54
rm_workredrobot: so, if I get rid of the type arg in Container()'s signature15:54
rm_workand get rid of the properties for it15:54
rm_workand simply set and read self._type internally15:55
rm_workthat would satisfy you?15:55
redrobotyes, I would think that's awesome ^_^  ... also debating myself right now if maybe we want the different Container classes defined at the module level, in case we need to import them somewhere15:56
rm_workerk15:56
rm_workI mean, you can still import them15:56
rm_workfor example...15:56
rm_workhttps://review.openstack.org/gitweb?p=openstack/python-barbicanclient.git;a=blob;f=barbicanclient/test/test_client_containers.py;h=3c7c23243a4c4930d467d3ed02ea17a03ca6d21f;hb=2da3c3d3828262c875bc45e1ab937c3691bab038#l30915:59
rm_work:P15:59
rm_worknot sure what you want exactly16:00
atiwarireaperhulk, woodster do you guys know where we stand on https://github.com/cloudkeep/barbican/wiki/Blueprint:-Initial-Approach-to-Keystone-Interaction use cases?16:01
rm_workatiwari: wow, that looks very much like what I've been working on for a while now16:02
rm_workatiwari: http://goo.gl/X3kKIX16:02
atiwarirm_work, great16:03
rm_workI think their solution is probably better16:03
rm_workI was just trying to get something to WORK with the current system16:03
rm_workI am interested in what they're doing16:03
rm_workredrobot: I will do that I guess <_<16:04
redrobotrm_work ok, I'm fine with the classes where they are16:06
redrobotrm_work but yes, I'd like that type change16:06
rm_workredrobot: ok, one side-effect16:13
redrobotrm_work shoot16:13
rm_workredrobot: now if a user does "my_existing_container = RSAContainer(container_ref='blah')"16:13
rm_workand the container is actually a CertificateContainer16:14
rm_workit will straight up return a CertificateContainer16:14
rm_workpreviously, it would have complained and raised an exception about expected type not matching16:14
redrobotweird... should that be an exception maybe?16:14
rm_workyes16:14
rm_workbut now I can't do that easily16:14
rm_workerr, well16:14
rm_workscratch that, I just need to reorganize I think16:15
rm_work<_<16:15
rm_workso, question then16:15
rm_workshould it be possible for Container(container_ref=blah) to return an RSAContainer?16:15
rm_workor do they absolutely *need* to know the type to get the container out?16:15
rm_workthat seems… >_>16:15
rm_worksuboptimal16:16
rm_workbut if we allow that, it violates your constraint that the factory only return the specific type that was "requested"16:16
rm_workbut NOT allowing that, it becomes overly burdensome on the user just to get their container out16:17
redrobotrm_work trying to think of use cases for Container(container_ref="http://actually_an_rsa_container")  ...   ?16:18
redrobotI mean, it's my container, I should know what type it is?  :-\16:19
rm_workwell, without it, how would the user even be able to find out what type a container is with the client? >_>16:19
rm_workprogrammatically16:19
rm_workif you can't GET the container without knowing the type16:19
rm_workbut you can't know the type programmatically without doing a GET :P16:19
rm_workremember, containers are going to be passed to other services16:20
rm_workit might not be *your* container16:20
rm_workthough there should theoretically be an "expected type" in those cases...16:20
redrobotyeah...  wonder if we just need a containers.get_container(container_ref) that returns the correct type?16:20
rm_work<_<16:20
redrobotbut now I can't remember why we wanted to move away from that ?16:21
rm_worklol16:21
rm_workthe spec said so, for one16:21
rm_work:P16:21
rm_workand I do honestly like these factory methods a lot more16:21
rm_workerk16:21
rm_worksec, please leave your thoughts, I will brb in a sec16:21
*** SheenaG1 has joined #openstack-barbican16:22
rm_workerr and by "sec" i now mean "a while"16:23
atiwarirm_work, in the seq diagram you are LBaaS is creating trust on behalf of use.16:26
*** akoneru has joined #openstack-barbican16:27
atiwariI think that is not allowed16:27
rm_workatiwari: haha16:27
rm_workyes16:27
rm_workso16:27
rm_workI have had HOURS of discussion on this16:27
rm_worktechnically it is possible16:27
rm_workbut it "depends"16:27
rm_workwhich is not great, because then there are cases where it works and some where it doesn't16:27
rm_workoh right, I was going to be afk for a few… >_>16:28
* rm_work goes afk for a few min16:28
atiwariI think we need to report it to Keystone folks, it is security issue16:28
rm_workatiwari: these discussions were *with* keystone folks16:28
rm_workspecifically ayoung16:28
rm_workwho apparently is here16:28
atiwariare they ok with this issue?16:28
rm_worknot particularly :P16:28
rm_workI think his statement was something like "I am trying my hardest to prevent things like this from being possible, but if you want to do it we can't stop you"16:29
atiwariok16:29
rm_workatiwari: also of interest might be this morning's LBaaS meeting16:29
rm_workhttp://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-09-11-14.00.log.html16:30
rm_workfirst topic16:30
rm_workBarbican integration -- Keystone Trusts, comments and concerns (rm_work)16:30
rm_workthat went for about 30 minutes :)16:30
rm_workI explain most of what the issues are16:30
rm_workseriously tho, afk for a few16:30
atiwarihmm16:31
rm_workatiwari: it kind of comes down to the never-ending tug-o-war between security and usability16:40
rm_workwe think making the user do the Trust stuff themselves is horrible usability16:40
rm_workbut allowing for a service like us to create trusts on someone's behalf is unarguably a security hole, to some degree16:40
rm_workI definitely don't think ayoung is *wrong* in his quest to plug holes like that, but I also hope that he sees the value of what we're trying to do as well (make a seamless user experience)16:41
rm_workit's about finding a balance, usually16:41
rm_workbut anyway, I should talk to the guys that are working on the Cinder side of this :P16:42
rm_worklooks like they may have some thoughts that would be useful to LBaaS as well, even though their stuff is slightly different16:42
rm_workI am going to lunch right now, I will be back in an hour+, can resume this conversation then? (both conversations actually, redrobot / atiwari )16:43
atiwarirm_work, problem is *IMO* it is security issue and if you design your use case around those issue it may cause problems later16:43
atiwarirm_work, sure16:43
rm_workatiwari: yes, that is a concern16:43
rm_workkk, bbl16:43
atiwarialso can you provide me cinder contact16:44
atiwarino rush16:44
*** alee is now known as alee_lunch16:45
ayoungrm_work, I understand it, and it is one of thing things that I wrote up as a blueprint a long time ago but the world was not there yet...  https://blueprints.launchpad.net/keystone/+spec/delegation-workplans16:50
ayoungatiwari, I think the trust creation needs to be done by the user, but the trust definition does not.  The user should have to "sign on the dotted line"  that the trust is OK16:51
atiwariayoung, seems correct16:52
atiwaribut who is going to define the trust?16:53
ayoungatiwari, you know, I think it is OK for LBaaS or Heat to do it, so long as the user actually creates it16:53
ayoungthe client can be smart enough to show the user the trust definitino16:53
ayounglonger term, I would like to have them pre-canned in Keystone, and thus subject to a third party review as well16:54
ayoungI think we need to be iterative:  lets get something that works now based on "You create the trust for me"  I promise to break that on you in the future, and you work towards the day when I break that16:54
ayoungatiwari, the problem is, the day is coming where not all end services are trusted with all resources.16:55
atiwariok, I am still not clear on "the client can be smart enough to show the user the trust definitino"16:57
atiwaribtw thanks ayoung,16:57
atiwariseems some kind of workflow ?16:58
*** nkinder_ has joined #openstack-barbican17:03
*** nkinder has quit IRC17:07
openstackgerritPaul Kehrer proposed a change to openstack/barbican: PKCS11 refactor to use a master KEK and per project KEK  https://review.openstack.org/12049817:19
*** tkelsey_ has joined #openstack-barbican17:29
*** tkelsey_ is now known as tkelsey17:31
*** alee_lunch is now known as alee17:45
*** openstackgerrit has quit IRC17:46
*** openstackgerrit has joined #openstack-barbican17:47
*** tkelsey has quit IRC17:58
*** usimha has quit IRC17:59
*** rose_ has joined #openstack-barbican18:10
atiwariwoodster, redrobot can we make some progress on https://review.openstack.org/#/c/118697/?18:15
atiwarithanks18:15
jvrbanacreaperhulk, ping18:21
*** mikedillion has joined #openstack-barbican18:27
*** mikedillion has quit IRC18:30
*** Stanzi has joined #openstack-barbican18:36
Stanzihello, this is a test18:36
*** Stanzi has quit IRC18:37
*** Constanze has joined #openstack-barbican18:38
*** paul_glass1 has quit IRC18:41
jaosoriorrm_work: so, the result of the __str__ cr is that the containers are printed differently per type but the same if listed?18:52
ConstanzeI submitted the following CR's for the Barbican docs. I'm looking for reviewers. Thanks!18:52
Constanzehttps://review.openstack.org/#/c/117889/ https://review.openstack.org/#/c/119931/ https://review.openstack.org/#/c/119932/ https://review.openstack.org/#/c/120156/ https://review.openstack.org/#/c/120161/ https://review.openstack.org/#/c/120163/18:52
jaosoriorI still think this could have been a bit simpler just by using inheritance18:53
jaosoriorBut why does listing the containers of different types have to be the same?18:54
*** stanzi has joined #openstack-barbican18:57
*** annegentle has joined #openstack-barbican19:00
jaosoriorAnd stuff19:04
jvrbanacstanzi, I'm taking a look at a couple of them right now19:05
*** russellb has quit IRC19:05
*** russellb has joined #openstack-barbican19:07
stanziGreat. Thanks, John!19:07
*** lbragstad has quit IRC19:07
reaperhulkjvrbanac what's up?19:08
*** xaeth has quit IRC19:09
*** jillysciarilly has quit IRC19:09
*** dstufft has quit IRC19:10
*** hockeynut has quit IRC19:10
*** lbragstad has joined #openstack-barbican19:10
*** dstufft has joined #openstack-barbican19:10
*** kebray has quit IRC19:10
jvrbanacreaperhulk, I was looking at your review noticed that you're pulling the hmac_key and the mkek_key from the same dict. It seems like potentially a problem if someone accidentally defines the same label name for both the mkek_label hmac_label.19:10
jvrbanacreaperhulk, thoughts?19:10
*** paul_glass has joined #openstack-barbican19:12
*** hockeynut has joined #openstack-barbican19:12
*** paul_glass1 has joined #openstack-barbican19:14
*** reaperhulk has quit IRC19:14
*** russellb has quit IRC19:15
*** paul_glass has quit IRC19:17
*** paul_glass1 is now known as paul_glass19:18
*** annegentle has quit IRC19:18
*** lbragstad has quit IRC19:19
*** hockeynut has quit IRC19:21
*** hockeynut has joined #openstack-barbican19:21
*** nkinder_ has quit IRC19:23
*** lbragstad has joined #openstack-barbican19:23
*** lbragstad has quit IRC19:28
*** hockeynut has quit IRC19:30
*** hockeynut has joined #openstack-barbican19:30
akoneruredrobot, ping19:34
*** lbragstad has joined #openstack-barbican19:34
*** lbragstad has quit IRC19:37
redrobothi akoneru19:39
*** hockeynut has quit IRC19:39
akoneruredrobot, hi. i have a question regarding a jenkins failure for my CR. Got a minute?19:39
*** hockeynut has joined #openstack-barbican19:40
*** paul_glass has quit IRC19:40
*** paul_glass has joined #openstack-barbican19:40
akoneruredrobot, the py26 gate tests are failing. in the console.html, i came across this error - error: testr failed (3)19:41
akoneru2014-09-10 22:02:58.146 | ERROR: InvocationError: '/home/jenkins/workspace/gate-barbican-python26/.tox/py26/bin/python setup.py testr --coverage'19:41
redrobotakoneru is that on your local dev box?19:41
akoneruredrobot, no. i submitted the CR. i see this in the Jenkins UI. I started looking into running tests using tox locally, but wanted to know the exact failure reason first.19:43
redrobotakoneru can you give me the cr link?19:43
akoneruredrobot, https://review.openstack.org/#/c/117845/19:43
*** ryanpetrello has quit IRC19:44
*** ryanpetrello has joined #openstack-barbican19:44
*** ryanpetrello is now known as ryanpetre19:44
*** hockeynut has quit IRC19:48
*** jillysciarilly has joined #openstack-barbican19:51
*** xaeth has joined #openstack-barbican19:52
*** reaperhulk has joined #openstack-barbican19:56
redrobotakoneru looking... also having a discussion here about another issue, so give me a few...19:56
akoneruredrobot, sure. thanks!19:58
*** lbragstad has joined #openstack-barbican20:02
*** bubbva has quit IRC20:05
*** bubbva has joined #openstack-barbican20:05
jvrbanacreaperhulk, thoughts on my question?20:08
*** nkinder_ has joined #openstack-barbican20:11
*** tkelsey has joined #openstack-barbican20:23
*** tkelsey has quit IRC20:29
*** SheenaG11 has joined #openstack-barbican20:31
*** SheenaG1 has quit IRC20:33
openstackgerritMatthew Treinish proposed a change to openstack/barbican: Install tempest instead of just adding it to PYTHONPATH  https://review.openstack.org/12090420:36
openstackgerritMatthew Treinish proposed a change to openstack/barbican: Switch to running tests in parallel with testr  https://review.openstack.org/12090520:36
*** akoneru is now known as akoneru_brb20:40
redrobotakoneru_brb I can't tell what's going on in that failure.  And I'm having a completely different error on my machine -___-20:45
*** rose_ has quit IRC20:54
*** akoneru_brb is now known as akoneru21:29
akoneruredrobot, oh. ok. thanks! i will keep looking into it21:29
openstackgerritMatthew Treinish proposed a change to openstack/barbican: Switch to running tests in parallel with testr  https://review.openstack.org/12090521:30
*** alee is now known as alee_heading_hom21:32
reaperhulkjvrbanac: I don't think I saw a question21:33
jvrbanacreaperhulk,  I was looking at your review noticed that you're pulling the hmac_key and the mkek_key from the same dict. It seems like potentially a problem if someone accidentally defines the same label name for both the mkek_label hmac_label.21:34
openstackgerritConstanze Kratel proposed a change to openstack/barbican: removed whitespace from pom.xml  https://review.openstack.org/12016121:35
openstackgerritConstanze Kratel proposed a change to openstack/barbican: removed tenant id from code samples  https://review.openstack.org/12016321:35
openstackgerritConstanze Kratel proposed a change to openstack/barbican: removing cq-devguide.wadl which was added by mistake  https://review.openstack.org/11993121:35
openstackgerritConstanze Kratel proposed a change to openstack/barbican: Updated dev guide to include feedback from previous tech review  https://review.openstack.org/11788921:35
openstackgerritConstanze Kratel proposed a change to openstack/barbican: Update Getting Started Guide to include tech review feedback  https://review.openstack.org/12015621:35
openstackgerritConstanze Kratel proposed a change to openstack/barbican: removed image files as they referred to internal architecure  https://review.openstack.org/11993221:35
reaperhulkif they do that then it will break some shit21:35
reaperhulkI think there's even a comment to that exact effect in the api.conf :)21:35
reaperhulkpretty much https://review.openstack.org/#/c/120498/3/etc/barbican/barbican-api.conf ("must not be the same as HMAC label")21:36
jvrbanacreaperhulk, ok. Is there any benefit of adding safeguards against that?21:36
reaperhulknot particularly since the key would be ambiguous in the HSM too21:36
reaperhulkI'm not sure the HSM would even let you generate it21:36
jvrbanacreaperhulk, ok cool. I just thought I would ask.21:37
*** alee_heading_hom has quit IRC21:37
reaperhulkIt's a fair question. We could add a check in the init to error if they're the same21:37
jvrbanacreaperhulk, I'm fine with either. In theory this is more of a deployer problem, so I'm not so concerned.21:40
*** paul_glass has quit IRC21:40
*** jaosorior has quit IRC21:42
openstackgerritConstanze Kratel proposed a change to openstack/barbican: removed whitespace from pom.xml  https://review.openstack.org/12016121:44
openstackgerritConstanze Kratel proposed a change to openstack/barbican: removed tenant id from code samples  https://review.openstack.org/12016321:44
jvrbanacreaperhulk, I +2'ed. If it becomes more of a concern we can address it then.21:47
reaperhulkko, thanks for the review jvrbanac21:47
*** atiwari has quit IRC21:50
*** SheenaG11 has quit IRC22:02
jvrbanacwoodster, you still around?22:27
woodsterjvrbanac: yep22:28
jvrbanacwoodster, do you mind approving Doug H's CRs in the barbican-specs repo? reaperhulk and myself already +2'ed them22:28
openstackgerritConstanze Kratel proposed a change to openstack/barbican: removed tenant id from code samples  https://review.openstack.org/12016322:29
jvrbanacwoodster, they are quite small22:32
woodsterjvrbanac: will take a look22:33
*** openstackgerrit has quit IRC22:38
*** openstackgerrit_ has joined #openstack-barbican22:39
*** openstackgerrit_ is now known as openstackgerrit22:40
*** gyee has quit IRC22:40
jvrbanacwoodster, I added in a link to the email from the dev list that talk about what this stuff is for22:41
jvrbanac^in a comment22:41
openstackgerritConstanze Kratel proposed a change to openstack/barbican: removed whitespace from pom.xml  https://review.openstack.org/12016122:43
openstackgerritConstanze Kratel proposed a change to openstack/barbican: removed tenant id from code samples  https://review.openstack.org/12016322:43
*** ayoung has quit IRC22:45
*** alee_heading_hom has joined #openstack-barbican22:48
Constanze <jvrbanac> thanks for reviewing my CR's. I went ahead and addressed all of them22:49
openstackgerritAdam Harwell proposed a change to openstack/python-barbicanclient: Add Containers to python-barbicanclient  https://review.openstack.org/11339323:06
openstackgerritAdam Harwell proposed a change to openstack/python-barbicanclient: Change object __str__() to use pretty formatting  https://review.openstack.org/11849423:06
rm_workredrobot: change made to remove type23:06
rm_workbbl, please leave reviews :)23:06
*** SheenaG1 has joined #openstack-barbican23:28
*** arunkant_work has quit IRC23:29
*** SheenaG11 has joined #openstack-barbican23:30
*** SheenaG1 has quit IRC23:32
*** jorge_munoz has quit IRC23:48
« Wednesday, 2014-09-10 Index Friday, 2014-09-12 »

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