17:00:14 <tmcpeak> #startmeeting security
17:00:14 <openstack> Meeting started Thu May 19 17:00:14 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:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:15 <tmcpeak> o/
17:00:18 <openstack> The meeting name has been set to 'security'
17:00:21 <tmcpeak> #chair hyakuhei
17:00:22 <openstack> Current chairs: hyakuhei tmcpeak
17:00:24 <gmurphy_> o/
17:00:28 <tkelsey> o/
17:00:34 <tmcpeak> #link https://etherpad.openstack.org/p/security-agenda
17:01:04 <elmiko> o/
17:01:05 <mdong> o/
17:01:14 <michaelxin> o/
17:01:56 <diazjf1> o/
17:02:02 <tmcpeak> hi everybody
17:02:10 <tmcpeak> please have a look at the agenda and add anything if you want
17:02:12 <tmcpeak> otherwise we'
17:02:16 <tmcpeak> we'll get rolling in a minute or two
17:02:17 <hyakuhei> o/
17:02:23 <lhinds> hi everyone
17:02:32 <hyakuhei> I’m about 50% here. Will be 100% here in a few minutes.
17:02:35 <tmcpeak> hey lhinds
17:02:39 <lhinds> hey tmcpeak
17:03:42 <tmcpeak> I pinged nkinder, if we can get him to join I'll move the OSSN to match his schedule
17:03:58 <tmcpeak> meanwhile, let's roll it
17:04:01 <tmcpeak> #topic Anchor
17:04:09 <tmcpeak> tkelsey: you might be the one today
17:04:16 <tmcpeak> don't see Mr. Chivers
17:04:26 <tkelsey> humm, well i got nothing on my radar
17:04:40 <ccneill> o/
17:04:49 <tmcpeak> easy enough
17:04:52 <tmcpeak> #topic Bandit
17:04:59 <tmcpeak> probably not much here either, huh?
17:05:02 <dg___> o/
17:05:08 <tmcpeak> ahh, Chivers
17:05:13 <tmcpeak> you have anything you want to say on Anchor or no?
17:05:14 <tkelsey> nope, quiet times
17:05:23 <tkelsey> bandit ^
17:05:32 <dg___> ditto, not touched anchor this week. soon
17:05:32 <tmcpeak> cool easy enough
17:05:37 <tmcpeak> I'll tell you where there aren't quiet times
17:05:40 <tmcpeak> #topic Syntribos
17:06:01 <tmcpeak> nkinder: thank you for joining
17:06:09 <nkinder> tmcpeak: sure
17:06:13 <tmcpeak> we'll have the Syntribos team do an update and OSSN is next up
17:06:15 <michaelxin> mdong: go ahead
17:06:42 <mdong> so this past week we’ve done a deep dive into improving our tests
17:07:20 <mdong> we’ve taken a second pass on our current security test cases, mostly to streamline them and reduce false positives
17:07:57 <mdong> rahulunair and vinaypotluri have also been working on creating new test cases
17:08:07 <tmcpeak> awesome
17:08:14 <tmcpeak> I see tons of activity in the channel
17:08:16 <ccneill> we'll be doing another design session soon to tackle some architectural changes we're contemplating, including removing OpenCAFE and changing the way we detect "failures"
17:08:34 <ccneill> i.e. making it easier to write further test cases
17:09:28 <ccneill> thanks to elmiko I think we have a pretty good idea of what a transition to oslo.logging and oslo.config will look like from CAFE components
17:09:30 <michaelxin> We are using the broken API that we talked before as our test bed.
17:09:54 <michaelxin> The running against the broken API should start this week.
17:09:56 <ccneill> yes, we should be running all our basic tests against that API by next week
17:10:05 <ccneill> but yeah, we'll start today/tomorrow
17:10:17 <tmcpeak> how are you guys running it, just manually?
17:10:25 <rhallisey> hello.  Sorry I'm late
17:10:27 <ccneill> yeah, local environment
17:10:42 <tmcpeak> you guys have tox or something to pull down broken API and run Syntribos against it?
17:10:54 <tmcpeak> that would be cool, kind of like Syntribos functional tests
17:10:59 <ccneill> yeah we might do that
17:11:06 <ccneill> probably better than bundling it into the repo itself
17:11:09 <michaelxin> That would be cool.
17:11:11 <ccneill> haven't gotten to that point just yet
17:11:15 <ccneill> but it's doable
17:11:25 <tmcpeak> would make a cool demo
17:11:28 <michaelxin> Currently, the broken api is running use docker tool
17:11:40 <michaelxin> locally
17:11:42 <tmcpeak> I've found running against our bandit examples directory to be the best way to quickly show somebody its value
17:12:03 <tmcpeak> would be really cool to get something similar for Syntribos
17:12:08 <ccneill> yep, we're using the vAPI as our sort of "proof" that we can detect X vulnerabilities
17:12:15 <tmcpeak> very cool
17:12:29 <ccneill> I think there will be a good synergy between syntribos + bandit too
17:12:33 <tmcpeak> yeah
17:12:40 <tmcpeak> I've shown some of the IBM guys and they're really interested
17:12:44 <ccneill> nice
17:12:51 <ccneill> in Syntribos? or bandit?
17:12:55 <tmcpeak> Syntribos
17:13:05 <ccneill> sweet
17:13:18 <ccneill> well hopefully we have something to show off very soon :)
17:13:28 <tmcpeak> awesome, great work guys
17:13:40 <ccneill> I think that's about it for now
17:13:42 <tmcpeak> cool
17:13:44 <tmcpeak> #topic OSSN
17:13:49 <tmcpeak> nkinder: around? :)
17:14:02 <tmcpeak> hyakuhei:
17:14:08 <hyakuhei> Hey
17:14:13 <tmcpeak> got nkinder to join
17:14:19 <nkinder> tmcpeak: yep, I'm here
17:14:20 <tmcpeak> I assume it was you that put you wanted his input on the etherpad, yeah?
17:14:34 <hyakuhei> So we’ve spoken a few times about converting or otherwising magicing OSSNs into a more machine-readable / searchable format
17:15:00 <tmcpeak> yeah talked a bit at the summit about it too
17:15:10 <nkinder> Yeah, we specifically looked at YAML ni the past
17:15:15 <hyakuhei> As much as we’d like to fix things with parsing / scripts - I was going to suggest that we have a manual sprint at the summit to change the OSSNs out
17:15:16 <nkinder> though SCAP would be interesting too
17:15:29 <hyakuhei> SCAP gets pretty vendo specific I think
17:15:53 <hyakuhei> Though some tool that takes OSSN from YAML -> SCAP (with additional content from the person doing the conversion) could be interesting
17:16:15 <hyakuhei> So my proposal would be to agree a YAML schema/format  before the mid-cycle
17:16:34 <nkinder> If we agree on a format, I think the conversion won't be too bad
17:16:40 <lhinds> Guesses are that currently people are manually cherry picking from the notes or the security guide
17:16:51 <nkinder> I have a tool that was converting to YAML, but we didn't have an exact format that we ever agreed on
17:17:26 <tmcpeak> I think the original format of OSSN took us pretty far and we've been hesitant to move forward with YAML out of concern for preserving legacy, yeah?
17:17:56 <hyakuhei> Sounds about right. I think the time is right to move onto something more usable overall
17:18:02 <tmcpeak> +1
17:18:05 <nkinder> Partially that, but we also had a concern that less people would volunteer to write them in YAML (it's more of a barrier to entry)
17:18:07 <hyakuhei> Search being particularly interesting
17:18:21 <michaelxin> +1 for searching
17:18:22 <nkinder> but a parseable format would be nice
17:18:27 <tmcpeak> there's also an issue for how to handle things like code snippets nicely
17:18:39 <hyakuhei> Yup that was a concern but nominally it’s either developers or established peoples who are happy to write YAML now.
17:18:43 <hyakuhei> tmcpeak: Interesting
17:19:07 <nkinder> yeah, there are a few things that become tough in YAML
17:20:14 <hyakuhei> Hmmm. Do the VMT ever run into this problem? gmurphy_ ?
17:20:21 <nkinder> I have some YAML tools here - https://github.com/nkinder/ossn-tools
17:20:22 <hyakuhei> I’m open to other formats
17:20:39 <nkinder> There was some other standard in this area that I looked into at one point
17:20:47 <hyakuhei> So nkinder. Are you in favor of the move in principle?
17:21:09 <gmurphy_> sorry only half watching..
17:21:10 <gmurphy_> what now?
17:21:26 <tmcpeak> gmurphy_: does VMT run into issues with code snippets in YAML for OSSA?
17:21:32 <hyakuhei> Do you run into problems with YAML when describing vulns, code snippets etc
17:21:32 <tmcpeak> and if so, how is it solved?
17:21:37 <gmurphy_> we don't include code snippets..
17:21:50 <hyakuhei> good lot of use you are gmurphy_ ….
17:21:53 <gmurphy_> or haven't historically.
17:21:55 <nkinder> hyakuhei: yeah, I'm fine with it.  I think there are big benefits if we add a scanning tool
17:22:13 <tmcpeak> yeah, pain for dealing with code snippets in some cases is less than benefit for creating a searchable format
17:22:21 <ccneill> one way to solve for code snippets: link out to github commits?
17:22:36 <nkinder> ...by scanning tool, I mean that a deployer can create a simple config file that says things about their deployment (versions, services used, etc.), then the tool can find all relevant notes
17:22:42 <tmcpeak> ccneill: that could definitely work in a lot of cases
17:22:53 <tmcpeak> nkinder: +1
17:22:53 <hyakuhei> That being the case nkinder, how involved in the work do you want to be? I’m happy for you to lead the charge or to let it happen, up to you …
17:23:08 <nkinder> We could link to a published note on the wiki with code snippets
17:23:08 <hyakuhei> ccneill: Code snippets tend to be around config changes etc
17:23:19 <hyakuhei> YAML needs a “”” type thing from python :D
17:23:23 * hyakuhei hides.
17:23:43 <nkinder> hyakuhei: I'm happy to be involved, but my time is a bit thin as of late
17:24:09 <ccneill> hyakuhei: we could just gzip/b64 any text blobs in the YAML?
17:24:17 <ccneill> ugly as all hell, but if linking out isn't an option, it's something
17:24:29 <hyakuhei> Righto, so what’s the best way to manage this? Should we start by smashing things into an etherpad? Do we want a security spec to work through the YAML format?
17:24:33 <ccneill> or maybe link out to a textfile hosted in the same location as the OSSNs
17:24:34 <nkinder> CVRF was the format I looked into previously
17:24:40 <hyakuhei> ccneill: I’d like the YAML to be true YAML i.e human readable.
17:24:42 <tmcpeak> ccneill: text file link could work
17:24:48 <tmcpeak> I'd prefer that over B64
17:25:06 <ccneill> B64 definitely makes review/human reading (without a tool) harder
17:25:10 <hyakuhei> Basically I’d like it if it was all native YAML and then we can have tools for cross publishing, making things searchable etc.
17:25:42 <tmcpeak> well code snippets are pretty central to a fair amount of notes so whatever we get has to address that well
17:25:46 <hyakuhei> Hmmm, I imagine Ansible may have fixed this, aren’t there playbooks YAML? They must have to do smart things with code.
17:26:03 <lhinds> hyakuhei, major is doing a lot there
17:26:03 <tmcpeak> hyakuhei: not fixed
17:26:09 <hyakuhei> lol
17:26:11 <lhinds> we can use the remediation snippets
17:26:19 <lhinds> as examples
17:26:22 <tmcpeak> I've had a hard time with getting unedited code in yaml
17:26:32 <lhinds> there is also a lot of the OSSN stuff in SCAP already
17:26:38 <lhinds> we borrow back :)
17:26:52 <tmcpeak> lhinds: link?
17:26:58 <nkinder> Here's a YAML converted OSSN - http://paste.openstack.org/show/497764/
17:27:12 <tmcpeak> this one is easy bc no snippets
17:27:22 <nkinder> let me find one with snippets...
17:27:43 <lhinds> https://github.com/OpenSCAP/scap-security-guide/tree/master/OpenStack/RHEL-OSP/7/input/oval
17:27:59 <tmcpeak> oh yeah, XML
17:28:15 <nkinder> Here's one with an example snippet - http://paste.openstack.org/show/497765/
17:28:16 <tmcpeak> I despise XML but it does tend to handle snippets pretty well
17:28:50 <lhinds> https://github.com/rackerlabs/openstack-ansible-security
17:29:02 <nkinder> SCAP is a bit different, because it can deal with actual scanning and remediation with some tools
17:29:25 <tmcpeak> nkinder: the snippet here isn't awful
17:29:27 <nkinder> ...but it needs knowledge about the platform, so it is vendor/platform specific
17:29:31 <hyakuhei> SCAP gets quite distro specific quite quickly I think
17:29:31 <tmcpeak> not great but isn't awful either
17:29:42 <gmurphy_> what about sticking with the markdown and embedding metadata somehow (maybe like this - https://pythonhosted.org/Markdown/extensions/meta_data.html)
17:30:00 <nkinder> so the YAML my utility produces was designed to be able to spit back out the text form we're been publishing
17:30:11 <nkinder> Maybe that should not be a goal...
17:30:24 <tmcpeak> nkinder: yeah I think we can relax that constraint
17:30:35 <nkinder> I had thought we'd want a human readable form like now, but a YAML form that can be used for parsing
17:30:38 <tmcpeak> gmurphy_: MD is nice but most of the note would end up being metadata anyway, huh?
17:30:44 <hyakuhei> nkinder: +1
17:30:56 <nkinder> so some things can be simplified in the YAML if we change the goals
17:31:27 <tmcpeak> yep yep
17:31:30 <nkinder> For example, you can see that I have a separate item for each paragraph in the "description" section
17:31:34 <michaelxin> What's the goals here again?
17:31:41 <tmcpeak> goal is easily parseable yet also human readable
17:31:53 <hyakuhei> Yup
17:31:53 <ccneill> hmmm..
17:32:06 <ccneill> maybe bad idea, but what if we just make a pretty web UI that generates markdown in a VERY specific way
17:32:18 <ccneill> and build our own parser for the MD we generate
17:32:19 <hyakuhei> Though actually being directly human readable is a weak requirement if we have something from which a human readable version can easily be derived
17:32:24 <nkinder> The direction I was going with this in the past was that YAML would be the canonical format that we commit to the repo
17:32:28 <gmurphy_> tmcpeak: but isn't the point to have some way of linking the note to an actual version of openstack deployed. you would only need to a small set of metadata to achieve this. e.g. the whole document wouldn't necessarily need to be machine parseable…
17:32:37 <hyakuhei> nkinder: +1
17:32:43 <nkinder> ...and we can convert to a human readable form to publish on the wiki
17:33:02 <nkinder> I didn't focus on making the YAML the readable format
17:33:17 <tmcpeak> ok so one question is, do we want to maintain multiple copies of one note or not
17:33:18 <hyakuhei> We want _all_ the info. In _one_ place. With tools that take that info and make a searchable OSSN DB, a human readable OSSN etc
17:33:30 <tmcpeak> I would say no
17:33:59 <tmcpeak> one shot is either human readable or easily converted to human readable AND contains all the data needed to enable our searches
17:34:11 <hyakuhei> So no, the OSSN doesn’t have to be strictly human readable in YAML but I would like it to be self contained so that the published OSSN and various other tooling can all use the same YAML.
17:34:22 <nkinder> hyakuhei: +1
17:34:33 <tmcpeak> cool
17:34:48 <hyakuhei> which I guess potentially puts B64 back on the table as an easy way to encode messy stuff
17:34:57 <tmcpeak> yeah
17:35:02 <hyakuhei> Although it’s ugly from a git POV
17:35:05 <gmurphy_> yeah that makes sense. i was just trying to think of a way around the code snippets etc.
17:35:06 <hyakuhei> reviewing OSSNs etc
17:35:23 <tmcpeak> not that bad, just have a tox env or something that converts
17:35:29 <michaelxin> sound like a good plan
17:35:29 <tmcpeak> hrmm, yeah
17:35:32 <tmcpeak> not great actually
17:35:48 <ccneill> BSON
17:35:50 <ccneill> :D
17:35:59 <ccneill> (jk)
17:36:06 <elmiko> lol
17:36:13 <lhinds> What's the issue with parsing out the values from MD to YAML? I missed the gotcha?
17:36:36 <hyakuhei> lhinds: The MD is weakly enforced. No particularly solid schema
17:37:02 <ccneill> that's why I was thinking maybe we enforce that by making a tool that you build an OSSN in
17:37:11 <ccneill> and it spits out MD in a format we can easily parse
17:37:18 <ccneill> even if that doesn't map to an existing standard
17:37:21 <ccneill> ¯\_(ツ)_/¯
17:37:23 <hyakuhei> A tool to write a doc?
17:37:25 <ccneill> definitely a bit of work to make it happen
17:37:29 <tmcpeak> that's a lot of engineering work
17:37:33 <ccneill> yep
17:37:38 <hyakuhei> We’d be better off having a WSDL
17:37:44 <ccneill> haha
17:37:45 <nkinder> That's sort of what I developed...
17:37:55 <tmcpeak> might be over-engineering this
17:38:01 <hyakuhei> +1
17:38:02 <nkinder> You can write in the plain text form, then convert to YAML (or vice-versa)
17:38:11 <tmcpeak> ok so we like YAML, only problem is how to handle the base64 snippet for review?
17:38:13 <michaelxin> build on nkinder's current tools is better
17:38:15 <hyakuhei> Ask a room full of engineers to write a document.
17:38:20 <ccneill> haha
17:38:49 <hyakuhei> So potentially we could have a gate job extract, decode and show/add the b64 if that’s the route we went
17:38:54 <hyakuhei> ok, lets all have a think about this
17:39:23 <hyakuhei> and talk more next week?
17:39:24 <tmcpeak> rathole deferred until next week? same time?
17:39:29 <hyakuhei> ++
17:39:30 <nkinder> It would probably be useful if someone looked more closely at the tools I wrote
17:39:39 <hyakuhei> I’ll try to stab at it
17:39:42 <nkinder> ..then can give some feedback
17:39:49 <tmcpeak> sounds good
17:39:58 <nkinder> The one problem with code snippets in it right now is that you lose line feeds
17:40:15 <michaelxin> how often do we have code snippet?
17:40:19 <nkinder> pretty often
17:40:21 <ccneill> nkinder: looks pretty reasonable to me
17:40:26 <ccneill> from a quick skim
17:40:31 <nkinder> ..but it's usually for configuration file snippets
17:40:37 <ccneill> if the MD format is enforced consistently enough
17:40:41 <nkinder> we rarely show actual code
17:40:47 <hyakuhei> Yeah it’s more configs
17:41:26 <ccneill> hmmm... is there some way we could abstract that away?
17:41:32 <ccneill> like have a schema for various config changes?
17:41:39 <ccneill> sorry, I keep trying to make this as complicated as possible :P
17:41:44 <hyakuhei> No way
17:41:59 <ccneill> fair enough
17:42:05 <hyakuhei> Some configs are pure python, many are custom logic, some are strange magic
17:42:37 <michaelxin> can we use Block literals for it?
17:42:52 <nkinder> michaelxin: I think we'll have to do something like that
17:42:55 <ccneill> ...what if we just wrote OSSNs as a Python class with a to_yaml method? O_o
17:42:56 <tmcpeak> michaelxin: that would be the easiest
17:43:12 <ccneill> somewhat similar to setup.py
17:43:18 <tmcpeak> I don't know how well it works for code snippets though
17:43:18 <lhinds> There is a echo=FALSE in MD - we could put in our own tags
17:43:55 <tmcpeak> allright guys, glad we're having this discussion
17:43:58 <michaelxin> can we try it for a couple of existing ones?
17:44:02 <tmcpeak> seems like we've got buy in to do OSSN v 2
17:44:04 <lhinds> is it not more stuff like file perm octals, key / values though?
17:44:09 <tmcpeak> maybe have some plays and come back next week with ideas?
17:44:19 <tmcpeak> do want to have some time to chat midcycle
17:44:27 <hyakuhei> Yup, lets get through the rest of the agenda.
17:45:07 <diazjf1> tmcpeak, hyakuhei, so I started an etherpad here: https://etherpad.openstack.org/p/barbican-security-midcycle-N
17:45:15 <tmcpeak> #topic Midcycle
17:45:47 <diazjf1> Having the security midcycle with the barbican midcycle worked out last year and I wanted to see everyones opinion on having both sessions together
17:45:59 <diazjf1> I am also working on getting space at IBM@Austin
17:46:17 <diazjf1> I wanted to get opinions as well as a list of potential attendees
17:46:36 <hyakuhei> I’m very much in favor of an overlapping midcycle again
17:46:39 <diazjf1> #link https://etherpad.openstack.org/p/barbican-security-midcycle-N
17:46:40 <tmcpeak> +1
17:46:51 <michaelxin> +1
17:46:56 <hyakuhei> diazjf1: ping me a mail if you need support for IBM@Austin
17:47:00 <elmiko> +tacos
17:47:03 <nkinder> I think overlapping would work nicely
17:47:18 <hyakuhei> I assumed Rack when I saw Austin
17:47:28 <nkinder> hyakuhei: Especially if we want to proceed more on the certmonger/anchor documentation we talked about at the Summit
17:47:42 <michaelxin> doug and I talked about this.
17:47:43 <hyakuhei> Definitely
17:47:49 <michaelxin> Let IBM try it first
17:47:54 <hyakuhei> Righto
17:47:55 <michaelxin> we can serve as backup
17:48:05 <diazjf1> cool, yeah I'll keep you guys posted.
17:48:29 <michaelxin> diazjf1: +1
17:48:33 <hyakuhei> Righto, let me know if I can help
17:49:21 <hyakuhei> Anything else on the agenda for today?
17:49:23 <diazjf1> Please add your info to the etherpad
17:49:44 <sicarie> blog post review: https://github.com/openstack-security/openstack-security.github.io/pull/24
17:50:54 <hyakuhei> Thanks sicarie
17:52:24 <hyakuhei> Cool, anything else ?
17:53:06 <tmcpeak> should be a wrap
17:53:46 <hyakuhei> Excellent. Thanks everyone!
17:53:50 <michaelxin> thanks
17:53:51 <tmcpeak> thanks everybody!
17:53:53 <tmcpeak> #endmeeting