17:00:34 <tmcpeak> #startmeeting Security
17:00:35 <michaelxin> hi
17:00:35 <openstack> Meeting started Thu May 28 17:00:34 2015 UTC and is due to finish in 60 minutes.  The chair is tmcpeak. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:39 <openstack> The meeting name has been set to 'security'
17:00:46 <bknudson> I meant eh?
17:00:46 * sicarie waves
17:00:47 <tmcpeak> hi michaelxin, bknudson, tkelsey
17:00:51 <singlethink> o/
17:00:54 <dg__> hey tmcpeak
17:00:59 <tmcpeak> yo yo
17:01:00 <michaelxin> hi, tmcpeak
17:01:08 <tmcpeak> so we'll give a couple minutes for stragglers and then get going
17:01:12 <tmcpeak> meanwhile throw agenda items at me
17:01:38 <michaelxin> sounds good
17:01:47 <bknudson> bandit progress (world domination)
17:01:52 <elmiko> yo/
17:01:52 <tmcpeak> +1
17:01:53 <sicarie> not an agenda item, but more informational, there is also an #openstack-security room that many lurk in
17:01:54 <shelleea007> hi
17:02:13 <tmcpeak> yeah, a bunch of lurkers there ;)
17:02:33 <gmurphy> o/
17:02:50 <tkelsey> tmcpeak: item "bandit patches coming in post-vancouver"
17:02:52 <michaelxin> we did not finish reviewing https://etherpad.openstack.org/p/liberty-security-tooling
17:02:58 <tmcpeak> cool, got it
17:03:06 <michaelxin> should we spend some time on it and came up with some action items?
17:03:15 <tmcpeak> michaelxin - sure, sounds good
17:03:30 <sigmavirus24> A couple of those patches are mine. I'm sorry and you're welcome
17:03:41 <tmcpeak> sigmavirus24: ;)
17:03:49 <tmcpeak> ok cool, let's get going then
17:03:59 <tmcpeak> #topic Bandit Progress
17:04:07 <michaelxin> I heard that you guys plan to re-brand bandit, any movement?
17:04:21 <tmcpeak> tkelsey, bknudson, etc - take it away
17:04:36 <bknudson> bandit is now posting on keystonemiddleware -- https://review.openstack.org/#/c/178707/
17:04:39 <tmcpeak> michaelxin: I don't think we're doing that anymore (at least I don't know about it).  That was only if we couldn't get the name on PyPI
17:04:47 <tkelsey> cool, you should startmeeting tmcpeak :)
17:04:53 <tmcpeak> tkelsey: I have
17:04:55 <michaelxin> tmcpeak: Thanks.
17:04:56 <hyakuhei> o/
17:04:59 <tkelsey> oh wait, yeah sorry my bad lol
17:05:11 <tmcpeak> bknudson: awesome, how's it going?
17:05:20 <bknudson> keystonemiddleware is passing.
17:05:26 <bknudson> it was only turned on yesterday
17:05:26 <tmcpeak> sweet
17:05:39 <dg__> thats good work!
17:05:40 <bknudson> keystoneclient is waiting on https://review.openstack.org/#/c/178707/
17:05:41 <tmcpeak> so are all keystone properties running Bandit now?
17:05:42 <tkelsey> bknudson: awesome :)
17:05:49 <bknudson> we have a lot of repos
17:05:58 <sigmavirus24> we should add bandit to keystoneauth too
17:06:01 <bknudson> keystone and keystonemiddleware are the big ones
17:06:10 <sigmavirus24> since that'll be crucial for lots of projects
17:06:19 <tmcpeak> sigmavirus24: +1 , not sure what it is but it sounds important ;)
17:06:30 <jian5397> cool
17:06:30 <bknudson> keystoneauth is a new one that hasn't had a release yet
17:06:50 <bknudson> I don't think the bandit tests are as useful for the clients, but might as well get them working
17:06:59 <tmcpeak> bknudson: how come?
17:07:12 <bknudson> clients aren't going to use rootwrap for example
17:07:23 <sigmavirus24> bknudson: can probably catch other things though
17:07:24 <bknudson> I guess they might create temp files
17:07:28 <michaelxin> server side is more interesting
17:07:38 <tmcpeak> sure, actually the rootwrap test is not included in the Keystone profile I don't think
17:07:52 <tmcpeak> we don't have a good way to rule out false positives, so we'd have to use #nosec on all the safe rootwraps
17:07:53 <bknudson> what kinds of problems do you think bandit can catch in clients?
17:08:33 <bknudson> I guess they might decide to implement their own crypto for whatever reason
17:08:35 <tmcpeak> maybe handling creds insecurely, temp files, improper TLS handling, stuff like that?
17:08:46 <tmcpeak> bknudson: I would sure hope not ;)
17:08:56 <tkelsey> tmcpeak: +1
17:09:14 <michaelxin> tmcpeak: +1
17:09:15 <sigmavirus24> bknudson: like glanceclient?
17:09:16 <sigmavirus24> yeah
17:09:17 <bknudson> it'll eventually be enabled for everything in keystone
17:09:21 <sigmavirus24> glanceclient has it's own crypto at the moment
17:09:27 <tmcpeak> :|
17:09:30 <sigmavirus24> yea
17:09:33 <sigmavirus24> I'm working on it
17:09:51 <tmcpeak> own crypto like algorithm or implementation of a known algorithm?
17:09:51 <michaelxin> insecure logging might be another one
17:09:59 <tmcpeak> michaelxin: +1
17:10:12 <sigmavirus24> tmcpeak: as in implementation of a verifying an https connection so they can set special opts with pyOpenSSL
17:10:29 <tmcpeak> ahh ok, so it's shelling out to OpenSSL or something?
17:10:30 <sigmavirus24> By working on it, I mean I'm working on requests and urllib3 so we can stop those shenanigans
17:10:37 <sigmavirus24> tmcpeak: pyOpenSSL doesn't shell out
17:10:51 <sigmavirus24> Either way, that's a distraction of sorts
17:11:02 <sigmavirus24> Back to the meeting ;)
17:11:06 <tmcpeak> sigmavirus24: oh good, getting that addressed in requests and urllib3 would be very useful in other cases too
17:11:13 <sigmavirus24> yep
17:11:20 <sigmavirus24> that's why I'm working on it :D
17:11:22 <tmcpeak> cool, bknudson: thanks for all the work pushing this in Keystone
17:11:28 <michaelxin> sigmavirus24: good job
17:11:34 <sicarie> tmcpeak: maybe an action to hyakuhei on his 'overarching crypto monitoring' idea?
17:11:51 <tkelsey> sigmavirus24: out of interest did we chat at vancouver about some pyOpenSSL stuff
17:11:53 <tmcpeak> for sure, I believe gmurphy is working on something along those lines too
17:12:08 <sigmavirus24> tkelsey: maybe? I talked to lots of people at the summit
17:12:17 <sigmavirus24> That said, if not we can chat in #openstack-security about it more
17:12:25 <tkelsey> heh yeah same, sure
17:12:26 <tmcpeak> cool
17:12:29 <tmcpeak> so item 2
17:12:35 <tmcpeak> #topic Liberty Security Tooling
17:12:38 <tmcpeak> michaelxin: this is your item
17:12:50 <tmcpeak> #link https://etherpad.openstack.org/p/liberty-security-tooling
17:13:08 <tmcpeak> want to describe what's going on here?
17:13:11 <michaelxin> We talked about this during summit design session
17:13:30 <tmcpeak> cool, any consensus or resulting action items?
17:13:37 <michaelxin> We used the ether pad to track the projects or ideas
17:13:46 <michaelxin> No, we do not have any action item yet.
17:14:01 <michaelxin> I am not sure about the next step
17:14:17 <michaelxin> Should we send this list to the email list and ask for feedbacks
17:14:28 <tmcpeak> so it looks like this is broken into several categories
17:14:30 <tkelsey> Is this working towards a proposal for new tools?
17:14:36 <tmcpeak> improvements to existing projects: Anchor, Bandit
17:14:50 <tmcpeak> proposals for new tools: IDS, Rest API fuzzer, config validator
17:14:51 <michaelxin> it is just like brainstorming
17:14:54 <tmcpeak> and open questions
17:14:59 <michaelxin> yes
17:15:02 <tkelsey> oh ok, cool
17:15:03 <dg__> improvements to Bandit - write a roadmap?
17:15:05 <tkelsey> good stuff
17:15:09 <elmiko> might be worth looking at cdent's gabbi tool to do api fuzzing
17:15:12 <tkelsey> dg__: im on it :)
17:15:31 <tkelsey> elmiko: good stuff, please add info to the etherpad
17:15:37 <elmiko> tkelsey: will do
17:15:39 <tmcpeak> dg__: tkelsey has expressed a never-ending passion for doc improvement, so he's going to get Bandit whipped into shape
17:15:49 <dg__> tkelsey is my hero
17:15:49 <tmcpeak> :P
17:15:57 <michaelxin> tmcpeak: +1
17:15:58 <dg__> Im getting a t-shirt printed up with that on
17:16:04 <tkelsey> lol, well when you put it that ... :P but yeah I am going to get stuck in
17:16:04 <tmcpeak> lol
17:16:31 <bknudson> we need a photo of tkelsey
17:16:34 <tmcpeak> personally I'd be very interested in some good API slamming tools
17:16:45 <michaelxin> tmcpeak: +1
17:16:57 <michaelxin> We can work on it
17:17:06 <tmcpeak> I'm not the biggest Tempest fan in the world though ;) maybe I had a bad early experience
17:17:14 <sigmavirus24> tmcpeak: no that's justified
17:17:23 <sicarie> michaelxin: I think you mentioned that you guys are currently doing REST fuzzing - will any of that be submitted upstream? (or am I wrong about you mentioning that?)
17:17:24 <michaelxin> Tempest is for integration
17:17:25 * sigmavirus24 speaks as someone with recent bad tempest experiences
17:17:32 <tmcpeak> michaelxin: that would be great! I'm sure you'll get some contributors to pitch in too
17:17:44 <tmcpeak> sigmavirus24: good to see it hasn't changed much :)
17:17:45 <michaelxin> sicarie: Yes.
17:17:53 <michaelxin> Some of them are Tempest.
17:18:01 <michaelxin> Some of them are our own QE tools
17:18:08 <sigmavirus24> tmcpeak: it's stable of course
17:18:19 <michaelxin> We are thinking about creating our own API fuzzing tool.
17:19:00 <tmcpeak> that would be great
17:19:03 <bknudson> part of this might require having schemas for the openstack apis
17:19:10 <tmcpeak> I mean if you open source it :)
17:19:12 <michaelxin> There is still debate in QA about Tempst
17:19:26 <sicarie> michaelxin: and is there any plan to submit that upstream, or assist in outlining an open version?
17:19:29 <sigmavirus24> bknudson: yeah. Glance v1, for example, has 0 schemas
17:19:37 <michaelxin> Our QE tool is open source
17:19:58 <michaelxin> https://github.com/stackforge/opencafe
17:19:58 <gmurphy> http://developer.openstack.org/api-ref-image-v2.html
17:20:15 <michaelxin> Yes, we will for sure
17:20:20 <gmurphy> most of the schema details are there
17:20:23 <tkelsey> michaelxin: could you put any details into the etherpad please, so we can collect stuff there
17:20:26 <bknudson> y, but a computer readable schema so that a fuzzer could use it
17:20:33 <michaelxin> tkelsey: Got it.
17:20:37 <tkelsey> thanks :)
17:20:39 <tmcpeak> bknudson: +1
17:20:39 <sigmavirus24> gmurphy: that's for v2 though
17:20:42 <gmurphy> oh right.
17:20:45 <gmurphy> v1 is there too
17:20:47 <sigmavirus24> v2 has schemas
17:20:48 <elmiko> this might dovetail nicely into some of the swagger ideas that have been circling around
17:21:01 <sigmavirus24> elmiko: don't you bring none of that API-WG nonsense in here ;)
17:21:02 <bknudson> y, I was thinking about swagger
17:21:15 <elmiko> sigmavirus24: lol
17:22:39 <tmcpeak> cool
17:22:44 <tmcpeak> so seems like we have some good ideas for tools
17:23:18 <tmcpeak> anybody want to take action items for future research here?
17:23:27 * sicarie volunteers
17:23:31 <tmcpeak> or I guess what I'm asking is how can we carry these from ideas into things
17:23:41 <tmcpeak> sicarie: awesome, what are you volunteering for
17:23:42 <tmcpeak> ?
17:23:48 <sicarie> tmcpeak: no idea
17:23:52 <tkelsey> LOL
17:23:56 <tmcpeak> haha
17:23:57 <michaelxin> I for API fuzzing
17:24:01 <elmiko> i've done a bunch with swagger, i can certainly participate with discussions about api fuzzing
17:24:03 <shelleea007> i'd be interested in helping
17:24:08 <tmcpeak> #action michaelxin to look into API fuzzing options
17:24:14 <sicarie> Yeah, I'll help with michaelxin with API fuzzing if he needs it
17:24:21 <michaelxin> sicarie: sure
17:24:24 <sicarie> Or another item if it needs effort
17:24:26 <tkelsey> michaelxin: awesome shelleea007 sicarie awesome
17:24:34 <tmcpeak> #action elmiko to look into API fuzzing options
17:24:49 <tmcpeak> #action sicarie to look into API fuzzing options
17:25:01 <tmcpeak> cool, so that's a good group on that
17:25:13 <tmcpeak> maybe you guys can synch up in #openstack-security and provide an update next week or so?
17:25:24 <michaelxin> sounds good
17:25:37 <tmcpeak> #action shelleea007 to look into API fuzzing options
17:25:47 <tmcpeak> sorry shelleea007, didn't see your name there too :)
17:25:55 <tmcpeak> sweet
17:26:15 <tmcpeak> #topic Signed Requirements
17:26:36 <tmcpeak> so I've been looking into getting the OpenStack requirements signed before they go to PyPI
17:26:37 <shelleea007> its ok, I'm used to being ignored :p
17:27:06 <tmcpeak> I think I have a plan, I'm just ironing out some last minute details and then we can have a full discussion about it in a soon future meeting
17:27:31 <tmcpeak> the idea is though, that unless somebody goes and retrieves each requirement from the author page directly, we are vulnerable
17:27:56 <tmcpeak> PyPI credentials can be compromised and used to upload a malicious version of a package and cause all kinds of bad
17:28:22 <tmcpeak> this is something I'm planning to move to the top of my personal stack, and once I get everything ironed out I'll greatly appreciate help from the community
17:28:32 <tmcpeak> does anybody have any thoughts or questions about this idea?
17:28:38 <elmiko> how can we help out =)
17:28:52 <tmcpeak> elmiko: awesome :) I was hoping you might say that
17:28:58 <elmiko> LOL
17:29:14 <bknudson> sign not only the package but also require the bandit results and sign them.
17:29:24 <tmcpeak> so we'll need to create some simple guidance about how to get set up for GPG signing and upload a signed package to PyPI
17:30:06 <tmcpeak> bknudson: that would be perfect world, but I'm hoping to convince each developer of every requirement to give 10 minutes to the cause and sign and reupload their package, if we can get that we're in much better shape
17:30:23 <bknudson> do you have an example of a signed project?
17:30:35 <tmcpeak> sure, one sec
17:30:46 <elmiko> would this documentation live on security.openstack.org?
17:30:50 <sigmavirus24> tmcpeak: you'll be using twine, right?
17:30:53 <bknudson> I assume bandit is
17:31:02 <sigmavirus24> since twine is the only project that can securely upload packages to PyPI
17:31:07 <tmcpeak> https://pypi.python.org/pypi/argcomplete
17:31:14 <tmcpeak> bknudson: actually bandit is not
17:31:15 <sigmavirus24> it also has a way of uploading signatures and doing signing for you
17:31:28 <tmcpeak> sigmavirus24: oh does, twine do the signing for you?
17:31:32 <sigmavirus24> tmcpeak: yep
17:31:35 <tmcpeak> oh sweet
17:31:36 * sigmavirus24 maintains too many things
17:31:40 <bknudson> I'm wondering how you tell if it's signed or not
17:31:51 <tmcpeak> even better!  one of the early items was to find the easiest path to get a signed package on PyPI
17:31:52 <sigmavirus24> bknudson: I believe it uploads an asc
17:31:59 <tmcpeak> bknudson: it's difficult to tell, but you can tell by looking at the json
17:32:08 <tmcpeak> https://pypi.python.org/pypi/argcomplete/json
17:32:20 <sigmavirus24> I'm probably wrong though, it's been a while since I touched that part of PyPI/twine integration
17:32:34 <tmcpeak> bknudson: yeah, sigmavirus24 is right, it uploads an asc, which isn't linked on the actual page, but you can download it by appending .asc to the end of the actual package you are downloading
17:32:51 <michaelxin> it is not very easy to follow
17:33:04 <tmcpeak> so one of the foundations of this effort is that we aren't requiring any server side improvements to PyPI
17:33:10 <bknudson> has_sig = false for python-keystoneclient
17:33:12 <sigmavirus24> michaelxin: it should get better when dstufft actually gets warehouse out the door iiuc
17:33:19 <michaelxin> it is still using md5
17:33:28 <sigmavirus24> michaelxin: it's switching to sha256 shortly
17:33:29 <tmcpeak> I've spoken to Donald Stufft - dstufft , and he has his hands full with Warehouse
17:33:42 <sigmavirus24> the blocker was that devpi didn't support sha256
17:33:46 <tmcpeak> those signatures aren't what we're talking about… that's just for error detection
17:33:50 <sigmavirus24> so now that it has a release with that, Donald will cut over
17:33:54 <sigmavirus24> tmcpeak: correct
17:34:08 <elmiko> tmcpeak: just to clarify, is some of the intent here to help get more openstack project signed in pypi, like across the board?
17:34:29 <tmcpeak> also it won't help, the threat we're trying to prevent is a developer credentials becoming compromised and they upload a malicious version, which PyPI would happily calculate a sha256 sum for and everything would appear dandy
17:34:33 <michaelxin> elmiko: +1
17:34:52 <michaelxin> But it can happen to any developer, right?
17:34:52 <bknudson> twine isn't signed so we can't trust that either
17:34:54 <tmcpeak> elmiko: yes, the intent is to get every single think in global requirements signed
17:35:15 <elmiko> ack, tnx
17:35:39 <tmcpeak> bknudson: you're correct, any tooling which itself has not been signed can't be relied on
17:35:41 <bknudson> twine 1.1.1 has_sig but 1.4.0 lost it.
17:35:50 <michaelxin> gee
17:35:57 <sigmavirus24> bknudson: yeah because I took it over from Donald
17:36:10 <bknudson> just use Donald's sig
17:36:11 <tmcpeak> sigmavirus24: oh, twine is yours?
17:36:16 <sigmavirus24> tmcpeak: I maintain it
17:36:21 <sigmavirus24> It's PyPA's to be exact
17:36:27 <sigmavirus24> Donald wrote it initially
17:36:32 <tmcpeak> sigmavirus24: awesome! one of the things on my list was to find who is in charge of twine
17:36:36 <sigmavirus24> Like I said, I maintain too many things
17:36:47 <elmiko> hehe
17:37:01 <michaelxin> sigmavirus24: +1
17:37:07 <tmcpeak> so the developer guidance that we'll create will also include to use twine, to prevent (among other things) credentials becoming compromised because setuptools standard upload process does not validate TLS
17:37:34 <elmiko> sounds nice
17:37:45 <michaelxin> tmcpeak: +1
17:37:56 <tmcpeak> I believe it is the simplest way to get what we want, but I'll definitely want all of your opinions and help on it
17:38:22 <elmiko> tmcpeak: for sure, i would love to see this kind of guidance
17:38:24 <tmcpeak> I should have all details of plan firmed up in the next week and then I'll open it up and see if anybody has concerns and who would like to work on it
17:38:29 <tmcpeak> sweet
17:38:55 <tmcpeak> #topic Other Business
17:39:03 <tmcpeak> open floor, anybody have anything they want to discuss?
17:39:21 <michaelxin> I have one question
17:39:26 <tmcpeak> michaelxin: sure, what's up?
17:39:41 <tkelsey> nothing from me, other than to say thanks to folks pushing bandit patches :) lots of interest after Vamcouver
17:39:49 <michaelxin> Does security involved with defcore by any chance?
17:40:06 <michaelxin> It will be cool if they include security requirements there
17:40:09 <tmcpeak> michaelxin: good question, I have no idea
17:40:11 <bknudson> does defcore have any interest in security?
17:40:22 <bknudson> I thought it was just API compatibility
17:40:38 <bknudson> seems like there are already lots of cloud security standards
17:40:48 <hogepodge> michaelxin: right now it's focused on APIs, so non-secure endpoints would pass tests
17:41:01 <michaelxin> got it.
17:41:03 <michaelxin> Thanks
17:41:17 <bknudson> it would still be interesting to get security tests into tempest
17:41:21 <hogepodge> michaelxin: bknudson: That doesn't preclude it being part of the testing standard, though. It's just not part of it right now.
17:41:42 <tmcpeak> I haven't looked at security tempest tests lately, what's the state of them?
17:41:46 <bknudson> we need a "secure" gate
17:41:52 <sigmavirus24> re bandit on Python 3: I just want it to be clear that Bandit's AST parsing will be made to work on Py 2 and Py 3 just like PyFlakes does
17:42:11 <elmiko> sigmavirus24: nice
17:42:11 <sigmavirus24> Any code being tested with bandit run on Py 3 would have to have valid Python 3 syntax
17:42:26 <tmcpeak> tkelsey: doesn't it currently work against Py3 code?
17:42:34 <sigmavirus24> And any code tested where bandit is run on Py 2 would need valid Python 2 syntax
17:43:09 <sigmavirus24> There are also checks that will need to be done conditionally. The exec plugin will need to work differently on different versions. `exec` is both a statement and a function on Py2. On Py3 it's only a function
17:43:10 <tkelsey> tmcpeak: I _think_ the ast should be similar enough that bandit can test py3 code
17:43:36 <sigmavirus24> tkelsey: as long as the Py3 code is also valid Py2 syntax since you'd be compiling with Py2's AST
17:43:38 <bknudson> let's drop py2 support
17:43:43 <sigmavirus24> bknudson: let's not
17:43:45 <tmcpeak> haha
17:43:52 <michaelxin> sigmavirus24: +1
17:43:57 <sigmavirus24> It's a bad idea until all the projects are off py2
17:44:08 <tkelsey> sigmavirus24: +1
17:44:10 <sigmavirus24> THEN we can drop Py2 support ;)
17:44:13 <tmcpeak> sigmavirus24: so is it a different AST lib for Py3 or something?
17:44:19 <sigmavirus24> tmcpeak: yes
17:44:24 <tmcpeak> ahhh
17:44:28 <sigmavirus24> Same basic API but the symbols from _ast are different
17:44:34 <sigmavirus24> So TryExcept/TryFinally are just ast.Try now
17:44:44 <sigmavirus24> ast.Exec doesnt' exist since exec isn't a statement
17:44:44 <elmiko> interesting...
17:44:45 <sigmavirus24> etc.
17:44:49 <dg__> Is there much py3 adoption in openstack?
17:44:50 <sigmavirus24> I've done this before
17:44:55 * sigmavirus24 worked on pyflakes
17:44:57 <tmcpeak> hmm, yeah.. so it seems like even the plugins would have to be Py3 aware
17:44:58 <tkelsey> sigmavirus24: thats very interesting
17:44:59 <sigmavirus24> dg__: we're moving towards it so yes
17:45:01 <bknudson> all the clients use py3
17:45:10 <sigmavirus24> tmcpeak: yep
17:45:21 <bknudson> can we change the bandit tox job to use py3 then?
17:45:23 <sigmavirus24> @checks('Exec') is the current blocker on the tests passing on Py34 right now
17:45:30 <sigmavirus24> bknudson: tox -e py34 just works
17:45:31 <tmcpeak> I wonder if there is some way to abstract that complexity away
17:45:39 <sigmavirus24> tmcpeak: oh god, don't get me started
17:45:39 <bknudson> I mean the keystone tox -e bandit
17:45:43 <sigmavirus24> bknudson: ah
17:45:53 <tmcpeak> would be nice to free plugin writers from worrying about those intracacies
17:45:54 <tmcpeak> lol
17:45:56 <sigmavirus24> bknudson: well it won't work for a while
17:45:59 <bknudson> I didn't think about the interpreter
17:45:59 <tkelsey> I guess there is no six for the ast lol
17:46:05 <sigmavirus24> tkelsey: there isn't
17:46:10 <sigmavirus24> I thought about doing it once
17:46:12 <michaelxin> Another topic is container is so popular in the summit. Should we plan something too?
17:46:15 <sigmavirus24> And then nope.gif'd right out fthere
17:46:15 <bknudson> looks like we just need to set basepython = python3.4
17:46:28 <tmcpeak> hahaha
17:46:44 <tkelsey> michaelxin: yeah its been noted, we should think about things in that space for sure
17:46:57 <tmcpeak> michaelxin, tkelsey: yeah, agree
17:46:58 <bknudson> tell me when bandit works with py34 and I'll update my tox.ini s
17:47:09 <tmcpeak> I guess we could start by taking a good hard look at Magnum
17:47:15 <michaelxin> tkelsey: tmcpeak: Cool, Thanks.
17:47:21 <tkelsey> tmcpeak: +1
17:47:35 <sigmavirus24> bknudson: good to hear. I'll keep you in the loop
17:47:41 <sigmavirus24> bknudson: also add you to the review =P
17:47:44 <elmiko> makes sense, it seems like the state of the art hasn't caught up with all the ideas about signed containers and what not though
17:49:30 <tmcpeak> cool, anything else to discuss before we wrap for the day?
17:49:36 <michaelxin> no, thanks.
17:50:06 <sicarie_> tmcpeak: a fun note  - the install docs recommend disabling firewalls
17:50:11 <tmcpeak> wut
17:50:16 <elmiko> lol
17:50:18 <tmcpeak> which install docs?
17:50:32 <sicarie_> ubuntu
17:50:37 <tmcpeak> wut
17:50:44 <tmcpeak> link?
17:50:44 <sigmavirus24> sicarie_: the install guide from OpenStack or is this Ubuntu's docs?
17:50:57 <sicarie_> sigmavirus24: from OpenStack
17:51:05 <sicarie_> tmcpeak: looking
17:51:07 <tmcpeak> oh man
17:51:20 <sigmavirus24> sicarie_: you can file a bug for that on the openstack-manuals project
17:51:25 <sigmavirus24> And mark me as nosey or whatever LaunchPad calls it
17:51:42 <tmcpeak> yeah, please do… that's horrible.  We should never be recommending flat out disabling the firewall
17:51:50 <sicarie_> sigmavirus24: sure
17:52:03 <tmcpeak> 1) people just magically forget to put it back,  2) it's lazy guidance
17:52:26 <sigmavirus24> In the install guide's defense, it's not meant as a guide to deploying a production cloud
17:52:37 <sigmavirus24> I don't think it's right, but it's the purpose of the guide
17:52:41 <tmcpeak> fair enough
17:52:55 <michaelxin> sicarie_: Good catch
17:53:02 <sigmavirus24> also openstack-doc is a good channel to discuss this in
17:53:06 <tmcpeak> yeah, sicarie_: great catch
17:53:07 <sigmavirus24> with the doc writers who likely wrote that
17:53:20 <dave-mccowan> has any project made bandit a voting job in the gate?  we're thinking about it for barbican.
17:53:21 <sicarie_> sigmavirus24: I was in the docs working group at the summit when that was brought up
17:53:36 <sigmavirus24> dave-mccowan: bknudson added it to keystone
17:53:49 <bknudson> dave-mccowan: it's not voting.
17:53:54 <bknudson> yet.
17:53:56 <michaelxin> we can work with barbican team to add it
17:54:04 <tmcpeak> dave-mccowan: not yet that I'm aware of, I'd really encourage it though
17:54:05 <elmiko> dave-mccowan: same for sahara, we have it non-voting
17:54:11 <bknudson> I'll request to make it voting soon enough
17:54:30 <elmiko> ours needs more tuning and some local bug fixes to sahara before we go voting
17:54:38 <dave-mccowan> i added it as non-voting to barbican.  we're discussing to make it voting, but don't want to be first. :-)
17:54:42 <tmcpeak> elmiko: if you would like any help with it please let us know
17:54:50 <sicarie_> #link: http://docs.openstack.org/icehouse/install-guide/install/yum/content/basics-networking.html
17:54:50 <tmcpeak> haha
17:54:51 <elmiko> tmcpeak: awesome, will do!
17:55:02 <sicarie_> During this installation, certain steps will fail unless you alter or disable the firewall.
17:55:05 <tmcpeak> only bknudson has the stomach to be first :D
17:55:06 <tkelsey> elmiko: dave-mccowan i can help as well
17:55:26 <tkelsey> bknudson: trail blazing  :)
17:55:26 <elmiko> tkelsey: ack, thanks
17:55:30 <sicarie_> my bad, it was the rh guide, the ubuntu guide calls out that iptables/ufw is disabled by default
17:55:41 <bknudson> if there's a new release of bandit and it doesn't break us then I'll be happy to make it voting
17:56:01 <bknudson> otherwise I'll just request to make it voting after it's been running a while
17:56:17 <tmcpeak> sicarie: :| - I think we should file a bug against that
17:56:22 <tkelsey> that seems sensible
17:56:23 <bknudson> the bandit job was broken for a while
17:56:24 <michaelxin> bknudson: +1
17:56:32 <tkelsey> bknudson: oh?
17:56:33 <tmcpeak> bknudson: broken how?
17:56:43 <bknudson> because I used bandit~=0.10 or whatever
17:56:49 <tkelsey> ahh ok
17:56:54 <bknudson> and something changed so that wasn't working anymore
17:57:10 <sicarie_> tmcpeak: done
17:57:10 <bknudson> it's fixed since we switched to having a test-requirements-bandit.txt
17:57:30 <tkelsey> bknudson: interesting, sorry for the breakage
17:57:40 <sicarie_> sigmavirus24: just added you to the bug
17:57:45 <bknudson> it was my own fault for trying to be on the bleeding edge
17:57:52 <tmcpeak> oh yeah.. ~=0.10 was pulling a version that we knew wouldn't work, right?
17:58:06 <bknudson> no, it was something didn't understand ~= format
17:58:14 <bknudson> not bandit related at all
17:58:18 <tmcpeak> oh yeah, that's right
17:58:33 <tmcpeak> cool.  We'll get another Bandit release fairly soon to ease your troubled mind bknudson
17:58:50 <tmcpeak> :D
17:59:03 <tmcpeak> allright all, that's about it for the meeting, any last (quick thoughts)?
17:59:10 <bknudson> I'll always have a troubled mind.
17:59:10 <tmcpeak> I guess we can roll over to #openstack-security if so
17:59:14 <tmcpeak> lol
17:59:20 <tmcpeak> great meeting everybody, thanks for coming
17:59:22 <tmcpeak> have a good week!
17:59:24 <tmcpeak> #endmeeting