16:59:39 <tmcpeak> #startmeeting security
16:59:39 <openstack> Meeting started Thu Aug 11 16:59:39 2016 UTC and is due to finish in 60 minutes.  The chair is tmcpeak. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:59:43 <lhinds> hi tmcpeak !
16:59:43 <openstack> The meeting name has been set to 'security'
16:59:45 <tmcpeak> #chair hyakuhei
16:59:46 <openstack> Current chairs: hyakuhei tmcpeak
16:59:58 <lhinds> hi *
17:00:01 <hyakuhei> sup y'all
17:00:02 <tmcpeak> hai!
17:00:03 <mdong> o/
17:00:24 <elmiko> hi
17:00:52 <singlethink> howdy
17:00:56 <tmcpeak> heads up, I'll likely have to split soon
17:00:58 <tmcpeak> boarding a plane
17:01:26 <hyakuhei> fancy!
17:01:36 <elmiko> ++
17:01:46 <tmcpeak> :D
17:01:49 <tkelsey> o/ all
17:01:52 <hyakuhei> So this is the last IRC meeting before the midcycle which is exciting
17:01:55 <hyakuhei> oh hai tkelsey
17:02:04 <tkelsey> hi hyakuhei :)
17:02:38 <hyakuhei> As usual we have an agenda over here:https://etherpad.openstack.org/p/security-agenda
17:02:43 <hyakuhei> #link https://etherpad.openstack.org/p/security-agenda
17:02:47 <ccneill> o/
17:02:54 <hyakuhei> elmiko: I’m looking at the gerrit groups
17:03:04 <hyakuhei> do we have security docs core for OSSN ?
17:03:34 <tmcpeak> #link https://etherpad.openstack.org/p/security-agenda
17:03:34 <elmiko> i /thought/ we did
17:03:35 <hyakuhei> I’ll have to check the policy for the OSSN gate,
17:03:38 <tmcpeak> lol
17:03:43 <tmcpeak> I'm about a minute slower than hykauhei
17:03:46 <tmcpeak> this web client sucks
17:03:48 <hyakuhei> elmiko: we have a specific OSSN one
17:03:51 <hyakuhei> but no-one’s in it
17:03:56 <hyakuhei> so I’m guessing that’s not right :P
17:04:03 <sicarie> hyakuhei: i thought that was sec-core
17:05:36 <hyakuhei> yeah, I need to do an audit
17:05:37 <elmiko> honestly, i never worked the levers for the gerrit groups. i know i was able to +2 on ossn, and i thought that was related to sec-core, but not sure about the docs core for ossn
17:06:04 <dg____> o/
17:06:08 <hyakuhei> There’s ways to figure it out, this is all in aid of making lhinds a sec core anyway :)
17:06:13 <hyakuhei> hey dg____
17:06:26 <elmiko> sweet, and grats lhinds =)
17:06:32 <lhinds> thx!
17:06:38 <dg____> good work lhinds
17:06:38 <tmcpeak> +1, well deserved!
17:06:45 <hyakuhei> Yupyup
17:07:08 <hyakuhei> ok, I want to move sec docs up the agenda a bit
17:07:12 <hyakuhei> #topic Security Docs
17:07:34 <hyakuhei> So crdotson is new to the group here, he’s just joined my team over at IBM
17:07:39 <tmcpeak> o/
17:07:46 <crdotson> Hello everyone!
17:07:48 <elmiko> sweet, welcome crdotson
17:07:51 * crdotson waves
17:07:52 <lhinds> hi crdotson
17:08:02 <dave-mccowan> o/
17:08:20 <hyakuhei> Chris might be helping with OSSN/Docs - good security guy, technical writer in a past life, seems like a good guy to have around :)
17:08:22 <singlethink> welcome
17:08:32 <elmiko> awesome ++
17:08:36 <hyakuhei> So obviously I especially wanted him to meet elmiko and sicarie
17:08:42 * sicarie waves
17:08:48 <elmiko> nice to meet ya, later o/
17:08:51 * elmiko giggles
17:08:57 <hyakuhei> lol
17:09:02 <tmcpeak> haha
17:09:11 <unrahul> Hey crdotson welcome!!
17:09:15 <elmiko> i keeed
17:09:16 <tmcpeak> elmiko you're going to attend the midcycle on the big screen again, right
17:09:17 <tmcpeak> ?
17:09:26 <elmiko> maybe just to say hi
17:09:47 <tmcpeak> works for me
17:09:48 <hyakuhei> Now I don’t think its fair to throw crdotson straight into being a docs maintainer but I think we should try to work out what a fast-track to that might be. Starting with OSSNs seems reasonable.
17:09:52 <elmiko> and i'll certainly join any sessions where i can help transition
17:10:06 <elmiko> hyakuhei++
17:10:13 <tmcpeak> yeah, OSSN is a good start
17:10:15 <tmcpeak> fun for the whole family
17:10:17 <lhinds> sounds good!
17:10:23 <hyakuhei> We’ve only just started talking about it
17:11:00 <dg____> crdotson maybe have a look at a few reviews on the security docs, maybe fix something obviously dumb so you get used to the horriblness of the workflow
17:11:12 <elmiko> lol
17:11:27 <tkelsey> workflow isn't _that_ bad :P
17:11:45 <elmiko> come on dg____, stiff upper lip, it's not *all* bad
17:11:47 <crdotson> Sure, I can do that
17:11:48 <hyakuhei> It’s ok when you get used to it
17:11:54 <tmcpeak> crdotson: maybe have a poke around the open bugs here? https://bugs.launchpad.net/ossn
17:12:10 <tmcpeak> you'll have to get started with launchpad, git if you haven't used it, etc
17:12:19 <tmcpeak> then you can assign yourself one of the open bugs that looks legit
17:12:23 <tmcpeak> we also have guidance somewhere...
17:12:34 <dg____> general docs guidance is pretty good
17:12:57 <tmcpeak> #link https://wiki.openstack.org/wiki/Security/Security_Note_Process
17:12:59 <dg____> the RST section in the docs guidance is worth a read too
17:13:28 <tmcpeak> allright, I gotta roll, hopefully see a bunch of you in Austin!
17:13:38 <ccneill> indeed!
17:13:48 <hyakuhei> safe flight tmcpeak
17:13:51 <crdotson> Yep, have used git, haven't used launchpad yet.
17:13:57 <tmcpeak> thank you sir
17:14:04 <lhinds> you have hyakuhei (whose the expert) sitting near you crdotson, but I am also happy to help, having got up to speed over the past few months
17:14:15 <crdotson> Thanks lhinds
17:14:18 <lhinds> s/whose/who is
17:14:20 <lhinds> derp
17:14:35 <hyakuhei> organisationally we sit close, geographically not so much
17:14:51 <lhinds> ahh, thats the way now
17:15:08 <lhinds> I thought we might have had another west country type :P
17:15:48 <hyakuhei> heh, kentucky I think
17:16:06 <crdotson> Yep!  :)
17:16:23 <hyakuhei> Seems like we need to get crdotson up to speed then :) if elmiko or sicarie known any low-hanging bugs to address that’d be handy
17:16:37 <sicarie> I’ll take a look
17:16:58 <crdotson> I'm perusing the Doc contributor guide now
17:17:27 <elmiko> yeah, might be nice if we have something light
17:17:53 <hyakuhei> TBH I’m sure crdotson can find plenty of things he’d want to tweak anyway.
17:18:06 <hyakuhei> ok, lets get back to our scheduled programming
17:18:27 <hyakuhei> #topic Syntribos
17:18:45 <ccneill> kewl
17:18:48 <mdong> cool, so ccneill and I were both out last week at Defcon
17:19:03 <hyakuhei> fancy!
17:19:15 <ccneill> yep yep, was a good time
17:19:33 <mdong> but while we were gone, there was a lot of work done on logging, and we were finally able to close out our “remove and replace OpenCAFE” trello card
17:19:40 <elmiko> nice
17:20:03 <ccneill> so if you haven't given Syntribos a run in a while, you might wanna go check it out
17:20:16 <ccneill> we've revamped the CLI a bit to be (we think) muuuuch clearer
17:20:19 <mdong> unrahul also wrote a fantastic CLI output
17:20:21 <ccneill> thanks to unrahul for the progress bars
17:20:25 <ccneill> and other modifications
17:20:27 <mdong> it’s real pretty
17:20:36 <unrahul> :D ..
17:20:39 <unrahul> thanks guys!
17:21:12 <unrahul> u guys should check it out.. its not perfect.. but Syntribos looks kinda cool ryt now!
17:21:16 <ccneill> we'll be having a discussion soon about how we can automatically generate syntribos templates for different APIs
17:21:29 <ccneill> if anyone has experience/ideas in that area, reach out to us
17:21:49 <ccneill> e.g. using mitmproxy to log results of functional tests, scraping docs, etc.
17:22:02 <hyakuhei> oh that’s none-trivial.
17:22:06 <ccneill> yeah :(
17:22:32 <hyakuhei> burpsuite probably has some discovery stuff ?
17:22:50 <elmiko> too bad we didn't get further with openapi specs for the projects
17:23:05 <ccneill> yeah and we realized documentation doesn't really follow the same conventions either
17:23:15 <elmiko> i would think having an openapi->syntribos template generator would be highly helpful
17:23:26 <ccneill> indeed
17:23:41 <elmiko> plus, could be a good way to reach out to projects as they will most likely be looking at generating these types of docs
17:23:46 <ccneill> in y'all's experience, do OS projects have RAMLs/WADLs/etc?
17:24:07 <elmiko> we had WADLs, but they are being replaced by openapi and possibly a custom format
17:24:11 <ccneill> i.e., is it worth it to support those formats, or should we focus on the "undocumented" approach
17:24:33 <ccneill> I'm not familiar with openAPI, is it something OS-specific?
17:24:34 <elmiko> imo, there is good value to supporting openapi as a format, but probably not worth it for wadl
17:24:42 <elmiko> openapi was formerly swagger
17:24:46 <ccneill> ahhh
17:24:51 <ccneill> these guys? https://openapis.org/
17:24:55 <elmiko> yes
17:25:23 <elmiko> that has been discussed many many times as a possible replacement for wadl in our api-ref site
17:25:24 <ccneill> well perhaps we'll help convince projects by supporting the spec and saying "you can get free security testing if you do to :)"
17:25:33 <elmiko> there was a ton of work over the last year or so about this
17:25:33 <ccneill> too*
17:25:55 <elmiko> yeah, i think that would be awesome. you may want to reach out to anne gentle and sean dague about it too
17:26:09 <ccneill> cool, will do
17:26:11 <elmiko> at least for ideas about how it impacts the OS landscape
17:26:23 <ccneill> any refs off-hand for OS integration with openapi?
17:26:35 <elmiko> let me look, 1sec
17:26:48 <ccneill> if not no worries, I'll touch base with Anne and Sean
17:27:04 <elmiko> i need to dig up some old specs and whatnot. may take a few
17:27:13 <ccneill> cool, if you wanna ping me after the meeting that would be awexome
17:27:20 <elmiko> ack
17:28:05 <hyakuhei> Seems like some good leads, certainly something approaching swagger (I mean openapi) would seem to be extremely useful for all involved
17:28:13 <elmiko> ccneill: good starting point, http://specs.openstack.org/openstack/api-wg/guidelines/api-docs.html
17:28:25 <ccneill> shweet, thanks elmiko
17:28:43 <hyakuhei> That’s not very prescriptive imho
17:28:56 <hyakuhei> “You should do these things” rather than “This is how to do these things”
17:29:04 <elmiko> yeah, agreed
17:29:13 <hyakuhei> Good starting point though I guess
17:29:15 <elmiko> there has been a whole debate swirling around this topic for like 2 years now
17:29:17 <ccneill> eh, best practices is better than "do wtf you want!"
17:29:27 <ccneill> at least we have some commonalities
17:29:31 <unrahul> that would be a significant effort ryt.. will that help us in the near term for Syntribos?
17:29:34 <elmiko> given time i can dig up a bunch of reviews and emails that all talk about it
17:29:39 <unrahul> as the spec has been there for a while..
17:29:42 <hyakuhei> I’m sure
17:30:23 <elmiko> i would say it's an evolving topic, but has come up many times about how do we represent the apis to developers. if there is a way to standardize that, i imagine it would help syntribos
17:30:31 <ccneill> yep
17:30:36 <hyakuhei> Yup
17:30:43 <ccneill> honestly I don't care so much that everyone uses ONE API TO RULE THEM ALL
17:30:47 <elmiko> i'm just not sure where the discussion ended up since i have been slowly moving away...
17:30:49 <ccneill> /API/API spec/
17:30:53 <sdake> o/
17:30:58 <ccneill> but at least that they're using /something/
17:30:58 <sdake> apologies for tardiness
17:31:02 <elmiko> well, the docs team is certainly interested in that ccneill
17:31:06 <ccneill> RAML, WADL, OAPI, etc.
17:31:38 <ccneill> sure, but I mean to say, we can get wins for Syntribos without convincing the entire barge to do a 360
17:31:47 <elmiko> definitely
17:31:52 <elmiko> i just wanted to bring it up
17:32:11 <ccneill> yep, should be a good starting place for us
17:32:14 <ccneill> thanks!
17:32:43 <ccneill> I think that's about it for Syntribos atm. we'll be doing some docs clean-up soon to get it up-to-date with all our latest changes
17:33:02 <hyakuhei> cool, OSSN next
17:33:07 <hyakuhei> #topic OSSN
17:33:16 <hyakuhei> I don’t have much here, saving it for the midcycle :)
17:33:49 <lhinds> Nothing to new from me, was on leave and still working on the ipv6 > qbr > breach
17:34:01 <lhinds> Did have a look a nkinder 's code as well
17:34:12 <lhinds> the scripts for parsing notes
17:34:19 <hyakuhei> Yeah that’s interesting stuff
17:34:56 <lhinds> yep, definately is
17:35:37 <lhinds> other then that, I think you have a backlog under embargo(?) still, that I could get stuck into as well
17:35:40 <hyakuhei> Cool, lhinds are you coming to the midcycle
17:35:54 <hyakuhei> lhinds: I’ll get you added to the right group for that today :)
17:36:08 <lhinds> unfortunately not hyakuhei , but I will make a push for the next one and should get my way
17:36:19 <lhinds> i will be @ the summit though
17:36:34 <lhinds> and happy to take part remotely (if that's possible?)
17:36:52 <hyakuhei> Yeah should be possible, elmiko and dg____ both did that last time
17:36:59 <lhinds> oh that would be cool
17:37:09 <hyakuhei> Excellent
17:37:14 <hyakuhei> ok, lets move on then
17:37:30 <hyakuhei> #topic Midcycle
17:37:44 <hyakuhei> Reminder: #link https://etherpad.openstack.org/p/barbican-security-midcycle-N
17:38:00 <sdake> hyakuhei say - I wont be at midcycle because of budget constraints
17:38:13 <hyakuhei> IBM will be picking up breakfast/lunch - I assume we’ll be getting stuff in
17:38:14 <sdake> hyakuhei will there be remote participation available?
17:38:20 <hyakuhei> sdake: Absolutely
17:38:36 <sdake> hyakuhei nice - thanks :)
17:38:43 <hyakuhei> sorry you can’t be there. it would have been good to have run through the process
17:38:59 <hyakuhei> I know dg____ has been working on parts of that recently
17:39:06 <sdake> i'd propose running through the process remotely if possible
17:39:18 <sdake> if not, or its too lat eto change the agenda, I understand
17:40:27 <hyakuhei> Seems like we can do a remote process the week after
17:40:46 <hyakuhei> Doing a remote process the one week we’re mostly in the same place seems a little disjointed.
17:41:04 <sdake> yup - i hear ya - remote participation in midcycles is rough :)
17:41:23 <sdake> pehraps we can schedule a couple weeks out - we are under heavy strain with osic testing at present
17:41:29 <hyakuhei> Yeah we can do that.
17:41:53 <sdake> cool i'll sync up with you offline on dates
17:41:58 <hyakuhei> At IBM we’ve been doing some threat modelling work internally that I want to share with dg____ and see how it might affect the openstack process
17:42:04 <hyakuhei> cheers sdake
17:43:17 <dg____> hyakuhei great to hear you've been working on that tool, I've been hacking together a bunch of stuff for the guide on this, and we should have the HPE review of Designate hitting the security analysis repo in the next couple of days
17:43:57 <hyakuhei> Excellent!
17:44:03 <elmiko> dg____++
17:44:08 <singlethink> hyakuhei: Did I miss that you're working on a threat modeling tool?
17:44:17 <dg____> it was a typo, should have been too
17:44:36 <singlethink> oh ok... we have one that we're building internally at Cisco
17:44:51 <dg____> oh awesome! are you able to share any details singlethink?
17:44:52 <singlethink> there's some talk of open sourcing eventually
17:45:13 * singlethink checking
17:45:16 <hyakuhei> That would be cool
17:45:55 <singlethink> (don't let me hold up the flow of the conversation)
17:46:13 <hyakuhei> I thnk that was it really :)
17:46:22 <singlethink> ok
17:46:26 <singlethink> I got the thumbs up
17:46:30 <hyakuhei> Sweet
17:46:39 <singlethink> So... basically dev teams make an arch diagram
17:46:54 <singlethink> think high level system diagram that describes data flows
17:47:18 <singlethink> There are pre-defined types of data flows like "public network connection", "database connection", etc.
17:47:45 <singlethink> Through some massaging and annotation, the tool finds boundaries between different trust domains
17:47:59 <hyakuhei> Sounds good, I like the idea of it being open sourced so others can add/customize
17:48:00 <singlethink> and alerts the devs to possible threats that need to be mitigated there (primarily drawing from CAPEC)
17:48:31 <sdake> sounds similar to the manual process we held for kolla at austin summit
17:49:12 <singlethink> yeah... the idea was to try to take the manual process, mash it up with codified domain knowledge about different threats, and give teams an artifact that can evolve over time with their project
17:50:07 <singlethink> I'll mention to the community interest to the manager that's currently in charge over development
17:50:23 <hyakuhei> release early, release often
17:50:31 <hyakuhei> sdake: yeah.
17:50:39 <hyakuhei> What we’ve been doing at IBM is similar too
17:50:53 <singlethink> It's becoming easier to do that here... but it's still a process
17:51:06 <hyakuhei> Very interesting
17:51:19 <elmiko> +1, sounds very cool
17:51:23 <ccneill> yep +1
17:51:49 <hyakuhei> Ok, any more on this stuff?
17:52:04 <hyakuhei> I think we’re onto AOB then
17:52:10 <hyakuhei> #topic Any other business
17:52:19 <dg____> sdake where are we at with the Kolla TA? Do you need anything from us?
17:52:23 <sdake> re kolla TA
17:52:32 <hyakuhei> Oh yeah, if someone could recommend to me where I should order food from in Austin
17:52:53 <sdake> dg____ yes - I think our last step taken was to produce a flow diagram
17:52:54 <sdake> i think hyakuhei did that work
17:53:14 <dg____> great work hyakuhei, hands on leadership
17:53:16 <sdake> if I could get access to that diagram, it would help me produce more diagrams for our other 6 types of containers
17:53:24 <hyakuhei> I think that’s captured in the etherpad.
17:53:33 <dg____> ok sure, I think I have that somewhere....
17:53:37 * dg____ plays hold music
17:54:07 <hyakuhei> #link https://etherpad.openstack.org/p/kolla-newton-summit-threat-analysis
17:54:12 <sdake> once we have diagrams in place, I'm not sure what the next step is
17:54:22 <dg____> thanks you beat me to it
17:54:36 <dg____> sdake the source for the diagrams from the summit are at the bottom of that etherpad
17:54:38 <hyakuhei> basically a discussion of how things work, based on interpretting the diagrams and discussing the threats to the system
17:54:45 <sdake> but we can produce documentation from the diagrams and our understanding of what is needed
17:54:46 <hyakuhei> Which for Kolla are probably quite limited
17:55:08 <sdake> and post that to the security-analysis repo
17:55:23 <sdake> and I guess I need to close the loop on the reno feature for threat-analysis repo
17:55:23 <sdake> I'll do that today
17:55:32 <sdake> its about a 1 hr job
17:55:40 <dg____> ok thanks sdake, it'd be great to have that in place when we start looking at this next week
17:55:56 <hyakuhei> +1
17:55:56 <sdake> dg____ can't promise to have all diagrams in place by next week
17:56:19 <hyakuhei> That’s ok, just see what you can managed. The diagram system we use is _very_ quick
17:56:23 <sdake> but deifnately by the time we have our ta in a few weeks over webex or google hangouts or whatever people want :)
17:56:24 <hyakuhei> in terms of time invested
17:56:36 <sdake> yup I'll work on it
17:56:38 <dg____> sdake no worries
17:56:43 <hyakuhei> Excellent.
17:57:04 <hyakuhei> Ok any last minute things?
17:57:18 <sdake> just a big thanks from kolla for working with us on this :)
17:57:23 <sdake> VMT is very important to us
17:57:32 <hyakuhei> Thanks for being our guinea pigs :)
17:57:38 <sdake> roger that :)
17:57:43 <dg____> np, we really appricate your cooperation sdake
17:58:13 <sdake> just one last uestion
17:58:23 <sdake> do you think we will be able to close this work out before newton concludes?
17:58:38 <dg____> yes
17:58:41 <sdake> nice
17:58:45 <hyakuhei> I’d like to
17:58:45 <hyakuhei> That should be our goal
17:58:55 <elmiko> +1
17:59:02 <sdake> hyakuhei ya - if we can't get it done in a cycle, seems like might be too heavyweight
17:59:09 <dg____> +1
17:59:10 <hyakuhei> +1
17:59:37 <hyakuhei> ok, time people! Thanks all!
17:59:37 <hyakuhei> #endmeeting