20:00:28 <redrobot> #startmeeting barbican
20:00:29 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:32 <openstack> The meeting name has been set to 'barbican'
20:00:53 <redrobot> #topic Roll Call
20:01:00 <arunkant> o/
20:01:03 <elmiko> hiyo/
20:01:03 <dave-mccowan> \o/
20:01:10 <igueths> Hola.
20:02:13 <jaosorior> Yo
20:03:18 <redrobot> #topic Action Items
20:03:29 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-04-13-19.59.html
20:03:49 <redrobot> Many thanks to elmiko for getting the Juno->Kilo migration working
20:04:00 * elmiko tips fedora
20:04:09 <woodster_> o/
20:04:12 <tkelsey> o/
20:04:14 <redrobot> on to my action items
20:04:25 <woodster_> elmiko, agreed!
20:04:33 <chellygel> o/
20:04:39 <redrobot> 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 <jvrbanac> o/
20:04:53 <redrobot> so you can "pip install castellan" now
20:05:02 <elmiko> huzzah!
20:05:21 <tkelsey> +1
20:05:25 <tkelsey> good stuff
20:05:36 <redrobot> 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 <redrobot> #link https://pypi.python.org/pypi/castellan
20:06:35 <redrobot> Also, I emailed the dev list earlier today to ask about minor changes in the API
20:06:37 <redrobot> #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/062021.html
20:06:49 <redrobot> looks like there were some replies since then
20:07:02 <redrobot> so take a look, and chime in if you'd like
20:07:55 <redrobot> and lastly, I did not get a chance to talk to Greg
20:07:56 <redrobot> so
20:08:14 <redrobot> #action redrobot to talk to Greg Swift about DB being used in Fedora
20:08:39 <redrobot> on to the agenda for today
20:08:44 <redrobot> which as usual can be found here:
20:08:48 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:08:54 <redrobot> #topic Kilo RC1
20:09:08 <redrobot> #link https://launchpad.net/barbican/+milestone/kilo-rc1
20:09:34 <redrobot> Kilo RC1 was released this morning, which means that the master branch is now tracking the Liberty release
20:10:39 <redrobot> also, we have a stable/kilo branch now for bugfixes etc
20:11:07 <redrobot> any questions/comments about RC1 ?
20:11:41 <chellygel> you mentioned there being an RC2 possibly
20:11:44 <chellygel> is that still happening? redrobot ?
20:12:27 <redrobot> 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 <chellygel> coo
20:13:48 <arunkant> redrobot, so for barbican specs, is there a liberty folder defined? I need to move audit spec from kilo.
20:14:10 <redrobot> arunkant good question, as it leads to the next topic
20:14:29 <redrobot> #topic What approved or drafting blueprints do we want to bring over to Liberty?
20:15:09 <redrobot> arunkant there is no Liberty directory yet.  usually the first blueprint proposed for the new cycle creates the new directory
20:15:31 <redrobot> afaik, you can't check in an empty directory in git
20:16:29 <arunkant> okay. makes sense. Will create one if not there at the time of my checkin
20:16:34 <redrobot> woodster_ did you have any particular blueprints in mind for this topic?
20:17:05 <woodster_> redrobot, it was more for folks to air out ones that don't want to bring over really.
20:17:42 <woodster_> redrobot: I'll bring over the TLS ones I put in there. tsv will hopefully bring over the quota one :)
20:18:26 <woodster_> redrobot, we probably want to bring over the version resource bp as well
20:19:02 <redrobot> 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 <redrobot> 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 <redrobot> #action redrobot to clean up the barbican-specs repo
20:20:08 <dave-mccowan> 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 <woodster_> redrobot, you have the #link https://blueprints.launchpad.net/barbican/+spec/active-secret-store spec
20:20:56 <redrobot> dave-mccowan usually the CR should include the spec it implements in the commit message
20:21:13 <woodster_> alee, you have the #link https://blueprints.launchpad.net/barbican/+spec/expose-ca-enrollment-templates one out there
20:21:25 <redrobot> dave-mccowan I can fix it in launchpad for the blueprints you worked on.
20:21:57 <redrobot> woodster_ I don't think alee made it to this meeting.
20:22:17 <arunkant> 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 <woodster_> redrobot: what? so much for perfect attendance for him
20:22:22 <tkelsey> dave-mccowan: did you say there was a bandit gate implemented?
20:22:49 <woodster_> arunkant: I was hoping tsv would do that as part of continuing to work on that feature
20:23:06 <redrobot> arunkant yes, I'll move those over as part of the spec cleanup
20:23:40 <dave-mccowan> tkelsey yes, as experimental.  "check experimental" in gerrit. or "tox -e bandit" locally.
20:23:50 <redrobot> woodster_ I haven't seen tsv in weeks.  He may not be available to work on that blueprint
20:24:05 <tkelsey> dave-mccowan: oh awesome :D I didnt know that (probably should have lol)
20:24:11 <woodster_> redrobot, sadness :\
20:24:22 <arunkant> woodster_, I am just trying to understand the process around this. Especially the spec is already merged to master.
20:24:26 <redrobot> dave-mccowan tkelsey I don't think adding a gate to the experimental pipeline would count as completing a blueprint?
20:25:05 <woodster_> arunkant, the CR would need to move the spec rst file from the kilo folder to the liberty one
20:25:52 <woodster_> redrobot, the LP blueprint would also need to be revised to point to Liberty, correct?
20:26:09 <redrobot> not necessarily
20:26:11 <tkelsey> 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 <tkelsey> sorry, blueprint
20:26:22 <dave-mccowan> 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 <redrobot> I don't assign LP blueprints to a release until they are implemented.
20:28:53 <redrobot> 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 <dave-mccowan> redrobot +1  i'll do that.
20:30:17 <tkelsey> dave-mccowan: +1 good stuff
20:30:17 <redrobot> 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 <redrobot> 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 <redrobot> arunkant I'll have to check other spec repos to see what they're doing.
20:31:28 <redrobot> any more questions/comments about Liberty blueprints?
20:32:00 <arunkant> redrobot, yes I was also thinking about http://specs.openstack.org/openstack/barbican-specs/ .. thanks for clarification
20:33:25 <redrobot> ok, moving on
20:33:40 <redrobot> #topic Stored-key RBAC
20:33:42 <redrobot> #link https://bugs.launchpad.net/barbican/+bug/1446266
20:33:43 <openstack> Launchpad bug 1446266 in Barbican "RBAC needs to be checked for stored-key orders" [Undecided,New]
20:35:27 <redrobot> 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 <redrobot> the problem is that no RBAC checks are being done on the stored key
20:36:00 <redrobot> so it's possible for someone to request a Certificate using a key for which they do not have access
20:36:25 <redrobot> 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 <alee> redrobot, right - this is soemthing we needed to wait until the acl stuff was in, to fix.
20:37:35 <alee> redrobot, because you could potentially have access to the key through the acl mechanism
20:37:54 <redrobot> right, so the question is, do we need to address this for Kilo?
20:38:26 <dave-mccowan> 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 <alee> dave-mccowan, understood -- its not a trivial problem to solve.
20:39:07 <woodster_> 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 <alee> redrobot, woodster_ yeah - it seems like this can be pushed to Liberty
20:40:47 <woodster_> 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 <woodster_> alee, agreed!
20:41:08 <alee> redrobot, I'd check with reaperhulk though to make sure we're not missing anything pernicious.
20:41:27 <woodster_> 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 <redrobot> woodster_ I don't really like the idea of shipping "experimental" software...
20:43:24 <dave-mccowan> alee, even without RBAC, is there some project-id based validation that should be done?
20:43:43 <arunkant> 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 <arunkant> woodster_, may be in the case where ACL is marked private.
20:44:27 <arunkant> s/ACL/container
20:44:29 <woodster_> 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 <woodster_> 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 <alee> dave-mccowan, are those checs currently being done in any case?
20:46:01 <alee> checks ..
20:46:18 <woodster_> 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 <alee> dave-mccowan, iirc, the db queries that are being used went in before acl changes
20:47:06 <alee> which means they are implicitly selecting for project ownership
20:47:28 <alee> you have to explicitly use the non-project-constrained queries
20:48:08 <dave-mccowan> 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 <alee> woodster_, +1 on the feature flag approach.
20:48:33 <alee> dave-mccowan, right -- but what query is being used?
20:49:02 <woodster_> 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 <redrobot> yes, I think we're ok without backporting this fix to kilo
20:50:42 <dave-mccowan> alee #link https://github.com/openstack/barbican/blob/master/barbican/common/validators.py#L101   it used project_Id.
20:51:24 <alee> dave-mccowan, right - that query is implicitly selecting only those for which the project_id = external_project_id
20:51:37 <alee> so the old mechanisms still apply
20:52:12 <arunkant> 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 <woodster_> 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 <woodster_> ...of course we could have a private/per-user POST orders call in Liberty....just sayin'
20:53:02 <alee> arunkant, or if you do have access via acl , but you cannot use them in this way
20:54:20 <redrobot> almost out of time here
20:54:30 <arunkant> alee, yes. if client is among acl users. But order logic can be changed easily to use rbac
20:54:34 <redrobot> but it seems we're all in agreement to fix this for Liberty, and ship Kilo as is
20:54:48 <redrobot> one last thing before we all go
20:54:55 <redrobot> #topic Liberty Design Summit
20:55:02 <redrobot> #link https://etherpad.openstack.org/p/barbican-L-design-sessions
20:55:09 <redrobot> please take some time to vote for topics
20:55:36 <redrobot> We've got 2 fishbowl sessions, and we'll need to figure out what topics to cover during that time.
20:56:13 <woodster_> redrobot, some folks have voted in this etherpad #link https://etherpad.openstack.org/p/barbican-L-design-sessions
20:56:48 <redrobot> woodster_ right, which is why I was asking for more votes. :)
20:57:27 <woodster_> oh sorry, I'm multitasking poorly
20:57:33 <redrobot> no worries
20:57:57 <redrobot> ok guys, thanks for coming!
20:58:01 <redrobot> #endmeeting