17:00:34 <elmiko> #startmeeting security
17:00:35 <openstack> Meeting started Thu Sep 24 17:00:34 2015 UTC and is due to finish in 60 minutes.  The chair is elmiko. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:38 <openstack> The meeting name has been set to 'security'
17:00:44 <mihgen> xarses: closing? let's move to #fuel-dev for 5 more min..
17:00:44 <tkelsey> o/
17:00:47 <elmiko> hi
17:00:53 <tkelsey> hey elmiko
17:01:07 <redrobot_mobile> o/
17:01:13 <singlethink> o/
17:01:35 <nkinder> o/
17:02:05 <elmiko> ok, let me dig up the agenda rob sent out. 1sec
17:02:30 <elmiko> #char tkelsey nkinder
17:02:37 <elmiko> #chair tkelsey nkinder
17:02:37 <tkelsey> heh :)
17:02:38 <openstack> Current chairs: elmiko nkinder tkelsey
17:02:41 <elmiko> just in case
17:03:08 <elmiko> ok, lets get this rolling =)
17:03:26 <nkinder> I'm feeling charred...
17:03:32 <elmiko> #topic PTL shenanigans
17:03:32 <gmurphy> lol
17:03:33 <elmiko> lol
17:03:37 <elmiko> #link https://review.openstack.org/#/c/224798/
17:03:55 <elmiko> anyone have additional thoughts on this?
17:04:01 <elmiko> seems like everything went through ok
17:04:03 <tkelsey> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/075275.html agenda
17:04:28 <tkelsey> seems good to me, so Rob is officially setup
17:04:28 <dg_> other than a fantastic opportunity to troll Rob, I have no feelings
17:04:30 <elmiko> thanks tkelsey
17:04:36 <elmiko> haha, nice dg_
17:04:38 <gmurphy> haha
17:04:39 <nkinder> yeah, seems like it's all set
17:04:50 <elmiko> ok then
17:04:58 <elmiko> #topic VMT project tracking
17:05:05 <elmiko> #link https://review.openstack.org/#/c/226869/
17:06:00 <elmiko> gmurphy, tristanC , you guys have anything to add on this one?
17:06:04 <gmurphy> please review. part of the implication to the security group is potentially being roped in for 'audits' of code bases before they are allowed to reach 'vulnerability managed' status
17:06:24 <elmiko> yea, the audit part was the only thing that really stood out to me
17:06:26 <tkelsey> gmurphy: interesting
17:07:10 <gmurphy> basically we don't want to accept a project.. then run bandit and have hundreds of tmp file vulnerabilities or similar
17:07:29 <nkinder> yeah, makes sense
17:07:30 <elmiko> yea, that makes good sense
17:07:34 <elmiko> jinx!
17:07:40 <tkelsey> heh :)
17:07:53 <tkelsey> maybe a standardised bandit config could be a good thing
17:08:01 <tkelsey> as a base level it must pass cleanly ?
17:08:13 <tkelsey> just thinking out loud
17:08:15 <gmurphy> yeah sounds like something to work towards
17:08:18 <elmiko> the real question would be, what plugins to have on that standard?
17:08:34 <tkelsey> sure, we would have to come up with a list
17:08:39 <gmurphy> maybe nut it out over a review?
17:08:44 <elmiko> +1
17:08:45 <tkelsey> probably take a few rounds of revision and input
17:08:52 <tkelsey> +1
17:08:52 <kevinlondon> +1
17:09:03 <edmondsw> have the security team review the #nosec as well?
17:09:15 <edmondsw> so they don't just add those everywhere :)
17:09:27 <gmurphy> good point!
17:09:39 <tkelsey> edmondsw: sounds good
17:09:49 <dave-mccowan> o/
17:09:55 <gmurphy> doesn't bandit have a flag now to ignore or show the nosec tags for such purposes?
17:10:01 <gmurphy> or am i making stuff up?
17:10:16 <bknudson> it would be handy to have an option that required a comment in addition to #nosec.
17:10:17 <tkelsey> gmurphy: not that i know of, but it probably should
17:10:40 <kevinlondon> yeah, I don't think I've seen that feature yet
17:10:55 <elmiko> bknudson: +1
17:10:55 <gmurphy> ok. i must be dreaming..
17:11:04 <tkelsey> kevinlondon: glad you could make the meeting, thanks for that email earlier
17:11:13 <kevinlondon> thanks! no problem :)
17:11:14 <tkelsey> gmurphy: I'll add a bug to create it :)
17:11:32 <nkinder> Sounds like a nice feature to have
17:12:12 <redrobot> I volunteer as tribute to have Barbican go through the new VMT tag process.
17:12:12 <gmurphy> cool.
17:12:23 <elmiko> nice
17:12:27 <gmurphy> haha
17:12:57 <elmiko> is there an action we can associate with this?
17:13:12 <tkelsey> #link https://bugs.launchpad.net/bandit/+bug/1499467
17:13:12 <openstack> Launchpad bug 1499467 in Bandit "Bandit needs an override for #nosec" [Wishlist,New]
17:13:21 <gmurphy> maybe define what a 'security group code audit' means?
17:13:47 <elmiko> ok, yea, but that should be part of the review i suppose
17:14:01 <gmurphy> yeah.. was going to say that
17:14:07 <elmiko> also, i was thinking more about if we could use barbican as a sacri^H^H^H^H^H tribute for the process?
17:14:28 <gmurphy> oh
17:14:29 <gmurphy> right
17:14:50 <redrobot> I haven't read the CR for the new process, but I'm assuming it's similar to what was discussed on the ML
17:14:55 <elmiko> or is that putting the cart before the horse, what with the review and all
17:14:55 <redrobot> I'm concerned about the audit part
17:15:04 <redrobot> mainly because professional security audits are not cheap
17:15:11 <elmiko> well, barbican already has bandit in the gate, right?
17:15:18 <redrobot> elmiko yes, we have bandit
17:15:28 <redrobot> but I read that as "hire a security firm to look at your code"
17:15:29 <gmurphy> maybe wait for the review to land and then we can submit barbican through the process..
17:15:30 <elmiko> so we know we wouldn't get slammed with a bunch of low hanging fruit type stuff
17:15:39 <elmiko> gmurphy: ok, yea. that makes sense
17:15:41 <tkelsey> I think an "audit" should have a manual part, at least to go look at the bandit findings etc
17:16:03 <elmiko> yea, we probably need more resolution on the depth of the initial audit
17:16:08 <tkelsey> but of course, that depends on bandwidth
17:16:25 <elmiko> i certainly wouldn't want to mandate that everything needs a full line-by-line code audit
17:16:50 <tkelsey> yeah, way more than we could ever reasonably do.... but that is why we have bandit
17:16:55 <redrobot> elmiko +1
17:17:01 <elmiko> anything else on this, or can we leave it to the review?
17:17:31 <gmurphy> could this also be a hook for the threat analysis stuff rob was talking about ?
17:17:39 <gmurphy> other than that comment - happy to leave it with the review
17:17:40 <elmiko> ooh, nice idea
17:17:43 <tkelsey> gmurphy: seems like a nice tie in
17:17:59 <elmiko> let's shed it out on the review =)
17:18:04 <gmurphy> agree
17:18:08 <tkelsey> +1
17:18:10 <elmiko> #topic Anchor
17:18:20 <elmiko> anchorites, updates?
17:18:25 <tkelsey> Bunch of stuff in review for Anchor
17:18:31 <tkelsey> please take a look if people have time
17:18:38 <dg_> its on my list for tomorrow
17:18:41 <tkelsey> new X509 extension handling
17:18:55 <tkelsey> Validators now in individual modules
17:18:56 <dg_> be nice to get some eyes on my spec
17:18:57 <dg_> https://review.openstack.org/#/c/227384/
17:19:06 <tkelsey> dg_: +1
17:19:21 <tkelsey> dg_: do you want to talk a little about it here?
17:19:28 <dg_> yeah that'd be cool
17:20:00 <dg_> so basically, the spec is to break out the Anchor Validation functionality into a seperate package, so it can be used by other services
17:20:37 <tkelsey> for background, validation is the rules engine that assert a CSR is good or not
17:20:53 <dg_> this will let us re-use a bunch of the anchor code to build a traditional CA/RA for generating longer term certificates, but still keep the benefits of the automated certificate validation
17:22:01 <dg_> Plan is to build a lightweight python CA with a rest api, that can be admined using a horizon pane, or other stand-alone interface
17:22:16 <elmiko> cool
17:22:45 <kevinlondon> Would it wind up being something like https://github.com/letsencrypt/letsencrypt?
17:22:52 <tkelsey> I like the idea dg_ and once we have a precedent, who know what other uses we may have for a CSR validation lib
17:23:15 <redrobot> dg_ sounds like you're planning to reimplement the CA features of Barbican
17:23:30 <nkinder> yeah, there sounds like there is quite a bit of overlap there
17:23:55 <nkinder> ...vs having anchor provide certificates for underlying openstack services themselves
17:23:57 <dg_> kevinlondon similar, although last time I looked at letsencrypt, it was a public certificate provider, like verisign, not a standalone CA/RA that I could deploy in my datacenter
17:24:10 <dg_> redrobot - does barbican do any automated validation?
17:24:17 <nkinder> Yes, letsencrypt is a public CA
17:24:18 <kevinlondon> got it, understood
17:24:33 <nkinder> dg_: the backend behind barbican does depending on what it is
17:24:34 <tkelsey> yeah i think the take away here is the validation rules, there are plenty of ways to sign a cert
17:24:42 <redrobot> dg_ some, yes.  we could definitely make use of a validation lib
17:24:43 <dg_> redrobot I had considered that this may sit behind barbican as an alternative CA
17:25:00 <dg_> more powerful than the snakeoil ca and lighter weight than dogtag
17:25:02 <nkinder> that woudl be the right approach IMHO, otherwise we have competing APIs
17:26:01 <redrobot> nkinder +1 it would definitely be awesome as a software-only CA for Barbican.  Not a fan of adding a 3rd CA API to OpenStack
17:26:30 <tkelsey> redrobot nkinder : +1 that sounds reasonable
17:26:45 <elmiko> so, is there a blueprint or spec that will be up for this idea dg_ ?
17:27:14 <elmiko> maybe something we can debate about in another arena
17:27:18 <dg_> redrobot agreed, although for a lot of use-cases, we just want to be able to throw a CSR at a CA and get a cert back - so it would be nice it were able to operate sans barbican as well
17:27:58 <dg_> elmiko yes we have talked about writing a spec, at the moment we just have a lot of whiteboard diagrams! my concern is that we may end up bikeshedding too much if we push it into a formal spec
17:28:04 <redrobot> dg_ that's basically what you get with the Snakeoil CA backend now.  I believe DogTag is able to be configured for automatic issuance as well
17:28:24 <nkinder> yeah, dogtag can do that too (it depends on the cert profile that is used)
17:28:25 <elmiko> dg_: yea, seems like we are heading down that path now. but it sounds like there are some good ideas abound
17:28:52 <elmiko> dg_: would you mind writing this up for the ML?
17:29:03 <dg_> elmiko yes it would be good to capture this, I'll write it up. ML or spec?
17:29:27 <tkelsey> spec + ML shout with link would be good
17:29:29 <elmiko> imo spec would be better
17:29:33 <elmiko> tkelsey: +1
17:29:51 <elmiko> #action dg_ to write spec + ML shoutout about lightweight python CA idea
17:29:59 <elmiko> sounds good?
17:29:59 <dg_> damnit, i loose at meetings
17:30:00 <Michaelxin> Sorry, I am late.
17:30:19 <tkelsey> hey Michaelxin
17:30:26 * elmiko waves to Michaelxin
17:30:27 <dg_> Ill try and get something up and out tomorrow/monday
17:30:33 <elmiko> dg_: awesome thanks!
17:30:43 <elmiko> #topic Bandit
17:30:51 <elmiko> tkelsey...
17:30:56 <tkelsey> lots of cool stuff in Bandit as ever :)
17:31:07 <tkelsey> we are pushing on test coverage and docs
17:31:08 <Michaelxin> Thanks Tim
17:31:15 <bknudson> thanks, Tim!
17:31:22 <elmiko> awesome
17:31:26 <tkelsey> I'll be talking to Rob about getting our docs published soon
17:31:42 <tkelsey> kevinlondon: would you like to mention some of your findings?
17:31:46 <kevinlondon> The docs that are there are very helpful tkelsey
17:32:02 <tkelsey> kevinlondon: :)
17:32:20 <bknudson> the docs would be handy when upgrading and enabling new tests.
17:32:29 <kevinlondon> Sure, so I scanned 16 popular open-source projects over the weekend with Bandit to see how we're doing with security. I wasn't expecting to find all that much tbh
17:32:43 <kevinlondon> I wound up finding things in 11 of the projects I checked, so I submitted 9 PRs and 6 issues
17:32:48 <elmiko> ooh, nice!
17:33:02 <kevinlondon> Some of the most common ones are untrusted urls in urllib, shell=True, loading things with yaml, using pickle
17:33:11 <bknudson> do other projects have a vulnerability management process?
17:33:15 <kevinlondon> The asserts disappearing surprises people too
17:33:33 <elmiko> that's a fun one
17:33:33 <kevinlondon> I didn't find one in many of the CONTRIBUTION guides that repos include
17:33:34 <tkelsey> kevinlondon: awesome work :)
17:33:36 <bknudson> or are these not bad enough
17:33:47 <kevinlondon> They're not awful, they're pretty small
17:33:57 <kevinlondon> In one case, a project was using tempfile.mktemp()
17:34:05 <kevinlondon> They used the right thing in every other place, it was just that one
17:34:23 <bknudson> are these projects going to sign up to bandit gating now?
17:34:23 <kevinlondon> In another case, a distributed client / server CI thing was using urllib without checking the url it was going to
17:34:26 <kevinlondon> I filed that one privately
17:34:35 <kevinlondon> I'm not sure, I included a link to bandit whenever I filed an issue / PR
17:34:41 <bknudson> great
17:34:45 <elmiko> nice
17:35:06 <kevinlondon> I'm giving a talk tonight on my finding at http://www.meetup.com/socalpython/events/225224958/, currently 122 people RSVPed
17:35:24 <elmiko> awesome, good luck!
17:35:29 <bknudson> I'd like to see a post to the openstack-dev mailing list with this info, we could use more reasons for openstack projects to run it.
17:35:35 <kevinlondon> Mostly covering the code itself and then talking about why it has security implications. I'm including bandit outputs. I'll send a link to the slides once I post it
17:35:49 <elmiko> bknudson: +1
17:35:49 <kevinlondon> In all cases I changed it so it doesn't uniquely ID the project
17:35:53 <kevinlondon> It's not about pointing fingers :)
17:36:06 <elmiko> that's a good attitude, imo
17:36:07 <kevinlondon> thanks!
17:36:11 <tkelsey> kevinlondon: that sounds really good
17:36:12 <bknudson> that's a long ways for me to go for a meetup
17:36:21 <kevinlondon> hahaha
17:36:21 <elmiko> lol, likewise ;)
17:36:31 <tkelsey> hehe yeah
17:36:42 <elmiko> any other bandit news?
17:37:12 <elmiko> #topic Developer Guidance
17:37:25 <elmiko> i'm not sure where we left this, and i think it was a rob topic
17:37:38 <tkelsey> yeah, Rob is driving this one
17:37:50 <elmiko> i think we were going to buff up the website, but haven't heard anything about it
17:37:51 <tkelsey> maybe table it for next time? unless anyone has input?
17:38:03 <elmiko> yea, anyone have a comment for this topic?
17:38:39 <elmiko> #topic Security Documents
17:38:54 <elmiko> sicarie__: any updates?
17:39:06 <sicarie__> Nothing this week
17:39:16 <sicarie__> I was suposed to send out an update email but was sidetracked at work
17:39:28 <sicarie__> Just scoping what state we want tog et to before Mitaka and pushing for that
17:39:40 <elmiko> ok, cool
17:40:01 <elmiko> #topic Security Notes
17:40:12 <elmiko> thanks to everyone who's been working on these
17:40:18 <elmiko> we've had a bunch merge in the last week
17:40:20 <nkinder> I published 5-6 notes since last week's meeting
17:40:34 <elmiko> many thanks nkinder =)
17:40:41 <nkinder> I think everythign in the queue now needs to be updated by the author(s)
17:40:43 <bknudson> we were pretty backed up
17:40:47 <elmiko> yea
17:41:51 <elmiko> looks like we 4 that are untriaged and have no assignee
17:42:10 <Michaelxin> +1
17:42:14 <bknudson> we need another meetup
17:42:17 <elmiko> maybe something to checkout in the next week or so
17:42:20 <nkinder> Yeah, a few need to be picked up
17:42:47 <nkinder> Anyone interested can look at the queue here - https://bugs.launchpad.net/ossn/
17:43:18 <elmiko> and at this point, we have a lot of good experience spread around for writing them. so... ;)
17:43:52 <elmiko> #topic Syntribos
17:43:58 <elmiko> Michaelxin: any updates ?
17:44:42 <Michaelxin> The project was finally merged to openstack this week.
17:44:50 <elmiko> \o/
17:44:53 <bknudson> there's a repo?
17:45:09 <Michaelxin> yes
17:45:25 <bknudson> http://git.openstack.org/cgit/openstack/syntribos/
17:45:36 <elmiko> #link http://git.openstack.org/cgit/openstack/syntribos/
17:45:43 <elmiko> thanks bknudson
17:46:19 <elmiko> and does syntribos have a git review process and everything, can we create reviews against it?
17:46:46 <Michaelxin> Thanks.
17:46:48 <bknudson> #link https://review.openstack.org/#/q/project:openstack/syntribos,n,z
17:46:49 <Michaelxin> Yes.
17:46:50 <bknudson> no reviews
17:46:57 <bknudson> yet
17:47:03 <elmiko> awesome, very cool
17:47:06 <Michaelxin> I will get other stuff ready this week.
17:47:29 <Michaelxin> Sorry, I am on my phone.
17:47:50 <elmiko> no worries
17:47:58 <tkelsey> so syntribos is officially on gerrit etc now?
17:48:01 <Michaelxin> Will meet with my team and come up with action items tomorrow
17:48:05 <elmiko> tkelsey: yea
17:48:15 <bknudson> who's the core team?
17:48:21 <tkelsey> nice
17:48:32 <bknudson> https://review.openstack.org/#/admin/groups/1093,members
17:48:33 <bknudson> nobody
17:48:52 <elmiko> i would imagine Michaelxin will be the PTL?
17:49:11 <Michaelxin> I will update this week.
17:50:12 <elmiko> #topic Any Other Business
17:50:19 <elmiko> anything thing else?
17:50:21 <tkelsey> Michaelxin:  awesome, looking forward to contributing :)
17:50:39 <Michaelxin> Thanks. Tim
17:51:05 <bknudson> I asked the gus who's proposing the privsep work if he wants it in ossg rather than oslo
17:51:19 <bknudson> some people didn't know ossg had repos
17:51:23 <elmiko> any word back?
17:51:32 <bknudson> last I saw he didn't care where it went
17:51:45 <elmiko> an interesting idea though, and makes sense imo
17:52:40 <bknudson> maybe something to discuss at a tc meeting or ptl meeting if rob is there
17:53:02 <elmiko> +1
17:53:22 <bknudson> I think it fits in with ossg as much as oslo, and would take some of the load off oslo
17:53:49 <elmiko> that's kinda what i was thinking too
17:54:32 <elmiko> ok, anything else?
17:55:10 <elmiko> have a good weekend all!
17:55:14 <elmiko> #endmeeting