17:01:17 <hyakuhei> #startmeeting Security
17:01:17 <openstack> Meeting started Thu Nov 19 17:01:17 2015 UTC and is due to finish in 60 minutes.  The chair is hyakuhei. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:21 <openstack> The meeting name has been set to 'security'
17:01:25 <hyakuhei> #chair tmcpeak
17:01:25 <openstack> Current chairs: hyakuhei tmcpeak
17:01:28 <hyakuhei> sup yall
17:01:30 <singlethink> hi
17:01:32 <tmcpeak> how it do?
17:01:34 <tristanC> howdee
17:01:34 <michaelxin> hi
17:01:35 <bknudson_> hi
17:01:39 <elmiko> o/
17:01:41 <wayward710> hi
17:01:49 <tkelsey> hi all
17:02:11 <hyakuhei> We’ll give people a second to roll in and then get started :)
17:02:28 <michaelxin> Sorry if I am unresponsive, need to mutli-task in a meeting now.
17:02:46 <hyakuhei> no worries michaelxin - thanks for swinging by :)
17:03:00 <nkinder> hi all!
17:03:01 <hyakuhei> #link https://etherpad.openstack.org/p/security-20151119-agenda
17:03:05 <hyakuhei> Hey nkinder !
17:03:09 <michaelxin> hyakuhei: thanks.
17:04:16 <hyakuhei> ok gues, so take a quick look at the Agenda and add anything required.
17:04:31 <hyakuhei> Sadly we don’t have a redrobot here
17:04:47 <hyakuhei> we haven’t spoken since last week so I don’t have an update on the location yet
17:04:50 <michaelxin> hyakuhei: I met with his boss  this week.
17:05:05 <michaelxin> talk about hosting the event in rackspace.
17:05:25 <michaelxin> They are waiting for our decision.
17:05:56 <hyakuhei> cool, so… soon? I mean it’s only what, ~11 weeks away
17:06:16 <michaelxin> haha
17:06:19 <michaelxin> plan early
17:06:24 <hyakuhei> It’ll fly by!
17:06:39 <michaelxin> When will be a good time to decide?
17:06:51 <tmcpeak> I'm in for Texas :)
17:06:59 <michaelxin> One of the reason is that we want to book for conference rooms.
17:07:02 <hyakuhei> well asap really because if that falls through we’ll have to find something else soon
17:07:08 <tmcpeak> +1
17:07:30 <bknudson_> should check if there's other conferences or something that people want to go to
17:07:35 <bknudson_> (I don't have any)
17:07:35 <hyakuhei> I expect we’ll all be backin texas in April/May
17:07:39 <hyakuhei> bknudson_: good idea
17:07:52 <michaelxin> +1
17:08:05 <michaelxin> So, what's the plan here?
17:08:14 <bknudson_> has barbican picked a date?
17:08:23 <michaelxin> I can talk with them any time.
17:08:44 <dg> 11 weeks time seems rather soon for the mid-cycle, we will loose a lot of time over the vacation
17:09:00 <hyakuhei> It’s because of the release cycle dg
17:09:07 <hyakuhei> So you can commit by/for a certain milestone
17:09:25 <dg> yeah...but...
17:09:38 <hyakuhei> https://wiki.openstack.org/wiki/Sprints
17:09:40 <dg> still, Im +1 for somewhere sunny and warm in january
17:10:02 <bknudson_> can we have a 2 month meeting?
17:10:07 <elmiko> lol
17:10:12 <michaelxin> haha
17:10:21 <hyakuhei> Sounds good
17:10:24 <tmcpeak> yeah I guess it would be better to finalize now so people can book travel before everybody collectively loses interest in work in mid December
17:10:29 <hyakuhei> +1
17:10:42 <hyakuhei> Want it all locked in before people start being AFK for holiday season
17:10:47 <tmcpeak> yeps
17:10:54 <michaelxin> +1
17:10:56 <tmcpeak> so hyakuhei you happy with Austin?
17:10:56 <elmiko> makes sense
17:11:03 <tmcpeak> SA or wherever we're going? ;)
17:11:05 <hyakuhei> I think it was San Antonio right ?
17:11:13 <michaelxin> Yes.
17:11:15 <hyakuhei> Yeah, though I don’t know how many HP can send
17:11:17 <michaelxin> San Antonio
17:11:21 <tmcpeak> ok cool
17:11:27 <bknudson_> HPE?
17:11:35 <tmcpeak> cool, michaelxin: want to check if it's available?
17:12:05 <michaelxin> what's available?
17:12:07 <hyakuhei> bknudson_: yeah HPE
17:12:12 <hyakuhei> *sigh*
17:12:16 <dg> lol
17:12:16 <tmcpeak> the room
17:12:19 <tmcpeak> (s)
17:12:26 <hyakuhei> Typing HP is like 33-50% easier than typing HPE
17:12:35 <elmiko> who's on first? ;)
17:12:39 <tmcpeak> truth
17:12:49 <ccneill> o/
17:12:53 <michaelxin> We already booked 5 break rooms. And in the process of booking two large conferences.
17:13:01 <elmiko> nice
17:13:02 <hyakuhei> excellent thank you michaelxin
17:13:11 <tmcpeak> ok cool, I guess should we fire up the etherpad then?
17:13:34 <tmcpeak> #link https://etherpad.openstack.org/p/security-mitaka-midcycle
17:13:40 <michaelxin> Barbican's mid-cycle will be from Mondy-Wednesday.
17:13:46 <hyakuhei> Good idea, happy for unconference style again though we can lay out a few more stable “must haves” too
17:13:48 <michaelxin> Ours will be from Tuesday-Friday
17:14:10 <michaelxin> So, there will be some overlaps for both teams to co-operate.
17:14:31 <hyakuhei> Excellent, I want Security people to be able to contribute to the Barbican setuff properly
17:14:44 <hyakuhei> which might mean limiting what gets done on Tuesday
17:14:55 <michaelxin> Lisa wants to get confirmation from us.
17:14:57 <tmcpeak> ok so what are our dates?
17:15:01 <tmcpeak> Jan 11-15?
17:16:21 <tmcpeak> geeze, I suck at picking colors
17:16:22 <michaelxin> Barbican Midcycle: Jan 11-13, M-W  (averages 20 attendees though it may be higher w/ Castle location)
17:16:22 <michaelxin> OSSP Midcycle: Jan 12-15, T-F (averages 15 attendees though it may be higher w/ Castle location and Barbican overlap)
17:16:48 <tmcpeak> ok cool
17:17:07 <tmcpeak> ok so as always, please add your name to the list if you would like to attend and think that there's a chance you might be able to
17:17:14 <bknudson_> I'll see if I can get some more people from IBM to go.
17:17:23 <tmcpeak> also add any proposed agenda items
17:17:26 <michaelxin> tmcpeak: +1
17:17:32 <michaelxin> bknudson_: +1
17:17:43 <bknudson_> softlayer is in tx.
17:17:53 <michaelxin> So, the decision is made for the time and location?
17:18:18 <hyakuhei> I think so
17:18:23 <tmcpeak> seems like it
17:18:24 <michaelxin> hyakuhei: Great.
17:18:44 <michaelxin> I will talk with Barbican guys and let them know this.
17:18:51 <tmcpeak> awesome
17:19:07 <michaelxin> So, we can move with booking rooms and other preparations.
17:19:16 <tmcpeak> michaelxin: that would be awesome, thanks man
17:19:20 <hyakuhei> Ok lets roll onto the next point, I want to juggle the agenda a bit to bring this up the stack while michaelxin is around
17:19:25 <hyakuhei> #topic FuzzTest
17:19:29 <hyakuhei> #link https://www.rdoproject.org/blog/2015/11/openstack-fuzztest/
17:19:32 <hyakuhei> So this is interesting ^^
17:19:38 <hyakuhei> tristanC: You around?
17:19:54 <hyakuhei> There’s obvious overlap with Syntribos here
17:20:01 <tristanC> hey, well I figured I might as well present this here
17:20:26 <tristanC> though it have been quite a rush since the summit, so I didn't want to "butt in" the agenda
17:20:34 <bknudson_> in keystone we implemented JSONSchema over most of the API to help with this.
17:20:42 <michaelxin> Yes. Tristan showed me this during the summit.
17:20:47 <tmcpeak> oh this is cool
17:20:53 <hyakuhei> No it makes sense to push it up here, lots of the stuff on the agenda are status checks
17:21:04 <elmiko> bknudson_: does that mean you can get the jsonschema through rest calls?
17:21:06 <ccneill_> also, this.. https://review.openstack.org/#/c/216303/ <_<
17:21:18 <tmcpeak> so for the uninitiated (such as myself), what are the differences between the two tools approaches?
17:21:24 <michaelxin> It is cool to see people come up with different solutions for same problems.
17:21:27 <bknudson_> elmiko: no, we don't have that yet... the jsonschema is used to validate the input
17:21:33 <elmiko> bknudson_: ack, thanks
17:22:08 <bknudson_> it would be easy enough to publish the JSONSchema (although I think there's custom validators)
17:22:23 <tristanC> tmcpeak: restfuzz generates inputs based on api definition while syntribos generates input based on pre-recorded trace
17:22:29 <elmiko> yea, i was just curious (something similar came up during api-wg meeting)
17:22:41 <tmcpeak> oh cool
17:22:50 <dg> tristanC thats cool
17:22:56 <dg> i will have a play :)
17:22:58 <tmcpeak> is the api description generated automatically?
17:23:20 <tristanC> tmcpeak: I couldn't figure a way to do that cross project, so it's currently hand written
17:23:33 <michaelxin> I will play with it for sure.
17:23:37 <tmcpeak> I wonder if the AST can help
17:23:42 <tristanC> tmcpeak: one cool usecase imo is that it also digg the log and display new uniq traceback
17:24:10 <tmcpeak> if we parse the python code for a services rest api, detect the appropriate decorated functions and inputs, and then generate the description automatically from that
17:24:17 <tristanC> tmcpeak: sadly each project seems to have a different approach for api routing, and such ast introspection seemed hard at first glance
17:24:30 <hyakuhei> I like this a lot tristanC
17:24:34 <tmcpeak> tristanC: agreed, it does seem hard.  Prohibitively hard for a PoC
17:24:43 <elmiko> tmcpeak: it would better, imo, to link into the auto-generated api doc impls that working about. like a swagger parser would be ideal for this.
17:24:51 <bknudson_> keystone also has JSONHome to describe the routes
17:24:55 <nkinder> elmiko: +1
17:25:00 <bknudson_> (which is published)
17:25:01 <tmcpeak> elmiko: good point
17:25:25 <tmcpeak> yeah no sense reinventing the sheel… swagger parser does seem ideal
17:25:27 <tristanC> thanks for the feedback guys, I'm not sure this needs to be gone over thoroughly during this meeting
17:25:29 <elmiko> something like the json-home doc would be perfect for this effort as well
17:25:30 <bknudson_> it should be easy enough to switch from JSONHome to swagger
17:25:41 <elmiko> yea exactly
17:25:43 <tmcpeak> that part could be a plugin system
17:25:51 <tristanC> though I'd like to work some more on this, and figures a way to integrate with other framework so that the wheel is not reinvented here
17:26:10 <hyakuhei> Will you be at the midcycle tristanC ?
17:26:24 <hyakuhei> Projects like this often get a really big boost with a hands on sprint
17:26:25 <tristanC> I can't say for now, I'll try to yes
17:26:44 <hyakuhei> Cool
17:27:00 <hyakuhei> ok any questions for tristanC peoples?
17:27:05 <tmcpeak> I'd prefer a clearish definition of the goals of each syntribos and RestFuzz so that we don't duplicate efforts
17:27:13 <hyakuhei> +1
17:27:24 <tmcpeak> I mean the goals are apparently pretty similar, different approaches, which is cool
17:27:38 <tmcpeak> maybe we can plugin the different approaches in some way and leverage common core
17:27:47 <bknudson_> would both syntribos and restfuzz be able to make use of a swagger definition?
17:28:02 <bknudson_> if so I can try to move it up on my list o' things to do.
17:28:36 <elmiko> imo, adding swagger generation to any service project has big win potentials beyond just fuzzing
17:28:44 <hyakuhei> I can see how both would benefit
17:29:32 <bknudson_> if I have questions about publishing JSONSchema or the swagger I've got a contact ( elmiko )
17:29:46 <elmiko> ;)
17:29:50 <tmcpeak> elmiko, aka elswagger
17:29:58 * elmiko chuckles
17:30:02 <hyakuhei> rofl
17:30:12 <hyakuhei> ok, lets do a quick run through of $thethings
17:30:19 <elmiko> bknudson_: you might find this interesting too, http://specs.openstack.org/openstack/api-wg/guidelines/api-docs.html
17:30:21 <hyakuhei> tkelsey: anything on Anchor this week?
17:30:29 <hyakuhei> #topic Anchor
17:30:31 <tristanC> thanks hyakuhei for picking this up :)
17:30:32 <tkelsey> nope, nothing major
17:30:35 <hyakuhei> Nothing to report
17:30:40 <hyakuhei> #topic Bandit
17:30:58 <tmcpeak> tkelsey: want to roll it?
17:31:19 <tkelsey> improvements to baseline stuff, config generator, other stuff
17:31:32 <tkelsey> we just rolled 0.16.2
17:31:37 <tkelsey> let me find the notes
17:31:59 <hyakuhei> congrats, so 016.2 is in pypy?
17:32:02 <tkelsey> ah yeah, some dead code cleaning and similar
17:32:09 <tmcpeak> yep
17:32:18 <hyakuhei> great!
17:32:23 <tmcpeak> something we mentioned a little last meeting, but is worth touching on again
17:32:25 <tkelsey> the config gen is interesting
17:32:35 <tkelsey> i need to find time to properly play with it
17:32:37 <tmcpeak> the baseline system should be perfect for a project to use for a gate
17:32:52 <tmcpeak> basically regardless of how many issues you currently have, the baseline will make sure that you don't introduce new issues
17:33:08 <bknudson_> btw - I've got someone working on enabling bandit for glance
17:33:11 <tmcpeak> so you can kind of draw a line in the sand and say "that's it, no more x, y, and z issues in my project"
17:33:23 <hyakuhei> Yeah that’s going to be useful
17:33:24 <tkelsey> bknudson_: nice
17:33:26 <tmcpeak> bknudson_: awesome!
17:33:57 <tmcpeak> so next step for projects to use this new gate- tkelsey and I will work with the infra guys to get the job set up
17:34:01 <tmcpeak> then it's just up to projects to use it
17:34:05 <elmiko> nice
17:34:19 <tmcpeak> should be an easier sell though than "fix all of your issues, then implement Bandit gates"
17:34:45 <hyakuhei> Though wouldn’t it be lovely if finding issues was something projects wanted?
17:34:51 <tmcpeak> :P
17:34:56 <tmcpeak> crazy talk hyakuhei
17:35:04 <nkinder> hyakuhei: but then you have to fix them! :)
17:35:20 <hyakuhei> Trudat!
17:35:27 <hyakuhei> Any more bandit things?
17:35:30 <tmcpeak> oh
17:35:40 <tmcpeak> is anybody interested in increased Bandit involvement?
17:35:48 <tmcpeak> we've been a little short handed since sigmavirus24 retired
17:35:53 <ccneill_> yep
17:36:05 <elmiko> interested yes, have time no
17:36:07 <ccneill_> I'll have a little more time to dedicate to it over the next month or two as things slow down a bit for the holidays
17:36:07 <hyakuhei> I could possibly move beyond my one commit
17:36:18 <bknudson_> hopefully next year a guy will get freed up and I'd try to get him helping with bandit.
17:36:19 <hyakuhei> What’s required?
17:36:22 <ccneill_> is there a todo list somewhere?
17:36:29 <wayward710> When I wrap up my other stuff and learn more, I'll be looking to get involved with something, so that might be a possibility
17:36:32 <tmcpeak> we have bugs and blueprints in launchpad
17:36:47 <tmcpeak> #link https://launchpad.net/bandit
17:36:59 <tkelsey> ccneill_: ah tmcpeak beat me to it :)
17:37:04 <ccneill_> boom
17:37:05 <ccneill_> ty
17:37:13 <hyakuhei> cool
17:37:18 <tmcpeak> something to think about, I know everybody is busy but IMHO Bandit is a lovely little project :P
17:37:30 <ccneill_> here here!
17:37:31 <tkelsey> tmcpeak: +1
17:37:38 <tmcpeak> cool, that should be it for Bandit :)
17:37:45 <tkelsey> yup ypu
17:37:59 <hyakuhei> cool
17:38:02 <hyakuhei> #topic Killick
17:38:09 <hyakuhei> dg: Anything to add here?
17:38:18 <hyakuhei> Not everyone is sold on short life certificates
17:38:21 <hyakuhei> They want revocation
17:38:25 <hyakuhei> and explaining it doesn’t work
17:38:32 <hyakuhei> doesn’t magically tick their revocation box
17:38:37 <hyakuhei> so now Killick is a thing
17:38:49 <hyakuhei> #link https://github.com/openstack-security/killick
17:38:51 <dg> not touched it this week, although i might have sold it to a couple of people as a solution
17:39:03 <tmcpeak> wait, so just to understand - people want the thing that doesn't work to just work?
17:39:31 <dg> more that they dont understand why revocation doesnt work, so they want to keep doing it the dumb way
17:39:31 <hyakuhei> People want to pretend that the thing that doesn’t work does, because people who don’t know about the thing said it works.
17:39:41 <dg> ^that
17:39:46 <hyakuhei> Yeah what dg said :)
17:40:08 <tmcpeak> umm, ok.  I'm fairly sure I've seen a preso or two from some smart chaps with British accents explaining why revocation doesn't work
17:40:19 <dg> yeah thats us, we are awesome.
17:40:23 <tmcpeak> ;)
17:40:26 <hyakuhei> lol
17:40:31 <elmiko> hehe
17:40:39 <tkelsey> dg: and modest ;)
17:40:40 <hyakuhei> maybe we’re presenting in the wrong places.
17:40:46 <dg> however, anchor was never intended to be a 100% solution
17:40:54 <dg> it was always inteded to be used along with a traditional pki
17:41:10 <dg> anchor is very very cool, and everyone should use it (and hopefully I've got a bunch of other places wanting to use it)
17:41:22 <hyakuhei> Yarp, Anchor is more closed community, falls down for things like production edges.
17:41:26 <wayward710> Is it that revocation doesn't work, or is it that implementing it takes a lot of work and the revocation lists have to be checked?
17:41:38 <nkinder> it's that revocation is painful for certain cases
17:41:38 <tmcpeak> revocation lists can also be blocked
17:41:49 <tkelsey> wayward710: both tbh
17:41:54 <wayward710> thanks
17:42:01 <hyakuhei> wayward710: CRLs are pretty non-deterministic and oftern aren’t checked, in most cases a 404 on a CRL won’t stop crypto systems working
17:42:11 <hyakuhei> and of course OCSP just isn’t a thing outside of the browser.
17:42:14 <dg> wayward710 revocation lists and ocsp mostly only work in the browser, most libraries dont support them
17:42:17 <nkinder> revocation does work, it's just a hassle
17:42:28 <hyakuhei> sometimes it works
17:42:43 <wayward710> gotcha, so that's the push to limit cert lifetimes?
17:42:59 <tmcpeak> yeah, I'd go with "works in limited cases"
17:43:09 <nkinder> if certs are short-lived, you accept the risk of it being compromised for a short period of time
17:43:12 <hyakuhei> Yeah, you get passive revocation, you don’t need to worry about the certificates from yesterday
17:43:15 <hyakuhei> nkinder: you do anyway
17:43:17 <nkinder> ...which might be shorter than a CRL update
17:43:25 <nkinder> hyakuhei: understood
17:43:28 <hyakuhei> typically anchor certs are shorter than CRLs or OCSP caches
17:43:33 <dg> almost no libraries check revocation status. most check certificate expirey
17:43:34 <hyakuhei> nkinder: sorry, slow fingers today
17:43:43 <hyakuhei> So yes, lets not make this an Anchor sales pitch
17:43:49 <hyakuhei> this is for hte thing that isn’t anchor
17:44:05 <hyakuhei> using validation and AuthN chains from Anchor to make smart decisions with Killick
17:44:18 <hyakuhei> or to help inform a human RA to help them make smart decisions
17:44:23 <nkinder> yeah, so it's really just a lightweigh traditional PKI as I see it
17:44:28 <hyakuhei> Yeah
17:44:35 <nkinder> some traditional PKIs can auto-issue too based off of rules
17:44:37 <hyakuhei> lightweight, pure python, easy peasy
17:44:54 <hyakuhei> Not trying to be all things PKI to all people, just enough to do sensible TLS
17:45:02 <dg> +1
17:45:30 <hyakuhei> ok any questions before we roll on?
17:45:36 <hyakuhei> thanks for the questions wayward710
17:45:38 <dg> nkinder as a certificate administrator, i dont want to be manually checking that a request meets our certificate policy
17:45:52 <dg> i want the pki to tell me that this has passed, or the following xyz rules have failed
17:46:04 <hyakuhei> nkinder: Yup, policy for PKI is a thing, you can do it with various tie-ins
17:46:13 <hyakuhei> ADCS does it with roles, EJBCA does it with entities
17:46:15 <nkinder> dg: yeah, understood.  We do this in dogtag
17:46:28 <hyakuhei> Dogtag probably does it with some sort of ritual sacrifice
17:46:34 <tmcpeak> :P
17:46:42 <hyakuhei> generally though they work as part of a wider identity piece
17:46:54 <nkinder> you define cert profiles that can have rules or automated checks (or require manual approval as needed)
17:46:56 <hyakuhei> ADCS needs AD, I’m assuming Dogtag wants FreeIPA/Kerb or something
17:47:07 <nkinder> nah, just uses LDAP underneath it (389)
17:47:32 <hyakuhei> as a core pillar of the issuing, Killick should be able to do some more symantic analysis, like Anchor does with reverse DNS lookups etc
17:47:50 <dg> thats the current approach, it just re-uses the anchor validators
17:48:03 <dg> which has the nice bonus, that if we add functionality to anchor, we get it for free in killick
17:48:11 <hyakuhei> +1
17:48:23 <hyakuhei> Probably want to look at breaking the CA/RA apart more in Anchor
17:48:37 <wayward710> Thanks for the education hyakuhei :)
17:48:45 <dg> theyre fairly broken already i think... tim and I made a bunch of changes last month(?)
17:49:22 <hyakuhei> Yeah but I’m basically thinking that Killick/AnchorCA just become pluggable things. We should sync on this tomorrow :)
17:49:33 <hyakuhei> Just so we don’t chew through the rest of this meeting
17:49:47 <hyakuhei> Speaking of - nkinder want to talk about OSSNs?
17:50:15 <hyakuhei> #topic OSSN
17:50:28 <hyakuhei> #link https://wiki.openstack.org/wiki/Security_Notes
17:50:39 <tmcpeak> oh yeah, saw nkinder did some activity on this
17:50:39 <nkinder> The queue has 4 in it (one embargoed)
17:50:55 <nkinder> I have a draft written up that I'm getting reviewed by a core on the affected project today
17:50:55 <hyakuhei> #link https://bugs.launchpad.net/ossn
17:51:07 <hyakuhei> Great, nkinder let me know when you want me to take a look
17:51:08 <nkinder> ...for the embargoed one that is
17:51:23 <nkinder> hyakuhei: what tool did you use last time for reviewing the embargoed OSSN?
17:51:40 <nkinder> hyakuhei: we could use something like google doc, but you used something else that I can't recall
17:51:59 <tmcpeak> gitlab
17:52:04 <nkinder> that's right
17:52:16 <tmcpeak> OSSN-TEMP
17:52:23 <hyakuhei> Yeah, I’m not sure it’s the best but it was useful enough
17:52:27 <nkinder> ok, well once I have the technical review on the draft, I'll get it over to hyakuhei and tmcpeak
17:52:30 <tmcpeak> yeah worked well enough
17:52:35 <tmcpeak> cool
17:52:40 <tmcpeak> what's the deal with this one? https://bugs.launchpad.net/ossn/+bug/1497031
17:52:40 <openstack> Launchpad bug 1497031 in OpenStack Security Notes "Authenticated Denial of Service in Blacklists" [Undecided,New]
17:52:50 <tmcpeak> how did this even get OSSN on it?
17:53:32 <ccneill_> <_<
17:53:35 * ccneill_ waves
17:53:53 <ccneill_> I wasn't sure how best to handle this issue
17:53:58 <tmcpeak> ahh ok
17:54:03 <ccneill_> I think I asked in the openstack-security channel at some point what th do with it and OSSN was floated
17:54:05 <hyakuhei> Authenticated DOS seems legit?
17:54:18 <tmcpeak> it does seem legit, it just doesn't look like we went through the triage process
17:54:19 <ccneill_> it's definitely a real issue, just wasn't sure of the severity
17:54:24 <hyakuhei> They’ve pushed a fix though, is there no back fix?
17:54:26 <tmcpeak> but yeah, channel works too :)
17:54:41 <tristanC> note that blacklist modification are admin only iirc
17:54:52 <ccneill_> ^ yes, important note
17:54:53 <nkinder> yeah
17:54:55 <hyakuhei> Oh ok
17:54:59 <hyakuhei> I didn’t notice that
17:55:18 <tmcpeak> oh this is a cool bug though
17:55:26 <hyakuhei> OSSN: Admins, don’t intentionally bork your cloud.
17:55:30 <tristanC> the ossn task seems to have been added for extra review before dropping the security status
17:55:33 <ccneill_> arbitrary regexes ftw
17:55:35 <hyakuhei> I suppose if it’s possible to accidentally set this situation up
17:55:49 <tmcpeak> yeah, I'm not sure what to recommend
17:55:49 <nkinder> yeah, but that's not really worthy of an OSSN
17:55:53 <hyakuhei> but I’d be happy enough to not have an OSSN for this as there’s a published fix already
17:56:06 <ccneill_> would CVE be appropriate?
17:56:24 <nkinder> It's just a flat out bug IMHO, not necessarily a security issue
17:56:54 <hyakuhei> +1
17:56:56 <ccneill_> it would be pretty contrived for someone to do this to themselves
17:57:17 <elmiko> do we have time for a brief AOB item?
17:57:22 <tmcpeak> ok so shall we close the OSSN part?
17:57:39 <hyakuhei> #topic AOB
17:57:43 <elmiko> thanks
17:57:48 <nkinder> tmcpeak: Yeah, I'll close it
17:57:51 <tmcpeak> awesome
17:57:55 <elmiko> at midcycle we talked a bunch about threat analysis
17:57:59 <tmcpeak> that's my contribution for the day
17:58:09 <elmiko> i've got buy-in from the sahara team and my local team to do this type of work during mitaka
17:58:21 <tmcpeak> legit
17:58:30 <elmiko> is there any chance of getting the HP threat analysis stuff we talked about during mid-cycle for reference?
17:58:31 <hyakuhei> ok that’s exciting
17:58:42 <hyakuhei> Lets chat about it on -dev
17:58:48 <hyakuhei> :)
17:58:57 <elmiko> yea, i have a clear thought about how we can deliver something that is useful to the community and operators
17:59:00 <bknudson_> HPE
17:59:04 <elmiko> and maybe inspire other teams to do it
17:59:05 <hyakuhei> HPE are still happy to get involved / share our findings
17:59:11 <elmiko> cool, thanks
17:59:20 <elmiko> and yea HPE, sorry for the inaccuracy ;)
17:59:36 <hyakuhei> heheh
18:00:01 <dg> I was working on upstreaming as much of the HPE process as possible
18:00:04 <elmiko> i'll send an email sometime today
18:00:19 <dg> thats still WIP but i should crack on with it really
18:00:19 <tmcpeak> o/
18:00:35 <elmiko> thanks dg
18:00:41 <bknudson_> http://www.businessinsider.com/how-to-say-hpes-name-2015-11
18:00:50 <elmiko> rofl..
18:00:56 <dg> take this to the security room, given the time?
18:01:03 <hyakuhei> yarp
18:01:07 <tmcpeak> thanks everybody!
18:01:07 <hyakuhei> #endmeeting