17:00:40 <hyakuhei> #startmeeting Security
17:00:46 <openstack> Meeting started Thu Jul  2 17:00:40 2015 UTC and is due to finish in 60 minutes.  The chair is hyakuhei. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:47 <tkelsey> o/
17:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:49 <openstack> The meeting name has been set to 'security'
17:00:50 <tmcpeak> o/
17:00:53 <browne> hi
17:00:55 <jian5397> hello
17:00:57 <tmcpeak> yo yo
17:01:03 <hyakuhei> Hey !
17:01:05 <timkennedy> o/
17:01:06 <Daviey> \o
17:01:07 <michaelxin> hi
17:01:12 <gmurphy> o/
17:01:24 <elmiko> yo/
17:01:32 <hyakuhei> Quiet room today...
17:01:51 <nkinder> hi all
17:01:52 <deepika> Hi this is Deepika a new member
17:02:00 <nkinder> deepika: welcome!
17:02:01 <tmcpeak> hi Deepika, welcome
17:02:06 <hyakuhei> Hi deepika :)
17:02:06 <browne> welcome
17:02:07 <tkelsey> hello deepika and welcome :)
17:02:10 <timkennedy> hi Deepika
17:02:15 <michaelxin> hi Deepika
17:02:16 <deepika> I met a few of you in Vancouver meeting
17:02:19 <deepika> Thanks all
17:02:38 <dave-mccowan> o/
17:02:46 <hyakuhei> nkinder: Great to see you :)
17:02:48 <deepika> I am new to open stack but not security.
17:02:57 <elmiko> hi deepika
17:03:04 <tmcpeak> deepika - want to give a brief intro?
17:03:14 <Daviey> Hi deepika o/
17:03:28 <deepika> sure. So I am from Cisco and new in their Open stack group
17:03:35 <nkinder> hyakuhei: sorry I missed last week.  I was at the Red Hat Summit.
17:03:47 <michaelxin> please welcome mvaldes too.
17:03:47 <tmcpeak> cool!
17:03:50 <hyakuhei> No problem, glad you're here
17:03:51 <deepika> but have been in Cisco for about 9 years and have been part of their security group
17:03:59 <michaelxin> he is a coworker with me in Rackspace security engineering.
17:04:01 <hyakuhei> Hey michaelxin, welcome mvaldes!
17:04:08 <tmcpeak> hi mvaldes
17:04:09 <nkinder> deepika: do you work with dave-mccowan?
17:04:09 <elmiko> hi mvaldes
17:04:15 <tkelsey> welcome mvaldes :)
17:04:15 <mvaldes> Hi all!
17:04:17 <deepika> Yes I will work with him
17:04:22 <nkinder> Cool.
17:04:25 <elmiko> deepika: thanks for the intro =)
17:04:28 <dave-mccowan> hi deepika :-)
17:04:29 <michaelxin> Thanks all
17:04:32 <nkinder> welcome mvaldes
17:04:37 <timkennedy> welcome, mvaldes
17:04:49 <tkelsey> new members, exciting times :)
17:04:57 <deepika> yes for sure
17:04:59 <hyakuhei> Agenda: MidCycle, Crypto, Bandit, $stuff
17:05:01 <mvaldes> thanks for the warm welcome
17:05:19 <michaelxin> hyakuhei: please add API security testing
17:05:25 <hyakuhei> and OSSNs :)
17:05:31 <nkinder> There's an OSSN topic we shoudl discuss as well
17:05:37 <hyakuhei> ^^ :)
17:05:37 <nkinder> hyakuhei: you beat me to it :)
17:05:42 <hyakuhei> Lets roll on then.
17:05:43 <elmiko> nkinder: +1
17:05:48 <hyakuhei> #topic midcycle
17:05:59 <hyakuhei> Reminder for everyone: #link https://etherpad.openstack.org/p/security-liberty-midcycle
17:06:11 <tmcpeak> looking forward to it!
17:06:13 <hyakuhei> Location is seattle and the winning date is 1st September.
17:06:36 <deepika> for this mid cycle meeting
17:06:48 <deepika> can we join remtely
17:06:54 <deepika> remotely
17:07:02 <tmcpeak> deepika: it's very difficult to get value from that, I think it's been tried before
17:07:02 <hyakuhei> In theory yes, in practice it can be hard depending on what's happening
17:07:16 <hyakuhei> They tend to be mini-sprints so it can work, especially when doing things like reviewing changes.
17:07:18 <nkinder> I *think* I can make that week
17:07:31 <hyakuhei> nkinder: You'd better (Shakes fist) :P
17:07:34 <deepika> I see
17:07:38 <tmcpeak> :P
17:07:38 <michaelxin> it should work for me but need to check with boss first.
17:07:41 <elmiko> i'm hoping to attend, still addressing travel issues though
17:07:44 <hyakuhei> nkinder: Expecting you to bring the beer
17:08:06 <nkinder> hyakuhei: I'm supposed to be in Bangkok around then for work, but it's the following week as of now (tentative)
17:08:17 <hyakuhei> Anyway, please take a look at the etherpad and take a look at the topics too, bullet points are fine for now but we'll flesh that out significantly later
17:08:31 <michaelxin> so no need to worry about backup location anymore?
17:08:31 <hyakuhei> cool
17:08:50 <hyakuhei> HP are happy to host it
17:09:07 <michaelxin> +1
17:09:13 <mvaldes> i can stay home and cover for michaelxin while he is there
17:09:30 <hyakuhei> Sounds good
17:10:18 <hyakuhei> ok, lets chat Crypto for a minute
17:10:27 <hyakuhei> #topic Crypto stuff
17:10:35 <Daviey> Lets write our own?
17:10:40 <hyakuhei> OpenStack in general has crypto stuff going all over the place
17:10:43 <tmcpeak> Daviey: +1!
17:10:49 <tkelsey> Daviey: what could go wrong :)
17:10:51 <tmcpeak> only if it's a brand new algo
17:10:55 <michaelxin> haha
17:10:58 <dg_> +1
17:10:59 <nkinder> well, Amazon is doing that right now...
17:11:06 <hyakuhei> At the last summit I proposed that the Security project start tracking this more formally
17:11:07 <tkelsey> s2n?
17:11:10 <nkinder> yah
17:11:16 <hyakuhei> I can imagine maintaining a crypto-status page
17:11:27 <tkelsey> hyakuhei: +1 sounds like a good idea
17:11:27 <michaelxin> hyakuhei: +1
17:11:38 <michaelxin> It is a great start
17:11:38 <tmcpeak> +1
17:11:43 <Daviey> (nkinder, they are still using crypto primitives from libcrypto (openssl))
17:11:53 <hyakuhei> should help us to connect some dots and provide outsiders with a better view of where OpenStack is at regarding what I've come to refer to as OpenStack-Native encryption features
17:11:54 <michaelxin> so we can know what the devs are doing
17:11:57 <browne> i think that would be good.  also should try to get rid of old ssl libs
17:12:04 <nkinder> Daviey: yes, just doing the TLS part themselves
17:12:07 <browne> and use python cryptography where possible
17:12:14 <hyakuhei> Yes, in the first phase it will be bringing that info together
17:12:16 <elmiko> hyakuhei: are we talking about tracking which projects are using what crypto packages?
17:12:29 <hyakuhei> In the second phase we can introduce more formal review, audit and advice.
17:12:34 <tmcpeak> I think last time we talked about this we decided Bandit could help drive this
17:12:38 <hyakuhei> elmiko: More high level to start with
17:12:45 <michaelxin> hyakuhei: +1
17:12:45 <elmiko> ok, cool
17:12:49 <tkelsey> tmcpeak: yes i think there is good scope for bandit here
17:12:52 <timkennedy> intent to centralize info, then make a coordinated push for cross-project best practices?
17:12:56 <hyakuhei> More tracking and influencing the _features_ rather than the implementation
17:12:58 <Daviey> hyakuhei: Are you talking about tracking which crypto libraries are used or which cipher suites etc?
17:13:02 <hyakuhei> timkennedy: yes
17:13:15 <nkinder> Daviey: both I think
17:13:16 <timkennedy> great.  +1
17:13:19 <michaelxin> we can do both
17:13:24 <browne> Daviey: i'd say both
17:13:32 <hyakuhei> Yeah
17:13:41 <hyakuhei> So Bandit can do a lot of implementation checking
17:13:54 <michaelxin> hyakuhei: +1
17:14:15 <browne> there's also a lot of use of exec of openssl command line which i don't like
17:14:25 <nkinder> bandit will help a lot.  When I started doing this for keystone a few releases back, it was tedious and manual
17:14:28 <tkelsey> browne: thats interesting
17:14:28 <hyakuhei> though it doesn't know where you should use CTR vs XTS etc
17:14:51 <hyakuhei> At a higher level though, tracking features and helping deliver better crypto is good
17:14:52 <nkinder> even if bandit points out where in the code manual research is needed, it will be useful
17:15:04 <tkelsey> nkinder: +1
17:15:07 <michaelxin> nkinder: +1
17:15:17 <mvaldes> this is a worthy effort.
17:15:24 <browne> agreed
17:15:26 <tmcpeak> +1
17:15:28 <tkelsey> yup
17:15:46 <hyakuhei> so I guess the wiki is the best place to create and to attempt to maintain some sort of high level overview. It should provide points to start drill-downs. Auditing / Bandit scanning will follow. I'll also try to reboot some of the TA work just around crypto
17:15:48 <Daviey> Hmm, I am guessing that many projects are using distro defaults for some things - rather than implemented in code we control?  Ie, we don't decalare that we want to use SSLv3 or RC4 on any endpoints.. Considering many endpoints are going behind a real webserver this cycle, that leaves us in a pickle... no?
17:16:01 <hyakuhei> As the projects are just too big for the current TA efforts to take off without dedicated headcount.
17:16:04 <tkelsey> hyakuhei: +1
17:16:26 <tmcpeak> I'll pitch in with any Bandit tweaks to support this
17:16:48 <nkinder> Daviey: soem stuff is clearly otu of scope.  There is advice for how to deploy (for deployers), but that's separate from advice for how to use crypto for developers
17:16:49 <tkelsey> Daviey: humm yes, but there is still plenty of stuff we can cover
17:16:49 <michaelxin> hyakuhei: +1
17:16:52 <hyakuhei> Daviey: Not really, almost all crypto parameters are application configured. Sure if you want to configure Apache as a front end and use crappy crypto I can't stop you
17:17:02 <hyakuhei> but I can damned sure make sure requests is doing cert validation etc.
17:17:13 <nkinder> both are important, but I think we're talking about the latter here
17:17:17 <hyakuhei> The goal isn't to make it perfect, the goals to make it the least weak part of the system.
17:17:26 <Daviey> ok, makes sense.
17:17:28 <michaelxin> it is more about application
17:17:39 <michaelxin> server configuration is depending on the users
17:17:40 <timkennedy> as they say, "Knowing is half the battle."
17:17:42 <tkelsey> also, having more docs out there will help educate people when setting up there apache or whatever as well
17:17:43 <browne> bandit does check for requests use of cert validation
17:17:56 <nkinder> tkelsey: yep, that's security guide territory
17:18:01 <timkennedy> even just having awareness of what is being done, and where, even if we can't change it in the short term, is invaluable.
17:18:02 <elmiko> tkelsey: +1
17:18:17 <hyakuhei> So yes, keep an eye out on -dev for emails regarding this. I'll also be including keymanagement, namely but not entirely, Bandit and Castellan
17:18:18 <michaelxin> timkennedy: +1
17:18:42 <hyakuhei> I'll do my best to bootstrap that then hopefully we can get help from some more people
17:18:49 <hyakuhei> Anything else on this?
17:19:04 <Daviey> hyakuhei: How will the weak points be tracked?
17:19:07 <Daviey> wiki or bugs?
17:19:12 <hyakuhei> Bugs
17:19:15 <Daviey> ok
17:19:46 <hyakuhei> As little on wiki as possible. Wiki will be more about telling potential adopters where the overall state of crypto _features_ is in OpenStack today and where it's headed
17:19:49 <mvaldes> hyakuhei: which -dev list?
17:19:49 <michaelxin> hyakuhei: is there a -dev list for this?
17:19:54 <hyakuhei> Top-down as it were
17:20:11 <hyakuhei> All Security Project work should be conducted on openstack-dev using the [Security] tag
17:20:18 <hyakuhei> ^ please :)
17:20:24 <nkinder> hyakuhei: +1
17:20:29 <browne> also, i've heard from some cores that they want general advertising of Bandit on the mailing list anyway.
17:20:33 <michaelxin> hyakuhei: Thanks.
17:20:41 <hyakuhei> Good.
17:20:43 <tkelsey> browne: nice
17:21:07 <hyakuhei> tmcpeak: chair6: tkelsey etc - you hear that? Have your bandit chats over on -dev !
17:21:25 <tkelsey> lol ok ok :)
17:21:26 <tmcpeak> haha ok cool :)
17:21:33 <hyakuhei> Speaking of...
17:21:36 <hyakuhei> #topic Bandit
17:21:39 <tkelsey> https://review.openstack.org/#/c/197180/
17:21:46 <tmcpeak> tkelsey, browne, bknudson: can you guys take this?
17:21:51 <tkelsey> new check for partial executable paths when running subprocesses
17:21:52 <tmcpeak> it deserves full attention, sadly I'm in another meeting
17:21:58 <tmcpeak> bknudson has great news :)
17:22:31 <tmcpeak> oh, lol, good times, he's not here today :\
17:22:40 <tmcpeak> Keystone went to a voting Bandit gate :D
17:22:47 <tmcpeak> first project!
17:22:49 <browne> tmcpeak: sure
17:22:53 <tkelsey> thats a shame, but yeah awesome :)
17:22:56 <browne> yay
17:23:05 <nkinder> awesome!
17:23:06 <michaelxin> great
17:23:08 <tkelsey> first one to take the plunge, we own him a beer
17:23:29 <Daviey> Oh dammit.. I currently depend on not using full path for binaries.. I can manipulate PATH before executioI guess i'll have to stop be slack.
17:23:47 <hyakuhei> Glad it was one of those small side projects that no-one uses....
17:23:55 <tmcpeak> :P
17:24:09 <hyakuhei> That's excellent work though, congrats
17:24:32 <tmcpeak> :) bknudson is hustling!
17:24:44 <hyakuhei> Any more on Bandit?
17:24:52 <tmcpeak> also there's some work going on for some gate, I want to say swift?
17:25:09 <tmcpeak> at some point we should take inventory and see how many projects are/aren't using Bandit
17:25:14 <tkelsey> yes I think I did hear about that
17:25:17 <tkelsey> tmcpeak: +1
17:25:18 <chair6> tmcpeak rolled a new release on pypi earlier this week..
17:25:20 <michaelxin> tmcpeak: +1
17:25:20 <elmiko> sahara has non-voting bandit gate
17:25:31 <notmyname> https://review.openstack.org/#/c/196395/
17:25:33 <tmcpeak> oh yeah, lol, was that this week? :)
17:25:34 <browne> nova, cinder are in the works.  i have patches for them.  oslo.vmware already uses bandit (non-voting)
17:25:37 <tkelsey> we should get a discussion going on -dev
17:25:39 <tmcpeak> 0.12.0 is live :)
17:25:45 <tkelsey> see who is using it and drum up some exposure
17:25:59 <tkelsey> thanks notmyname :)
17:26:07 <elmiko> tkelsey: +1  for ml discussion
17:26:36 <hyakuhei> This is excellent work guys, really useful for projects and raises the visibility of the Security Project overall.
17:26:37 <mvaldes> this progress is exciting
17:26:44 <tkelsey> :)
17:27:06 <dave-mccowan> we're still running 0.10.0 on barbican gate.  should i manually bump the version to 0.12.0, or will infra proposed updates be coming soon?
17:27:33 <tkelsey> tmcpeak: ?
17:27:39 <browne> dave-mccowan: global requirements has 0.10.1
17:27:42 <tmcpeak> dave-mccowan: yeah, for sure
17:27:48 <tmcpeak> I think 0.10.0 is pretty broken :)
17:27:50 <Daviey> libvirt uses iptables and qemu-* from PATH, and that was added as a _feature_ about 3 years ago.
17:27:52 <browne> you can set your test-requirements to match for openstack bot
17:27:57 <tmcpeak> new versions don't break things (at least in theory)
17:28:06 <tkelsey> tmcpeak: are you going to patch infra?
17:28:14 <tkelsey> I can otherwaise
17:28:21 <tkelsey> *other waise
17:28:23 <tmcpeak> no, we have >= 0.10.1, patching isn't required
17:28:31 <tkelsey> ah ok
17:29:39 <tmcpeak> https://github.com/openstack/requirements/blob/master/global-requirements.txt#L225
17:29:54 <Daviey> As more projects start to use Bandit, how are we measuring what bandit modules each openstack project has enabled?
17:30:10 <tmcpeak> Daviey: great question, we aren't but it would be nice to
17:30:30 <dave-mccowan> tmcpeak does this mean test-requirements-bandit.txt is no longer needed?
17:30:32 <tmcpeak> I'd at least to have an updated list of projects, their usage status, and a link to their profiles
17:30:34 <hyakuhei> Yeah, it'd be interesting to monitor that.
17:30:53 <tmcpeak> dae-mccowan: some projects use that to make it so you can run Bandit without installing all test requirements
17:31:05 <browne> dave-mccowan: yes, better to remove from -bandit.txt and just put in test-requirements.txt.  openstack bot can't deal with -bandit.txt
17:31:26 <tmcpeak> but it doesn't need to if you're >=, right?
17:32:02 <tkelsey> I always think of the -bandit.txt as a little messy
17:32:09 <tkelsey> but thats just me
17:32:28 <tmcpeak> it can be useful to cut down Bandit tox time, but I'm ambivalent
17:32:53 <Daviey> -bandit.txt is nasty, in that it is further pollution of the project root.. But i do think it is crazy to run what is basically a linting tool, having to install all of test-requirements.txt
17:33:07 <tmcpeak> yeah :\ no great answers either way
17:33:14 <michaelxin> Daviey: +1
17:33:20 <tkelsey> we can suggest both in the instructions and people can pick whatever seems right to them i guess
17:33:29 <michaelxin> tkelsey: good idea
17:33:37 <browne> Daviey: yeah if there's a better way we're open to it
17:33:39 <tmcpeak> honestly, we only have three requirements, couldn't we just list them in tox.ini instead of putting them in a file?
17:34:10 <tkelsey> well the openstack way is to use the file, I would follow convention
17:34:12 <hyakuhei> ok, maybe we should move on from bandit for a few minutes, we can come back if there's time
17:34:17 <hyakuhei> or use -dev
17:34:24 <tkelsey> hyakuhei: yeah sorry :) lets move on
17:34:30 <browne> the advantage of putting in test-requirements.txt is that the openstack proposal bot will operate on it so if the global requirements.txt is every bumped to a newer version
17:34:39 <hyakuhei> tkelsey: Is there much to discuss re: Anchor?
17:34:51 <hyakuhei> #topic Anchor
17:35:00 <tkelsey> well we have a new API setup in the works
17:35:11 <tkelsey> https://review.openstack.org/#/c/190473/
17:35:23 <tkelsey> ^^ is the change for people who are interested
17:35:42 <tkelsey> and we are/close to Py3 compatibility now
17:35:45 <hyakuhei> So there are some pretty big changes in flight for Anchor, some discussion of how you could do multi-root signing, this lets you have nice compartmentalized crypto with a single CA endpoint at the cost of slightly more complexity in Anchor itself.
17:35:47 <hyakuhei> Yay for Py3!
17:36:11 <hyakuhei> Anything else on Anchor today?
17:36:16 <tkelsey> thats all I got
17:37:02 <hyakuhei> Oh I forgot to mention. Andreas saw that we were still using Stackforge for stuff and put in a request to move Bandit and Anchor over to the openstack namespace
17:37:12 <hyakuhei> #topic OSSN
17:37:13 <tkelsey> :D nice!
17:37:17 <hyakuhei> nkinder: you around ?
17:37:17 <browne> nice
17:37:22 <nkinder> yep
17:37:32 <nkinder> OSSN-0049 has brought some interesting discussions
17:37:34 <nkinder> https://review.openstack.org/#/c/194416/
17:37:35 <hyakuhei> I see there's quite a few OSSN in the queue
17:37:44 <hyakuhei> yeah, especially re: the patch
17:38:01 <elmiko> and most recently, should this be general advice for all debug mode services
17:38:01 <nkinder> This was specific to Ironic and the use of debug=true leaking sensitive config values
17:38:23 <hyakuhei> Yeah, we've had other project specific ones in the past
17:38:24 <nkinder> Yes, I can see writing this one over and over and over for different services
17:38:34 <michaelxin> should debug mode be disabled for any production environment?
17:38:37 <hyakuhei> well, most services tag things correctly in oslo now
17:38:45 <hyakuhei> michaelxin: it _should_ but it tends to break when you do that
17:38:46 <nkinder> The value of specific cases is we can say "here is a known violator", then say when it was fixed
17:38:49 <elmiko> if there are no objections, i'll just rewrite it to be more general for all debug=true
17:38:57 <Daviey> We see leakage like this every year.. I was thinking about seeing if a Tempest test could automate the search for creds leaked in logs.
17:38:59 <tkelsey> nkinder: +1
17:39:12 <hyakuhei> nkinder: I agree
17:39:15 <elmiko> hmm, ok
17:39:19 <tkelsey> Daviey: nice idea
17:39:22 <nkinder> If we have a single generic OSSN, how are we goign to communicate when someone makes an "oops" and doesn't mark somethign as secret?
17:39:23 <hyakuhei> and have no problem with two OSSNs looking very similar
17:39:24 <michaelxin> hyakuhei: ic
17:39:25 <elmiko> nkinder: that is a good point
17:39:45 <nkinder> Daviey: we did something like that for keystone a while back
17:39:49 <hyakuhei> Daviey: there was a discussion of doing some staining tests with Tempest
17:40:10 <Daviey> hyakuhei: Have a thread handy? I thought it was an original idea :)
17:40:38 <hyakuhei> Verbal
17:40:52 <nkinder> so back to OSSSN-0049, what is the consensus?
17:40:55 <elmiko> so, what about #link https://bugs.launchpad.net/python-swiftclient/+bug/1470740
17:40:55 <openstack> Launchpad bug 1470740 in python-swiftclient "swiftclient disclose token in debug logs" [Undecided,New]
17:40:55 <hyakuhei> Never had the time to put much into it though I think it may have been discussed on-thread at some point
17:40:57 <elmiko> as it pertains to 0049
17:41:08 <hyakuhei> but staining != new, tempest != new :P
17:41:14 <nkinder> While I like the idea (and intent) of a generic article, I think we lose the value of calling out specific fixes
17:41:27 <michaelxin> staining+tempest=new
17:41:28 <elmiko> nkinder: that makes sense
17:41:29 <hyakuhei> Speaking of. michaelxin wants to talk about similar stuff in a minute
17:41:33 <tmcpeak> my only concern is that it might becoe stale in light of fixes and new issues
17:41:34 <tkelsey> nkinder: I agree on balance
17:42:04 <nkinder> so let's leave it specific to Ironic, but word as much as possible in a generic way so we can plagiarize OSSN-0049 next time this comes up? :)
17:42:09 <hyakuhei> Jeeze my IRC is way behind, I just got like 10 messages in one lump.
17:42:20 <tmcpeak> haha
17:42:21 <hyakuhei> nkinder: +1 for plagiarism.
17:42:22 <tmcpeak> poor elmiko
17:42:25 <elmiko> lol
17:42:33 <Daviey> We need a notion of Common Weaknesses :/
17:42:36 <hyakuhei> elmiko fwiw it's a very good OSSN.
17:42:39 <nkinder> elmiko: don't worry, we'll tell you something different tomorrow! ;)
17:42:44 <elmiko> nkinder: so, should i hack it again, or just remove WIP?
17:42:49 <elmiko> LOL
17:42:50 <nkinder> +1 on it being very good!
17:43:02 <elmiko> hyakuhei, nkinder, thanks
17:43:03 <tmcpeak> tomorrow for a new direction sounds above industry average :P
17:43:09 <nkinder> I think your last revision is good enough IMHO
17:43:12 <elmiko> k
17:43:16 <michaelxin> +1
17:43:32 <nkinder> and as hyakuhei points out, we have a backlog of OSSNs that need authors
17:43:52 <elmiko> ok, removed wip, just need a few more reviews
17:43:56 <tkelsey> I'll try and find some spare cycles to pick one up
17:44:06 <nkinder> https://bugs.launchpad.net/ossn/
17:44:07 <tmcpeak> nkinder: I'll pick one up
17:44:10 <elmiko> nkinder: i'll pick up another, but i'm only working on one at a time!
17:44:20 <hyakuhei> OSSNs are a great way of getting involved in Security projects, and getting an ATC badge :)
17:44:23 <tkelsey> elmiko: very wise :)
17:44:27 <elmiko> ;)
17:44:28 <nkinder> I've been travelling for conferences, and moving houses, but am ready to pick some up myself too
17:44:30 <hyakuhei> Any new members ^^^
17:44:53 <mvaldes> i'm interested in helping, but not sure how this works
17:44:56 <nkinder> We have the process pretty well documented for any newbs :)
17:45:07 <michaelxin> mvaldes: +1
17:45:10 <tmcpeak> I took this one: https://bugs.launchpad.net/ossn/+bug/1464750
17:45:10 <openstack> Launchpad bug 1464750 in OpenStack Security Notes "Service accounts can be used to login horizon" [Undecided,Incomplete]
17:45:17 <Daviey> https://wiki.openstack.org/wiki/Security/Security_Note_Process <-- how to
17:45:18 <michaelxin> nkinder: +1
17:45:24 <elmiko> mvaldes: it's very easy to get in on, the templates and wiki describe almost everything
17:45:24 <nkinder> elmiko: I think you're the most recent author.  Was the process well defined, or do we need to make things more helpful to the first time author?
17:45:31 <michaelxin> I will try to contribute too.
17:45:38 <tkelsey> awesome :)
17:45:38 <elmiko> i think the process is very well defined at this point
17:45:50 <elmiko> kudos to all who have worked on the templates and wiki instructions
17:45:52 <tmcpeak> well at least I'm attempting to assign it to me
17:45:56 <nkinder> ok, good.  If something isn't clear, I want to know about it :)
17:46:13 <michaelxin> nkinder: Thanks for your hard work
17:46:14 <hyakuhei> What happened with the parsing / revised format work?
17:46:18 <nkinder> ...and if anyone needs some hand-holding, just let me know
17:46:21 <elmiko> nkinder: i'll read them again with a different perspective and see if anything stands out for me
17:46:35 <tkelsey> nkinder: +1 and likewise I can help out
17:46:40 <nkinder> hyakuhei: writing them in yaml actualyl makes things harder
17:46:57 <nkinder> ...though converting and parsing for tools to check if an OSSN applies to their cloud is very possible
17:47:02 <nkinder> and I have a WIP for that
17:47:03 <hyakuhei> It would be nice to be able to (in a simple stacklytics type way) identify all the OSSN for each OpenStack release/project
17:47:21 <nkinder> add this as a topic for next week, and I'll share what I have
17:47:23 <tkelsey> grep for keywords?
17:47:27 <hyakuhei> ----cool, sorry for delayed comments, I think this freenode machine is on the verge of a split
17:47:34 <hyakuhei> thanks nkinder
17:47:50 <hyakuhei> Ok next topic
17:47:56 <hyakuhei> #topic API Security Testing
17:47:58 <hyakuhei> michaelxin: ^^
17:48:00 <tmcpeak> is launchpad broken in some weird and wonderful way?
17:48:05 <tmcpeak> I can't assign myself an OSSN
17:48:08 <tmcpeak> :\
17:48:08 <hyakuhei> More than usual ?
17:48:11 <hyakuhei> Are you signed in?
17:48:12 <nkinder> tmcpeak: really?
17:48:17 <tmcpeak> lol, yeah
17:48:19 <nkinder> which one do you want?
17:48:21 <michaelxin> last time, we talked about gabbi
17:48:29 <nkinder> tmcpeak: or shoudl I pick ones to assign to you :P
17:48:31 <michaelxin> And whether it is possible to use it for the framework
17:48:32 <tmcpeak> https://bugs.launchpad.net/ossn/+bug/1464750
17:48:32 <openstack> Launchpad bug 1464750 in OpenStack Security Notes "Service accounts can be used to login horizon" [Undecided,Incomplete]
17:48:45 <tmcpeak> as long as it isn't that Neutron one :P
17:48:47 <elmiko> michaelxin: +1, i've been experimenting with gabbi on sahara
17:48:50 <hyakuhei> got a link for Gabbi?
17:48:56 <michaelxin> We did more digging around and talked this with some developers
17:49:13 <elmiko> #link https://github.com/cdent/gabbi
17:49:19 <tkelsey> ty
17:49:23 <michaelxin> So far, we do not think that it is a good framework for automatic api testing.
17:49:40 <michaelxin> it is good for sending predefined http request testing
17:50:08 <michaelxin> In order to do fuzzing, security testing, too much additional work.
17:50:25 <tkelsey> interesting, any other candidates to look at/try ?
17:50:48 <michaelxin> I just got a team to work on this. We code named Syntribos.
17:50:58 <nkinder> tmcpeak: you are now the proud owner of that OSSN bug
17:51:06 <tmcpeak> nkinder: awesome, thank you :)
17:51:12 <nkinder> tmcpeak: thank YOU
17:51:16 <elmiko> michaelxin: in general i agree, it's not a perfect fit for security testing
17:51:17 <tmcpeak> :P
17:51:25 <michaelxin> We will use some codes from a rackspace open source project OpenCafe
17:51:35 <michaelxin> The basic idea is same
17:51:41 <tkelsey> michaelxin: so will this be a new project?
17:51:49 <michaelxin> Yes
17:52:07 <michaelxin> This project aims to become a API automatic scanner
17:52:09 <hyakuhei> A community one ?
17:52:09 <tkelsey> stackforge ? presumably under the security team umbrella
17:52:26 <michaelxin> like API testing of Appscan
17:52:38 <michaelxin> but with better performance
17:52:47 <hyakuhei> Cool
17:52:51 <michaelxin> hyakuhei: Yes. That will be great.
17:53:01 <michaelxin> Hope you can help with kicking it off.
17:53:02 <hyakuhei> Superb, we can make that a thing
17:53:04 <tmcpeak> cool, so michaelxin will this be a OpenStack Security labeled project?
17:53:15 <tkelsey> michaelxin awesome :)
17:53:17 <michaelxin> tmcpeak: We are fine with it.
17:53:20 <tmcpeak> great!
17:53:24 <elmiko> very cool
17:53:27 <tkelsey> :)
17:53:34 <michaelxin> The basic idea is similar
17:53:44 <hyakuhei> Yeah I'd love to semi-formally partner with you guys on this, I'll get our pentesters to take a look too, they're too cool for the IRC meetings but I imagine they'll have good input for a project like this
17:53:45 <tkelsey> first new members, now new projects :)
17:53:46 <michaelxin> The user needs to provide valid HTTP requests.
17:53:55 <hyakuhei> Have you looked at malybuzz at all ?
17:54:12 <michaelxin> hyakuhei: no.
17:54:16 <michaelxin> will take a look for sure.
17:54:22 <hyakuhei> cool
17:54:36 <hyakuhei> I also wonder if you could do something with tempest test cases
17:54:42 <Daviey> Is it expected to be some sort of Periodic jenkins job?
17:54:54 <hyakuhei> i.e teams have already written tests telling Tempest how their API _should_ work
17:55:14 <hyakuhei> branching the various nodes in that model, creating loops etc could be very interesting.
17:55:22 <michaelxin> Tempest is a different issues.
17:55:26 <hyakuhei> Yeah
17:55:30 <hyakuhei> I'm not saying use it
17:55:38 <hyakuhei> but the test cases capture some useful knowledge
17:55:49 <michaelxin> For Tempest test cases, we assume that people know about the products.
17:55:52 <Daviey> I guessed that hyakuhei was suggesting temptest be input for fuzzing etc?
17:55:58 <hyakuhei> Sure
17:56:02 <michaelxin> They have the luxury to create all security testing cases
17:56:06 <hyakuhei> So blind fuzzing only gets you so far
17:56:17 <hyakuhei> Knowing some things about the system can help with the depth of the test
17:56:25 <michaelxin> But this project is give a tool for people to point and shoot
17:56:43 <hyakuhei> It's an interesting project, really looking forward to learning more
17:56:48 <Daviey> unbound fuzzing can run for years :)
17:56:49 <michaelxin> Since lots of open stack projects have lots of common grounds
17:57:07 <michaelxin> we might be able to make it perform better.
17:57:12 <hyakuhei> Completely blind fuzzing would never Auth, but yeah lets talk more next week or on -dev :)
17:57:18 <hyakuhei> #topic Any Other Business
17:57:24 <hyakuhei> 2 minutes left guys
17:57:36 <tmcpeak> good stuff!
17:57:42 <hyakuhei> michaelxin: Very excited about that but wanted to open up AOB in case there's anything urgent to discuss
17:57:58 <tkelsey> hyakuhei: michaelxin +1 \
17:58:01 <michaelxin> Thanks
17:58:03 <michaelxin> sure.
17:58:13 <michaelxin> what's AOB?
17:58:19 <tmcpeak> any other business :)
17:58:25 <michaelxin> sure
17:58:49 <hyakuhei> Ok, lets wrap then. Thanks everyone! Great meeting.
17:58:51 <hyakuhei> #endmeeting