20:00:28 #startmeeting barbican 20:00:29 Meeting started Mon Apr 20 20:00:28 2015 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:32 The meeting name has been set to 'barbican' 20:00:53 #topic Roll Call 20:01:00 o/ 20:01:03 hiyo/ 20:01:03 \o/ 20:01:10 Hola. 20:02:13 Yo 20:03:18 #topic Action Items 20:03:29 #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-04-13-19.59.html 20:03:49 Many thanks to elmiko for getting the Juno->Kilo migration working 20:04:00 * elmiko tips fedora 20:04:09 o/ 20:04:12 o/ 20:04:14 on to my action items 20:04:25 elmiko, agreed! 20:04:33 o/ 20:04:39 I did not get a chance to look into why Castellan failed to upload, but I did manually upload 0.1.0 20:04:39 o/ 20:04:53 so you can "pip install castellan" now 20:05:02 huzzah! 20:05:21 +1 20:05:25 good stuff 20:05:36 next time we make a Castellan release, I'll be sure to go poke at infra to make sure the auto-upload works 20:05:42 #link https://pypi.python.org/pypi/castellan 20:06:35 Also, I emailed the dev list earlier today to ask about minor changes in the API 20:06:37 #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/062021.html 20:06:49 looks like there were some replies since then 20:07:02 so take a look, and chime in if you'd like 20:07:55 and lastly, I did not get a chance to talk to Greg 20:07:56 so 20:08:14 #action redrobot to talk to Greg Swift about DB being used in Fedora 20:08:39 on to the agenda for today 20:08:44 which as usual can be found here: 20:08:48 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:08:54 #topic Kilo RC1 20:09:08 #link https://launchpad.net/barbican/+milestone/kilo-rc1 20:09:34 Kilo RC1 was released this morning, which means that the master branch is now tracking the Liberty release 20:10:39 also, we have a stable/kilo branch now for bugfixes etc 20:11:07 any questions/comments about RC1 ? 20:11:41 you mentioned there being an RC2 possibly 20:11:44 is that still happening? redrobot ? 20:12:27 chellygel I don't know yet. There's another agenda item to talk about a possible bug. If we think we need to fix it for Kilo, then we may need an RC2 20:12:52 coo 20:13:48 redrobot, so for barbican specs, is there a liberty folder defined? I need to move audit spec from kilo. 20:14:10 arunkant good question, as it leads to the next topic 20:14:29 #topic What approved or drafting blueprints do we want to bring over to Liberty? 20:15:09 arunkant there is no Liberty directory yet. usually the first blueprint proposed for the new cycle creates the new directory 20:15:31 afaik, you can't check in an empty directory in git 20:16:29 okay. makes sense. Will create one if not there at the time of my checkin 20:16:34 woodster_ did you have any particular blueprints in mind for this topic? 20:17:05 redrobot, it was more for folks to air out ones that don't want to bring over really. 20:17:42 redrobot: I'll bring over the TLS ones I put in there. tsv will hopefully bring over the quota one :) 20:18:26 redrobot, we probably want to bring over the version resource bp as well 20:19:02 I figured if people still want to work on a proposed spec, they can submit a CR to move it from kilo->liberty 20:19:38 I also need to go back and clean up stuff so we can clearly tell which blueprints were not implemented in kilo 20:19:49 #action redrobot to clean up the barbican-specs repo 20:20:08 redrobot, i have two blueprints (gate-bandit and smoke-test-rsa) that have been implemented and merged into Kilo, but are still marked "New". I think i skipped a step. 20:20:46 redrobot, you have the #link https://blueprints.launchpad.net/barbican/+spec/active-secret-store spec 20:20:56 dave-mccowan usually the CR should include the spec it implements in the commit message 20:21:13 alee, you have the #link https://blueprints.launchpad.net/barbican/+spec/expose-ca-enrollment-templates one out there 20:21:25 dave-mccowan I can fix it in launchpad for the blueprints you worked on. 20:21:57 woodster_ I don't think alee made it to this meeting. 20:22:17 woodster_, the quote specs which was approved/merged in kilo. As its not implemented, so is it going to be added in Libery specs folder? Is that correct understanding. 20:22:20 redrobot: what? so much for perfect attendance for him 20:22:22 dave-mccowan: did you say there was a bandit gate implemented? 20:22:49 arunkant: I was hoping tsv would do that as part of continuing to work on that feature 20:23:06 arunkant yes, I'll move those over as part of the spec cleanup 20:23:40 tkelsey yes, as experimental. "check experimental" in gerrit. or "tox -e bandit" locally. 20:23:50 woodster_ I haven't seen tsv in weeks. He may not be available to work on that blueprint 20:24:05 dave-mccowan: oh awesome :D I didnt know that (probably should have lol) 20:24:11 redrobot, sadness :\ 20:24:22 woodster_, I am just trying to understand the process around this. Especially the spec is already merged to master. 20:24:26 dave-mccowan tkelsey I don't think adding a gate to the experimental pipeline would count as completing a blueprint? 20:25:05 arunkant, the CR would need to move the spec rst file from the kilo folder to the liberty one 20:25:52 redrobot, the LP blueprint would also need to be revised to point to Liberty, correct? 20:26:09 not necessarily 20:26:11 redrobot: I haven't seen the spec, I must have missed it, but i would think it would need to move out of experimental, thoughts dave-mccowan 20:26:22 sorry, blueprint 20:26:22 redrobot, to promote to 'check' requires a change to project-infra, not barbican. either way. i wanted to wait until Liberty before messing with the gate. 20:26:27 I don't assign LP blueprints to a release until they are implemented. 20:28:53 dave-mccowan it seems the experimental gate is working correctly now? I think we'll want to move it to the real pipelines soon, but leave it as non-voting. 20:29:58 redrobot +1 i'll do that. 20:30:17 dave-mccowan: +1 good stuff 20:30:17 arunkant since the barbican-spec repo is published to specs.openstack.org I think it would be best if it accurately represents the blueprints that get completed for each cycle 20:30:55 arunkant so, I'll probably send some CRs to the repo to move stuff around that landed but did not get implemented 20:31:13 arunkant I'll have to check other spec repos to see what they're doing. 20:31:28 any more questions/comments about Liberty blueprints? 20:32:00 redrobot, yes I was also thinking about http://specs.openstack.org/openstack/barbican-specs/ .. thanks for clarification 20:33:25 ok, moving on 20:33:40 #topic Stored-key RBAC 20:33:42 #link https://bugs.launchpad.net/barbican/+bug/1446266 20:33:43 Launchpad bug 1446266 in Barbican "RBAC needs to be checked for stored-key orders" [Undecided,New] 20:35:27 Currently you can submit an Order for a certificate using a stored-key. Barbican will use the key to create a CSR and submit to generate a Certificate 20:35:41 the problem is that no RBAC checks are being done on the stored key 20:36:00 so it's possible for someone to request a Certificate using a key for which they do not have access 20:36:25 as dave-mccowan pointed out, the certificate would not be of much use, since you'd still need to be able to retrieve the key to use it 20:37:07 redrobot, right - this is soemthing we needed to wait until the acl stuff was in, to fix. 20:37:35 redrobot, because you could potentially have access to the key through the acl mechanism 20:37:54 right, so the question is, do we need to address this for Kilo? 20:38:26 alee, redrobot, now the acl stuff is in, but there is no API to call rbac_enforce() except for the base API call. 20:39:02 dave-mccowan, understood -- its not a trivial problem to solve. 20:39:07 it doesn't leak the stored private key, but it does leak a certificate generated from it (that is also useless to use) 20:40:14 redrobot, woodster_ yeah - it seems like this can be pushed to Liberty 20:40:47 well, all other non-GET REST calls use the original project/roles based access. So if the stored key can't be retrieved via project ID, or if that retrieved key has an ACL list, it can be rejected. 20:40:54 alee, agreed! 20:41:08 redrobot, I'd check with reaperhulk though to make sure we're not missing anything pernicious. 20:41:27 but it woudl be good to note it in the documentation somehow. In general, it would be nice to mark things as experimental, but that dicussion can wait until the summit 20:43:23 woodster_ I don't really like the idea of shipping "experimental" software... 20:43:24 alee, even without RBAC, is there some project-id based validation that should be done? 20:43:43 woodster_, looks like currently new order checks that order project and container project are same. And needed roles are admin or creator. So will there be case where created cert would not be accessible? 20:44:13 woodster_, may be in the case where ACL is marked private. 20:44:27 s/ACL/container 20:44:29 arunkant, this concern is that the private key used to gen that cert is not accessible by the user that created the cert 20:45:48 redrobot, well then our definition of what is 'done done' for a release probably needs to change then :) We probably need to say releasable when all functional tests and docs are in place too. 20:45:55 dave-mccowan, are those checs currently being done in any case? 20:46:01 checks .. 20:46:18 redrobot, I'd still like to consider a feature flag approach that allows deployers to optional turn on/off features, esp. new ones. 20:46:46 dave-mccowan, iirc, the db queries that are being used went in before acl changes 20:47:06 which means they are implicitly selecting for project ownership 20:47:28 you have to explicitly use the non-project-constrained queries 20:48:08 in validators, the only container check for a stored-key certificate order is if the container is found. it would be nice if there was a functional test for this. 20:48:12 woodster_, +1 on the feature flag approach. 20:48:33 dave-mccowan, right -- but what query is being used? 20:49:02 redrobot, I think feature flag and experimental are good things for the summit. But for this bug, it seems we are ok with saying it is fixed in Liberty then? 20:49:49 yes, I think we're ok without backporting this fix to kilo 20:50:42 alee #link https://github.com/openstack/barbican/blob/master/barbican/common/validators.py#L101 it used project_Id. 20:51:24 dave-mccowan, right - that query is implicitly selecting only those for which the project_id = external_project_id 20:51:37 so the old mechanisms still apply 20:52:12 alee, as I said earlier..so the only issue is when container is marked private (does not want other users from same project to access it).. 20:52:26 yes, the POST orders is using the old project-ID/roles mechanism, so only stored keys available that way would be allowed 20:52:57 ...of course we could have a private/per-user POST orders call in Liberty....just sayin' 20:53:02 arunkant, or if you do have access via acl , but you cannot use them in this way 20:54:20 almost out of time here 20:54:30 alee, yes. if client is among acl users. But order logic can be changed easily to use rbac 20:54:34 but it seems we're all in agreement to fix this for Liberty, and ship Kilo as is 20:54:48 one last thing before we all go 20:54:55 #topic Liberty Design Summit 20:55:02 #link https://etherpad.openstack.org/p/barbican-L-design-sessions 20:55:09 please take some time to vote for topics 20:55:36 We've got 2 fishbowl sessions, and we'll need to figure out what topics to cover during that time. 20:56:13 redrobot, some folks have voted in this etherpad #link https://etherpad.openstack.org/p/barbican-L-design-sessions 20:56:48 woodster_ right, which is why I was asking for more votes. :) 20:57:27 oh sorry, I'm multitasking poorly 20:57:33 no worries 20:57:57 ok guys, thanks for coming! 20:58:01 #endmeeting