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