17:00:11 <tmcpeak> #startmeeting security
17:00:11 <angdraug> Tuesday then
17:00:15 <openstack> Meeting started Thu Feb 18 17:00:11 2016 UTC and is due to finish in 60 minutes.  The chair is tmcpeak. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:17 <tmcpeak> o/
17:00:19 <openstack> The meeting name has been set to 'security'
17:00:22 <elmiko> o/
17:00:24 <ccneill> o/
17:00:24 <browne> hi
17:00:27 <cjschaef> hi
17:00:36 <singlethink> o/
17:00:44 <sicarie> o/
17:00:55 <tmcpeak> #link https://etherpad.openstack.org/p/security-20160218-agenda
17:01:04 <tmcpeak> please add things to ^
17:01:07 <mdong> o/
17:01:08 <tmcpeak> if you're so inclined
17:01:14 <mvaldes> o/
17:01:57 <tmcpeak> hyakuhei can't be here as he's out living the dream in San Francisco on vacation today
17:02:22 <mvaldes> lucky him :)
17:02:29 <browne> too rainy to be living the dream today
17:02:31 <tmcpeak> yeah although the weather sucks in the bay today
17:02:34 <tmcpeak> browne: +1
17:02:35 <elmiko> nice, +1
17:02:41 <tmcpeak> living the dream would be Tahoe right now
17:02:58 <tmcpeak> allright
17:02:59 <michaelxin> hi, all
17:03:01 <tmcpeak> #topic Anchor
17:03:03 <tmcpeak> hey michael
17:03:08 <tmcpeak> tkelsey: want to take this?
17:03:09 <michaelxin> tmcpeak: hi
17:03:17 * elmiko waves at michaelxin
17:03:23 <michaelxin> elmiko: Thanks.
17:03:33 <michaelxin> I will need to leave early today, sorry.
17:03:56 <tmcpeak> cool, no worries
17:04:55 <tmcpeak> ok Tim and Doug aren't around
17:04:58 <tmcpeak> we can go back to anchor later
17:05:00 <tmcpeak> #topic Bandit
17:05:10 <tmcpeak> ok so we're still working away towards 1.0
17:05:17 <tmcpeak> in the process we're also closing some good bugs too
17:05:39 <browne> yeah, i think we can't publish a new release until we fix the integrations
17:05:44 <tmcpeak> anybody that's interested can pick up a bug or a blueprint targeted for 1.0 from our launchpad
17:05:47 <tmcpeak> browne: agreed
17:05:49 <elmiko> i have a question/suggestion about bandit
17:05:55 <ccneill> tmcpeak: any preferences?
17:05:57 <tmcpeak> elmiko: cool, what's up?
17:06:02 <tmcpeak> ccneill: nope, either would be awesome
17:06:12 <elmiko> have you guys considered, or is it available, to use bandit from another python app?
17:06:15 <elmiko> (eg is there an pi)
17:06:21 <elmiko> "api"
17:06:31 <tmcpeak> we don't have that currently
17:06:32 <browne> FYI, as far as integrations failing, they are keystone, keystonemiddleware, oslo.vmware, python-keystoneclient
17:06:39 <tmcpeak> what' use case do you have in mind elmiko?
17:06:46 <michaelxin> scan as service
17:06:57 <bknudson_> a REST API?
17:06:59 <elmiko> i was just thinking about cases where i could write an app that would use bandit to validate files
17:07:05 <elmiko> bknudson_: no, just a python api
17:07:12 <ccneill> ehhh we can get by without an API for a while, no? if we have good output formats
17:07:24 <bknudson_> popen
17:07:30 <michaelxin> What's the gain here?
17:07:31 <tmcpeak> lol
17:07:34 <tmcpeak> bknudson_: +1
17:07:39 <michaelxin> You an always run it locally
17:07:40 <elmiko> right.. i was thinking about avoiding subprocess
17:07:50 <tmcpeak> it's jank but that's what we've currently got ;)
17:07:58 <elmiko> yea, no worries. i was just curious
17:07:59 <bknudson_> that should be "popen #nosec"
17:07:59 <dg_> o/
17:08:05 <elmiko> bknudson_: LOL
17:08:05 <ccneill> elmiko: full disclosure, I'm working on a project (in python) to run other CLI tools :D
17:08:21 <tmcpeak> bknudson_: LOL!
17:08:32 <michaelxin> haha
17:08:36 <elmiko> ccneill: well, as long as we are going full disclosure, i wanted to run bandit in a distributed manner and collect results using a big data cluster
17:08:37 <tmcpeak> popen is fine as long as you always use a shell or something
17:08:52 <ccneill> elmiko: that sounds much more interesting than what I'm doing lol
17:08:55 <elmiko> this would be much easier if i could use it from an api as opposed to call popen
17:08:56 <michaelxin> elmiko: +1
17:09:00 <tmcpeak> elmiko: we've looked at doing something like that internally too
17:09:22 <michaelxin> we can build something and sell it
17:09:22 <tmcpeak> although a bunch of Python processes could probably do the same, yeah?
17:09:30 <michaelxin> it is better than what veracode is offering
17:09:46 <tmcpeak> yeah we should do a startup, I heard that's what the cool kids are doing
17:09:48 <ccneill> personally, since getting the golang bug, I always wonder now whether it's better to design something that's easy to parallelize in python, or just make it super granular (i.e. specify each file via CLI flags) and parallelize with go
17:09:59 <elmiko> tmcpeak: yes, i want to leverage the data harvesting potential of say spark to aggregate all the results
17:10:00 <bknudson_> curl http://openstack/bandit/scan?http://github/my_project
17:10:05 <ccneill> O:-) <- tech hipstar
17:10:17 <elmiko> it would be easy to do with a python api, slightly more difficult with subprocess
17:10:45 <tmcpeak> elmiko: let's chat offline, what you're doing sounds cool, I'm sure we can figure out some way to make it work in not too nasty of a way
17:10:46 <elmiko> ccneill: yea, good question
17:11:15 <elmiko> tmcpeak: yea, and don't get me wrong, i'm not asking for a big feature change. just thinking about some usages that fall outside the normal pattern.
17:11:25 <tmcpeak> cool, let's chat about it
17:11:26 <bknudson_> my opinion is all application CLI should just be a small wrapper over an API.
17:11:38 <elmiko> bknudson_: +1
17:11:45 <elmiko> would make these types of questions very easy
17:11:52 <tmcpeak> bknudson_: yeah that's definitely a better way, but it would be a huge lift at this point for us
17:12:04 <elmiko> and i'm sure i could just hack on the bandit package to make it work, but i thought i'd ask first ;)
17:12:18 <tkelsey> bah sorry im late chaps
17:12:21 <browne> its interesting, but defintely post 1.0 work
17:12:27 <elmiko> browne: agreed
17:12:30 <tmcpeak> yep yep
17:12:32 <elmiko> thanks for indulging me
17:12:43 <tmcpeak> thanks for bringing it up, it's a good idea
17:12:49 <tmcpeak> definitely a nicer design
17:13:00 <browne> for 1.0, we need to get agreement on the integration tox testenv name across the projects.  currently there are differences
17:13:20 <michaelxin> elmiko: good idea!
17:13:23 <tmcpeak> browne: should be 'bandit' right?
17:13:24 <browne> pep8, linters, bandit?
17:13:33 <tkelsey> i would like bandit
17:13:35 <browne> keystone doesn't have bandit
17:13:40 <tmcpeak> pep8 should call 'bandit'
17:13:50 <tmcpeak> browne: but yeah, you have a good point
17:14:04 <bknudson_> if you guys decide on bandit as the tox env then that's fine with me.
17:14:08 <tmcpeak> also how does the integration test work?
17:14:11 <browne> don't think we want to run pep8 or whatever other linter as part of this test either
17:14:14 <bknudson_> but right now keystone runs bandit with pep8
17:14:16 <tmcpeak> some aren't supposed to be passing, so are we going to block on that?
17:14:38 <tmcpeak> so for an intergration test to run a project should have a 'bandit' that we can call
17:14:43 <tmcpeak> if they don't we don't do integration checks
17:14:46 <elmiko> sahara uses bandit as the toxenv, but that's because we are still non-voting
17:14:56 <browne> they should all pass, otherwise it means our changes are breaking other projects.  this is the current situation
17:15:07 <tmcpeak> not in non-voting cases
17:15:08 <bknudson_> maybe there's another way to accomplish this
17:15:18 <browne> only non-voting is sahara
17:15:31 <tmcpeak> only voting is the Keystone stuff, right?
17:15:31 <bknudson_> maybe something in setup.py and then bandit does tox -e venv bandit <args>
17:15:34 <browne> https://review.openstack.org/#/c/281560/
17:15:54 <tmcpeak> bknudson_: sorry, who's setup.py? bandit's?
17:15:59 <tmcpeak> *whose
17:16:05 <bknudson_> keystone's setup.py
17:16:24 <bknudson_> because you don't know how keystone is running bandit (what the cmd line is)
17:16:43 <tmcpeak> bknudson_: that's why I was thinking we'd just call a standard name tox target
17:17:08 <elmiko> browne: i'm trying to get it non-voting. but i think it's a case we need to acknowledge
17:17:23 <tmcpeak> so we have a hierarchy 'bandit' tox target calls just Bandit, then 'pep8' or 'linters' calls that stuff + what's in bandit
17:17:24 <bknudson_> the tox.ini seems a little heavy-weight... but let's not get hung up on this.
17:17:35 <tmcpeak> bknudson_: cool, you know this stuff better
17:17:35 <browne> elmiko: no problem.  sahara integration did find a serious blacklist bug
17:17:38 <tmcpeak> what's your suggestion?
17:17:59 <elmiko> browne: which one?
17:18:00 <bknudson_> let's go with a bandit env in tox.ini for now
17:18:08 <tkelsey> browne: I have a fix for that bug FYI
17:18:22 <browne> tkelsey: saw that! awesome
17:18:25 <tmcpeak> bknudson_: cool, sounds good
17:18:26 <bknudson_> what's the problem with running pep8?
17:18:43 <tmcpeak> if there's a better way I'm happy to work towards that too, I'm just not super familiar with these things
17:18:51 <tmcpeak> sigmavirus24: is our resident tox expert I think
17:18:55 <bknudson_> ok, never mind, I guess I get it.
17:19:01 <sigmavirus24> o/
17:19:02 <browne> bknudson: running pep8 also works, although we're running more than necessary
17:19:21 <tmcpeak> and we're gating Bandit on non-bandit things
17:19:38 <bknudson_> let's go with bandit venv and then let's consider how this can be improved.
17:19:42 <sigmavirus24> oh right, that integration testing probably needs updates since the change from bandit to linters
17:19:47 <tmcpeak> bknudson_: +1
17:20:03 <sigmavirus24> I wonder if we can make the argument for having separate tox envs for different linters and having linters just combine all of them
17:20:05 <browne> sigmavirus24: it went from bandit to linters to pep8
17:20:15 <sigmavirus24> browne: we're back to pep8 from linters?
17:20:17 <sigmavirus24> lol okay
17:20:22 <browne> and several projects are inconsistent now
17:20:31 <sigmavirus24> Makes sense that they would be
17:20:35 <sigmavirus24> It's hard to keep track of these changes
17:21:59 <bknudson_> expect the keystone proposals to be +2d
17:22:02 <tmcpeak> yeah, eventually 'linters' may be used but for now the voting gate should be 'pep8'
17:22:20 <tmcpeak> per discussion with infra
17:22:36 <browne> tmcpeak: ha, i thought it was the other way around
17:23:01 <tmcpeak> no :(
17:23:06 <tmcpeak> changed again last week-ish
17:23:11 <browne> geez
17:23:41 <tmcpeak> I get it, infra is trying to maintain a consistent contract and so they'd either have to move all projects to 'linters' or keep all projects on pep8
17:23:55 <tmcpeak> and moving all projects to linters is more effort than anybody has time for right now
17:24:00 <elmiko> is this maybe a topic we should bring up at the cross project meeting?
17:24:10 <elmiko> or even make a cp spec for?
17:24:17 <tmcpeak> elmiko: those are both good ideas
17:24:34 <michaelxin> good idea
17:24:37 <browne> so for bandit integrations we agree on 'bandit'?
17:24:40 <tmcpeak> I had an initial conversation with #infra and what they said makes sense to me, although I'm not in love with having 'bandit' called as part of 'pep8'
17:24:48 <tmcpeak> browne: yeah, it seems so
17:24:55 <browne> ok cool
17:25:04 <tmcpeak> browne: thanks for taking it
17:25:09 <tmcpeak> allright, moving on from the Bandit show
17:25:12 <tmcpeak> #topic Anchor
17:25:15 <tmcpeak> dg_: tkelsey
17:25:16 <elmiko> i think we should propose this as cross project spec, then we can gather wider input on the tox env granularity
17:25:27 <tmcpeak> elmiko: I agree with that
17:25:31 <dg_> sup guys
17:25:33 <browne> elmiko: good point
17:25:37 <dg_> tkelsey anything to add on anchor
17:25:37 <elmiko> hey dg_
17:25:51 <tkelsey> not had much time to look into it recently
17:25:58 <dg_> +1
17:26:03 <browne> i think anchor needs reviews.  lots of patches in waiting
17:26:10 <tkelsey> I know Stan has done some new stuff around PKCS11 backends
17:26:17 <browne> like global requirements
17:26:21 <tkelsey> browne: +10
17:26:24 <dg_> browne ok ok
17:26:28 <dg_> will take a look
17:26:46 <tkelsey> I have been trying to keep ontop of it, but im only one core, so we need more reviews badly
17:27:13 <dg_> I've not been keeping on top of it, too busy with a couple of other things, will try and get caught up this week
17:27:26 <tkelsey> dg_: +1
17:27:55 <dg_> anything else on anchor?
17:28:02 <tkelsey> I guess thats it for anchor at the moment then
17:28:15 <tkelsey> then pkcs11 stuff is interesting though if people want to have a look :)
17:29:23 <tmcpeak> cool
17:29:26 <tmcpeak> #topic Syntribos
17:29:50 <mdong> right, I don’t have too much this week
17:30:06 <ccneill> soo I just found out in the OSQA meeting that my tempest-lib stuff is probably never going to merge.. so I guess I'll try to draw up a spec at some point of how we might integrate them into Syntribos
17:30:21 <mdong> we’re still making steady progress, there’s a few CR’s we could use some eyes on
17:30:30 <ccneill> don't know if that's something we want, but I'll do it anyway :P
17:30:58 <mdong> yeah, I think that stuff could integrate pretty well with Syntribos’ data generators
17:31:24 <mdong> michaelxin: do you have anything to say on syntribos?
17:32:06 <tmcpeak> yeah I've seen some patches flying around #openstack-security
17:32:35 <mdong> alright, in anycase we’ve still got plenty of blueprints on launchpad, and we would love to see some contributions!
17:33:01 <mdong> alright, that’s all Ive got for syntribos this week
17:33:03 <tmcpeak> cool
17:33:12 <tmcpeak> I'm skipping blog, I don't think we have much to say there
17:33:29 <tmcpeak> #topic OSSN
17:33:32 <tmcpeak> let's do a quick brush up
17:33:46 <elmiko> yea, i failed to get my blog post done :/
17:33:54 <tmcpeak> does look like we have a new one
17:35:15 <tmcpeak> https://bugs.launchpad.net/ossn/+bug/1545789
17:35:15 <openstack> Launchpad bug 1545789 in OpenStack Identity (keystone) "keystone ADMIN_TOKEN set by default can lead to default insecure deployment" [Medium,In progress] - Assigned to Adam Young (ayoung)
17:35:46 <elmiko> interesting, seems like an admin config issue
17:36:02 <elmiko> well, deployer
17:36:28 <browne> oh, but i think the keystoen documentation advises to disable admin token after bootstrapping
17:37:07 <elmiko> right
17:37:20 <elmiko> i mean, yea, don't leave your config file at default state
17:37:25 <tmcpeak> still since the impact is high we should probably do a note and refer to the keystone docs, yeah?
17:37:43 <browne> sure
17:37:52 <browne> doc for a doc
17:38:06 <elmiko> yup
17:38:11 <browne> definitely belongs in the security guide i think
17:38:17 <browne> if not already
17:38:27 <tmcpeak> yeah
17:38:39 <elmiko> +1
17:38:43 <tmcpeak> ok cool
17:39:20 <elmiko> we can probably just add an item here http://docs.openstack.org/security-guide/identity/checklist.html
17:39:35 <tmcpeak> yeah
17:39:36 <tmcpeak> sounds good
17:40:21 <elmiko> i can open a bug for the doc change
17:40:48 <tmcpeak> cool
17:40:51 <tmcpeak> speaking of...
17:40:58 <tmcpeak> #topic Sec Guide
17:41:26 <elmiko> sicarie around?
17:41:55 <sicarie> hello
17:42:37 <sicarie> Mostly moving on bugfixes now
17:42:43 <sicarie> there was one thing that popped up this morning
17:43:13 <sicarie> Around 3rd party applications and what could be construed as an endorsement
17:43:21 <sicarie> https://bugs.launchpad.net/openstack-manuals/+bug/1543249
17:43:21 <openstack> Launchpad bug 1543249 in openstack-manuals "Product endorsement in Passwords in Security Guide" [Low,Incomplete] - Assigned to Xing Chen (chen-xing)
17:43:40 <elmiko> i'm curious to see if anyone from the doc team chimes in
17:43:42 <sicarie> I voiced my opinion in the bug, I'd appreciate other points of view
17:43:57 <sicarie> There would need to be a MASSIVE effort to clean the sec guide
17:44:23 <elmiko> ok, i'll add a remark on the bug. i pretty much agree with you sicarie, but didn't say anything
17:44:25 <sicarie> It's one thing I try to never do is write in a bias towards my own company (or let others sneak theirs in)
17:44:33 <tmcpeak> umm
17:44:44 <tmcpeak> so just take out the specific references to certain password managers?
17:44:57 <sicarie> Well, if we're doing it here, we should be consistent
17:45:09 <sicarie> SO I see this as an "everywhere" precedence setter
17:45:18 <elmiko> yea, but we are advising F/OSS tools, so no real bias there
17:45:22 <sicarie> +1
17:45:30 <sicarie> That's my rule of thumb
17:45:43 <tmcpeak> yeah
17:45:50 <tmcpeak> I'd go ahead and punt that if it was me
17:45:55 <tmcpeak> that's just a good security recommendation
17:46:01 <tmcpeak> use a password manager, for example xyz
17:46:06 <elmiko> right
17:46:09 <sicarie> Well if the Docs team has a standard, then it's pretty cut and dry
17:46:11 <elmiko> we added a link to keepassx
17:46:16 <elmiko> agreed
17:46:24 <tmcpeak> ok cool
17:46:28 <tmcpeak> anything else for the guide?
17:46:30 <sicarie> Nope
17:46:32 <sicarie> Oh
17:46:34 <sicarie> actually
17:46:36 <ning> let's fix this first
17:46:41 <elmiko> sicarie, i've been going to some of doc team meetings. maybe we should bring this up to them?
17:46:49 <sicarie> +1
17:46:52 <elmiko> k
17:47:08 <sicarie> elmiko: they're scheduled just right ot be either before i wake up or during my commute :(
17:47:19 <sicarie> Additionally, I'm probably going to pull the link for the Lulu book
17:47:32 <elmiko> sicarie: yea, it's either way too early or too late lol
17:47:33 <tmcpeak> ning: fix what?
17:47:35 <sicarie> There's no easy way to build a pdf the way the RST guides are structured
17:47:41 <elmiko> ouch...
17:47:50 <elmiko> dave-mccowan was just asking about the pdf yesterday
17:47:57 <sicarie> So until there is we can't build it to be able to push to lulu
17:48:06 <ning> fix this reference documentation
17:49:02 <elmiko> ning: are you saying we need to remove the reference, or figure out what the standard is?
17:49:39 <ning> yes, remove the reference from sec doc
17:49:42 <sicarie> ning: please comment in the bug - we welcome all points of view, even if it's against something already posted - I'd be very interested in the other side of that discussion
17:49:51 <tmcpeak> sicarie: +1
17:49:53 <elmiko> sicarie: +1
17:50:00 <ning> sure
17:50:03 <sicarie> Thanks!
17:50:08 <tmcpeak> ok I'm going to skip to ccneill's topic
17:50:11 <tmcpeak> then we can AOB at the end
17:50:13 <tmcpeak> #topic CORS
17:50:17 <tmcpeak> ccneill: what's up with this?
17:51:28 <tmcpeak> selectively break SOP sounds sketchy
17:51:33 <tmcpeak> guess I should read the full details
17:51:37 <tmcpeak> ccneill: what's your take?
17:52:40 <elmiko> um, CORS is good mmmk
17:52:48 <elmiko> =D
17:53:05 <rickflare> howdie
17:53:08 <elmiko> but COORS is bad... /me snickers
17:53:35 <tmcpeak> ahh ok
17:53:38 <elmiko> rickflare: still having the OSSP meeting. sahara is up in a few minutes ;)
17:53:51 <tmcpeak> I guess I should spend some time reading it
17:53:56 <singlethink> servers have to opt-in for CORS to allow anything that isn't already allowed under SOP
17:54:16 <elmiko> i'm not cure what ccneill wanted to talk about, but krotscheck_dr  has been adding paste deploy patches to many projects to improve our coverage
17:54:24 <elmiko> s/cure/sure/
17:55:16 <singlethink> Is the concern that projects will be enabling CORS blindly, without verifying origins?
17:55:20 <elmiko> singlethink: was there something else we needed to discuss here, i thought the patches for CORS were already underway for awhile now?
17:55:37 <singlethink> I'm sorry... I think I'm missing the context
17:55:42 <singlethink> (of previous meetings)
17:55:45 <elmiko> not sure, ccneill brought this up
17:55:59 <elmiko> tmcpeak: maybe table this topic for the next meeting?
17:56:05 <tmcpeak> yeah I should read this carefully before I have an opinion
17:56:07 <tmcpeak> we'll cover it next time
17:56:09 <tmcpeak> #topic AOB
17:56:11 <tmcpeak> open floor
17:57:01 <elmiko> i'm just not sure what ccneill wanted to discuss, we have been adding improved support for CORS, but it gets highly specific about what is talking to the servers, and how to implement the origin exceptions, etc...
17:57:57 <tmcpeak> yeah, let's give people time to read and we can have a proper discussion
17:58:00 <tmcpeak> I'm sure Rob will want to play too
17:58:05 <elmiko> +1
17:58:14 <tmcpeak> allright well I'm going to close it!
17:58:16 <tmcpeak> #endmeeting