17:00:12 <hyakuhei> #startmeeting Security
17:00:17 <openstack> Meeting started Thu Feb 11 17:00:12 2016 UTC and is due to finish in 60 minutes.  The chair is hyakuhei. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:22 <openstack> The meeting name has been set to 'security'
17:00:26 <tmcpeak1> o/
17:00:27 <hyakuhei> #chair tmcpeak1
17:00:28 <openstack> Current chairs: hyakuhei tmcpeak1
17:00:30 <hyakuhei> Yo
17:00:38 <tmcpeak1> good morning
17:00:44 <hyakuhei> Isn’t is just :)
17:00:59 <tmcpeak1> :#
17:01:01 <mdong> o/
17:01:02 <hyakuhei> I’ve got an agenda up here
17:01:03 <elmiko> hi
17:01:03 <hyakuhei> https://etherpad.openstack.org/p/security-20160211-agenda
17:01:05 <cjschaef> hi
17:01:06 <hyakuhei> #link https://etherpad.openstack.org/p/security-20160211-agenda
17:01:06 <LHinds> Hi!
17:01:19 <tmcpeak1> he all
17:01:22 <tmcpeak1> *hey
17:01:59 <bknudson_> hi
17:02:19 <browne> hi
17:02:58 <hyakuhei> ok, so I thought we’d start by going through the actions
17:03:07 <hyakuhei> #topic Actions from previous meeting
17:03:21 <elmiko> hi
17:03:27 <tmcpeak1> seems legit
17:03:30 <hyakuhei> I was supposed to put together a byok spec and propose it on -dev
17:03:33 <hyakuhei> I haven’t but I will
17:03:42 <hyakuhei> Hopefully before I go on vacation (in about two hours).
17:03:48 <elmiko> i took a look at anchor, messed around with it. i have a few questions, but i think the time to iterate on anchor designs may have passed =(
17:03:58 <tmcpeak1> no vacation without seagulling
17:04:08 <hyakuhei> lol, it may have done but there’s versioning in the API now :)
17:04:31 <bknudson_> don't look up seagulling on urban dictionary
17:04:35 <hyakuhei> haha
17:04:35 <elmiko> lol
17:04:37 <bknudson_> actually, don't look up anything on urban dictionary
17:04:57 <hyakuhei> The other task I had was to write up a blog post, that’s on it’s way
17:05:25 <hyakuhei> #link https://github.com/openstack-security/openstack-security.github.io/blob/7b63114c705d63a6f56f3d1f342ecde966a1c4c4/_posts/2016-02-07-anchorTA.markdown
17:05:56 <hyakuhei> #link http://bit.ly/1SjDuzc
17:06:14 <tmcpeak1> woah man, urban dictionary
17:06:15 <hyakuhei> I’m hoping to finish that during my vacation
17:06:20 <elmiko> nice
17:07:02 <hyakuhei> Ok I guess we’ll roll on with the agenda. Please add things to it or -1 next to things you don’t think we need to talk about this week #link https://etherpad.openstack.org/p/security-20160211-agenda
17:07:03 <dg__> vacation lol
17:07:22 <hyakuhei> #topic Anchor
17:07:36 <hyakuhei> #link https://review.openstack.org/#/c/277765
17:07:47 <hyakuhei> So Anchor is getting pretty damned close to what we’ll call feature complete
17:07:54 <dg__> yay
17:07:58 <elmiko> can i ask an anchor design q here?
17:08:00 <tmcpeak1> woot
17:08:01 <hyakuhei> Supports CMC for CSR submission and PKCS11 for backend signing
17:08:03 <tkelsey> o/ sorry im kate
17:08:07 <tkelsey> *late
17:08:08 <tmcpeak1> hi Kate
17:08:10 <hyakuhei> elmiko: sure
17:08:31 <elmiko> so, why the use of forms data on the /sign endpoint instead of a json payload?
17:09:07 <hyakuhei> What would the advantage of a json payload be?
17:09:40 <elmiko> imo, just make a more consistent rest interface
17:09:59 <elmiko> i'm not aware of a technical merit to either approach
17:10:03 <hyakuhei> Interesting. I think because the data format is so static we didn’t need one that was self describing
17:10:14 <dg__> what do you mean by a forms data?
17:10:27 * sigmavirus24 apologizes for being late
17:10:30 <hyakuhei> POST thing=x&thing2=y
17:10:36 <elmiko> well, in the sign controller all the data is parsed from pecan.request.POST...
17:10:43 <dg__> yeah
17:10:49 <tmcpeak1> hey sigma
17:10:54 <elmiko> my understanding is that those values are pulled from a POST form data, is that not accurate?
17:11:02 <hyakuhei> Yeah that’s correct
17:11:20 <hyakuhei> I think the confusion was around the use of the word ‘form’ rather than just POST parameters
17:11:27 <elmiko> ah, sorry
17:11:33 <hyakuhei> i have no idea which is the correct term
17:11:43 * hyakuhei doesn’t do “web things” :P
17:11:46 <bknudson_> https://en.wikipedia.org/wiki/Percent-encoding#The_application.2Fx-www-form-urlencoded_type
17:11:50 <elmiko> mind you, these aren't knocks on the design. i'm just curious to learn the engineering history here
17:12:04 <hyakuhei> simplest path
17:12:06 <elmiko> thanks bknudson_
17:12:15 <hyakuhei> We didn’t really have a format that was going to change much
17:12:15 <bknudson_> web libraries can typically handle form encoding or JSON
17:12:28 * sigmavirus24 agrees with bknudson_ and elmiko
17:12:57 <dg__> theres no reason that you couldnt add a patch to support json too elmiko
17:12:57 <sigmavirus24> Has anyone from anchor looked at the API-WG materials?
17:12:59 <bknudson_> I'd prefer JSON over form encoding just because JSON is the openstack standard.
17:13:04 <hyakuhei> JSON is probably more elegant but the interface is so short I’m not sure it matters that much today.
17:13:12 <elmiko> hyakuhei: i think the main thing that caught my eyes was how anchor is approching the restful service from a different angle than most other openstack services
17:13:19 <hyakuhei> That’s a fair point
17:13:30 <hyakuhei> We can make it more iodiomatic of OpenStack
17:13:44 <elmiko> in that respect, it sits outside of the api conventions we are attempting to create for the community
17:13:46 <sigmavirus24> hyakuhei: also, if there are encoding issues, they *can* be handled in query parameters like that but those will be exponentially simpler in JSON
17:13:48 <dg__> given its two or three fields, json feels like its a bunch more complexity to add
17:13:59 <elmiko> fair
17:14:01 <sigmavirus24> I assume all testing on Anchor has been done with relatively ASCII character set
17:14:27 <hyakuhei> That seems likely though the bulk of the data that gets sent is PEM encoded anyway.
17:15:04 <hyakuhei> One of the requirements was that a simple web cli tool like curl can be used to push-fetch certificates
17:15:15 <elmiko> ok, sorry to derail. but that was the extent of my investigations. i did start to generate a swagger doc for anchor, but i got caught up on the endpoint description details
17:15:17 <hyakuhei> In some cases an anchor client may be a very small, very dumb device
17:15:23 <hyakuhei> No it’s good discussion
17:15:26 <hyakuhei> and I’m happy to have it
17:15:42 <hyakuhei> Thank you for taking a look elmiko
17:15:53 <elmiko> imo, if this is to be an *openstack* service, it might be worthwhile to hack it closer to the guidelines before cutting 1.0
17:16:11 <elmiko> and, i'd be willing to help, but only if the team is interested in that
17:16:23 <hyakuhei> That’s good advice elmiko
17:16:41 <tmcpeak1> +1
17:16:45 <hyakuhei> The concern I have is that it adds complexity and client requirements btu it’s worth looking into
17:17:00 <tmcpeak1> JSON is stdlib
17:17:06 <elmiko> hyakuhei: agreed, maybe i should pow-wow some other time with the anchor team?
17:17:10 <tmcpeak1> shouldn't add client requirements
17:17:17 <hyakuhei> what?
17:17:19 <dg__> tmcpeak1 yes, but currently you can curl a crl to it using cron
17:17:22 <hyakuhei> we’re not talking about a python client
17:17:37 <tmcpeak1> ahh ok, my bad
17:17:41 <elmiko> dg__: yea, and that's a good point about interactivity
17:17:57 <ccneill> o/ sorry I'm late
17:18:08 <tmcpeak1> gotcha, ok I'm back on board
17:18:09 <elmiko> adding a json payload makes the curl usage more complicated, but not impossible
17:18:15 <hyakuhei> sure
17:18:27 <elmiko> anyways, thanks for hearing me out =)
17:18:44 <dave-mccowan> o/
17:18:44 <hyakuhei> So the concern I have is that we _might _ be making something more complicated to make it more openstack.
17:18:48 <hyakuhei> ^ makes me feel dirty.
17:18:51 <dg__> +1
17:18:54 <elmiko> yup, understood
17:18:59 <hyakuhei> However, I can see the upsides too
17:19:05 <dg__> moar openstacks?
17:19:19 <tmcpeak1> I'd say JSON is fairly standard even outside of OpenStack though
17:19:22 <LHinds> is it likely to need to be extended much (beyond the two POST elements?)
17:19:26 <hyakuhei> So we should talk about it, might be that we throw in a json option as an addition
17:19:43 <dg__> its useful feedback thou elmiko, im concious of the point redrobot made about not adding more certificate APIs
17:19:51 <hyakuhei> So existing POST data would work, or you could just swappout the parameters with json
17:19:56 <bknudson_> application should set Content-Type so your app could support both pretty easy
17:19:59 <dg__> LHinds its been quite static for the last 18months
17:20:00 <elmiko> that's the other issue i had too, i don't like the POST to sign methodology, but that's more to do with rest purity than anything ;P
17:20:00 <hyakuhei> dg__: that’s a good point too
17:20:09 <hyakuhei> bknudson_: +1
17:20:18 <elmiko> bknudson_: +1
17:20:25 <hyakuhei> elmiko: oh we had a big conversation about that
17:20:40 <elmiko> i'm sure, it's a tough case design-wise
17:20:45 <hyakuhei> I think we went with POST because it affects a change on the server side.
17:20:50 <elmiko> dg__: yea, and i really apologize for showing up to the party so late
17:20:53 * elmiko feels bad
17:20:59 <hyakuhei> elmiko: no this is really good!
17:21:02 <dg__> elmiko seriously its great feedback
17:21:12 <hyakuhei> Nothing worse than working on something that no one looks at!
17:21:17 <dg__> i mean you need to work a little harder to convince me, but its really useful
17:21:28 <elmiko> hyakuhei: yea, i think you went with a pretty standard pattern, it's just one of those big rest code-smells
17:21:51 <hyakuhei> I’d like to understand more about that but we should probably move on for now
17:21:55 <elmiko> imo, the "resource" that anchor is using are "signings"
17:21:56 <hyakuhei> #topic killick
17:21:57 <dg__> part of the reason I am happy with it in its current state is I have extensively admin'd ADCS PKIs, and this is a simpler distillation of that
17:22:05 <tmcpeak1> I believe we skipped publicity too
17:22:09 <hyakuhei> Oh look dg__ it’s a web PKI thing
17:22:10 <tmcpeak1> although probably not much to say
17:22:13 <hyakuhei> Yeah we did
17:22:18 <elmiko> dg__: fair, and that's an area i lack experience with
17:22:19 <hyakuhei> s/we/I/
17:22:27 <dg__> hyakuhei yay!
17:22:31 <tmcpeak1> that's ok, not much going on there
17:22:54 <dg__> ok, killick?
17:23:00 <hyakuhei> yus
17:23:18 <dg__> so it now issues certs using the latest anchor (as of yesterday anyway) and generates CRLs
17:23:27 <elmiko> hyakuhei: i'll make a more indepth post to the ml, hopefully kick some ideas around
17:23:28 <dg__> elmiko wont like the api
17:23:31 <elmiko> haha
17:23:38 <dg__> elmiko please do
17:23:45 <hyakuhei> Thanks elmiko
17:24:23 <elmiko> should i take a gander at killick too?   ;)
17:24:28 <dg__> killick interface is super simple, curl http://0.0.0.0:5000/v1/list/, curl http://0.0.0.0:5000/v1/admin/issue/7, curl http://0.0.0.0:5000/v1/crl
17:24:33 <dg__> etc
17:24:59 <dg__> heh yeah, but please bear in mind that killick is massively work in progress, like we are still arguing over wether we need it at all, and I wrote most of it on a plane
17:25:07 <elmiko> ah ok
17:25:18 <elmiko> why the curl love, httpie so much better XD
17:25:36 <dg__> like hyakuhei, i dont know web stuff
17:25:45 <dg__> but will look
17:25:47 <tmcpeak1> dg__: where do you want Killick to go?
17:25:49 <elmiko> well that and like every system has curl
17:26:13 <tmcpeak1> what's the grand vision?
17:26:30 <dg__> tmcpeak1 the intention is to provide a super lightweight, super simple alternative to ADCS/Dogtag, for delivering a PKI for your cloud infrastructure
17:26:37 <hyakuhei> “Traditional” Pure-Python CA.
17:26:50 <dg__> with the added bonus that it will do automatic certificate policy enforcement, to make life easier for your poor PKI-admin
17:27:01 <hyakuhei> But with some Anchor smarts in the backend for making automated issuing / recommendations
17:27:04 <hyakuhei> That right ?
17:27:06 <dg__> ^^that
17:27:11 <tmcpeak1> writing a CA sounds hard
17:27:23 <tmcpeak1> are there lots of cryptos involved?
17:27:29 <dg__> nah, we already did that for anchor
17:27:36 <tmcpeak1> I guess you just need do interface with a secret store somewhere
17:27:41 <dg__> from anchor import pki :)
17:27:43 <tmcpeak1> *to
17:27:47 <dg__> yeh
17:27:47 <tmcpeak1> gotcha
17:27:54 <tmcpeak1> so Killick requires Anchor?
17:27:58 <dg__> yeah
17:28:08 <dg__> this is the main reason I want anchor 1.0 out the door and on pypi
17:28:20 <tmcpeak1> gotcha
17:28:26 <tmcpeak1> what other requirements?
17:28:32 <dg__> cryptography.io
17:28:46 <tmcpeak1> so is the idea to throw it in a container or something?
17:29:05 <dg__> unlikely, production pki on containers seems like a bad plan
17:29:18 <tmcpeak1> fair point
17:29:33 <tmcpeak1> I assume a CA should have been vetted somehow too, right?
17:29:35 <elmiko> so... unikernel then?
17:29:38 <elmiko> ;P
17:29:39 <hyakuhei> I actually think there’s a really interesting design pattern for that
17:29:47 <hyakuhei> If you front load AuthN to a more static service
17:30:09 <tmcpeak1> such as?
17:30:13 <hyakuhei> you could have PKI run as a micro service
17:30:15 <hyakuhei> after auth N
17:30:26 <tmcpeak1> I mean are you going to have plugins for all the AuthN bits?
17:30:37 <hyakuhei> It’s something I’m kicking around in my head at the moment
17:30:43 <tmcpeak1> cool, fair enough
17:31:01 <tmcpeak1> so take make this a thing what are next steps
17:31:02 <elmiko> hyakuhei: are you talking about authN-less PKI for trusted sources inside a network?
17:31:03 <hyakuhei> but there’s some nice methods you can use to reduce attack surface
17:31:10 <tmcpeak1> I think you had some discussion on ML a while back yeah? how did that go?
17:31:20 <hyakuhei> if you consider some function of surface .vs. time(exposure) etc
17:31:32 <hyakuhei> oh yeah, back to killick :)
17:32:06 <dg__> heh so yeah thats where killick is
17:32:29 <dg__> this week i have added the CRL functionality, but im not 100% convinced its working properly
17:32:42 <dg__> turns out its quite tricky to test revocation because its so hideously broken
17:32:55 <hyakuhei> hah
17:32:57 <tmcpeak1> dg__: where is this? github?
17:33:04 <dg__> yeah
17:33:09 <hyakuhei> linky
17:33:11 <LHinds> https://github.com/openstack-security/killick
17:33:22 <LHinds> (i think / hope)
17:33:22 <dg__> you guys are quick!
17:33:28 <dg__> LHinds thanks
17:33:34 <LHinds> I was just having a read :)
17:33:46 <tmcpeak1> sweet
17:33:58 <hyakuhei> ok, what’s up next
17:34:00 <tmcpeak1> is this still a holy-war with DogTag?
17:34:07 * elmiko grabs axe
17:34:10 <tmcpeak1> lol
17:34:11 <dg__> tmcpeak1 always
17:34:19 <tmcpeak1> allright, fair enough
17:34:48 <hyakuhei> dg__: redrobot fight!
17:34:57 <dg__> ok anything else to cover on killick? In summary, it kinda works, its nicer than ADCS and its horribly WIP and needs Auth, a sensible database and lots and lots of tests
17:34:57 <tmcpeak1> probably not much to say for security ansible now?
17:35:54 <hyakuhei> dg__: AuthN or AuthZ or both?
17:35:59 <hyakuhei> dunno
17:36:02 <dg__> both
17:36:03 <hyakuhei> mhayden: You about?
17:36:12 <mhayden> hyakuhei: in a meeting for the moment
17:36:14 <dg__> i think we want the following schemes:
17:36:24 <hyakuhei> no worries, thanks
17:36:27 <dg__> admin [single user|keystone|ldap]
17:36:41 <dg__> user [none|single user|keystone|ldap]
17:37:36 <LHinds> may i ask a quick Q about security ansible?
17:38:01 <tmcpeak1> LHinds: fire away
17:38:03 <dg__> go ahead
17:38:07 <hyakuhei> Sure, that’s mainly mhayden s thing but we’ll try
17:38:09 <bknudson_> keystone can be backed by ldap
17:38:33 <dg__> bknudson yeah, but im thinking we may want this in places where there is no keystone
17:38:42 <LHinds> is this playbook writing, or developing modules? I guess a better question would be, where should I go read about the scope?
17:39:02 <LHinds> been doing a fair amount on ansible, so thinking if anything could be used
17:39:14 <tmcpeak1> LHinds: it's been mostly (entirely) playbook writing until now
17:39:21 <tmcpeak1> I don't believe any custom modules have been implemented
17:39:42 <tmcpeak1> I think they have pretty good docs on the repo
17:40:01 <tmcpeak1> #link https://github.com/openstack/openstack-ansible-security
17:40:07 <hyakuhei> +1
17:40:21 <LHinds> tmcpeak1, thanks, will have a look
17:40:31 <tmcpeak1> sounds good
17:41:09 * redrobot pokes head in
17:41:15 <dg__> hey redrobot
17:41:16 <redrobot> totally missed my meeting alarm
17:41:19 <hyakuhei> :D
17:41:31 <redrobot> dg__ what are we fighting about?  Killick some more? ;)
17:41:47 <dg__> you missed the part where elmiko suggested we create yet another pki API....
17:42:06 <elmiko> MOAR APIS!!!!
17:42:08 <redrobot> lol
17:42:10 <dg__> and yeh, I talked killick for a bit
17:42:13 <dg__> how its totes awesome
17:42:29 <redrobot> hehe
17:42:32 <dg__> and maybe even works, except im not sure yet because revocation is so horribly broken
17:42:37 <elmiko> i don't want a *new* api, i just want to completely refactor the existing one. nbd...
17:42:45 <dg__> face desk
17:42:49 <elmiko> haha
17:43:11 <hyakuhei> Ok TIME on Killick
17:43:22 <dg__> +1
17:43:27 <redrobot> darn... sounds like I missed a good bike-shedding opportunity
17:43:35 <dg__> next week
17:43:39 <tmcpeak1> yeah we did a good 30 min bikeshed on that one
17:43:40 <hyakuhei> redrobot: We always invite you Barbican guys for those :P
17:43:41 <dg__> or submit some patches
17:43:58 <hyakuhei> #topic Bandit
17:43:59 <redrobot> hyakuhei it's what we do best ;)
17:44:00 <hyakuhei> tmcpeak1: tkelsey
17:44:08 <tmcpeak1> cool we're making good progress on 1.0
17:44:15 <tmcpeak1> we're tracking with blueprints tagged with 1.0
17:44:20 <bknudson_> I proposed configless bandit to keystone -- https://review.openstack.org/#/c/278136/
17:44:26 <bknudson_> any comments welcome
17:44:29 <tmcpeak1> I've got a couple things i'm working on, browne has some changes, tkelsey also has some
17:44:38 <tkelsey> yeah been doing some docs
17:44:39 <bknudson_> or link to docs
17:44:43 <tmcpeak1> bknudson_: awesome, I'll check it out
17:45:39 <tmcpeak1> that's probably it for Bandit, if anybody has cycles and wants to pitch in please do
17:45:46 <tmcpeak1> we're shooting for code complete end of Feb I think
17:45:50 <tmcpeak1> yeah	tkelsey?
17:45:52 <tkelsey> yeah not much going on
17:45:58 <browne> bknudson_: looks good, but now there is a merge conflict :(
17:46:02 <tkelsey> well nothing that we havnt talked about before :)
17:46:15 <bknudson_> browne: there's always a merge conflict.
17:46:17 <tmcpeak1> I mean that's code complete target right? end of Feb?
17:46:39 <ccneill> if you didn't already see it, we got a little attention this week :) #link https://eng.lyft.com/finding-a-needle-in-a-haystack-b7e0627b01f6#.x7et0d9t4
17:46:57 <tmcpeak1> ccneill: +1
17:47:04 <hyakuhei> oh nice
17:47:06 <browne> ccneill: oh yeah, that was cool
17:47:06 <tmcpeak1> was on front page of HN for a while
17:47:09 <hyakuhei> Lyft and Uber :P
17:47:17 <ccneill> yep yep
17:47:38 <tmcpeak1> that reminds me too
17:47:48 <ccneill> good stuff. I'd love to see more independent work on these types of modules/plugins
17:47:48 <tmcpeak1> I'm going to work on a Bandit overview for SuperUser
17:47:53 <tmcpeak1> the print edition
17:47:54 <tmcpeak1> at the Austin summit
17:48:50 <tmcpeak1> that's probably it for Bandit
17:49:08 <hyakuhei> ok, we’re blowing through the time today
17:49:19 <tmcpeak1> having fun and all that?
17:49:36 <hyakuhei> What else on the agenda do people want to address?
17:49:43 <hyakuhei> As we likely don’t have time for all of it
17:49:50 <browne> another quick thing on bandit.  linters gate job being changed to pep8
17:49:55 <tmcpeak1> yeah
17:50:02 <tmcpeak1> chatted to infra guys
17:50:08 <tmcpeak1> seems like it's just a cosmetic change
17:50:25 <tmcpeak1> new way of doing it is just going to be adding Bandit to your 'pep8' target, which incidentally is designed to run more than pep8
17:51:06 <tmcpeak1> anyway, we can give that a shot and if projects need something else we'll revisit
17:51:26 <bknudson_> projects will probably want to initially use a separate bandit job that's non-voting or experimental
17:51:56 <tmcpeak1> bknudson_: sure, with baseline we're hoping that's less necessary but if that's what projects are comfortable with I wouldn't argue
17:52:08 <tmcpeak1> once 1.0 is out we should be ready to focus on adoption more than development
17:52:33 <hyakuhei> Anyone have any syntribos stuff to discuss? michaelxin ccneill ?
17:52:44 <mdong> sure
17:52:56 <hyakuhei> #topic syntribos
17:52:59 <hyakuhei> hey mdong
17:53:08 <mdong> So we’ve been making steady progress on Syntribos
17:53:20 <mdong> 8 CR’s submitted this week
17:53:28 <tmcpeak1> mdong: awesome
17:53:31 <hyakuhei> Impressive
17:53:36 <mdong> we’d love to see some more code reviews and contributions
17:54:15 <mdong> and we’ll be updating the blueprints at https://blueprints.launchpad.net/syntribos/
17:54:26 <mdong> that’s all I’ve got on Syntribos
17:54:31 <hyakuhei> Cool
17:54:37 <hyakuhei> #topic Any Other Business
17:54:40 <ccneill> I'm gonna try to get some unittests written for syntribos
17:54:50 <ccneill> submitted a patch with some, but they're failing for (currently) unknown reasons
17:55:02 <ccneill> I'll try to track down the problem today
17:55:19 <mdong> awesome
17:55:27 <elmiko> i'm working on a "securing sahara" blog post, hopefully i'll put the PR up by monday
17:55:36 <hyakuhei> elmiko: awesome
17:55:47 <hyakuhei> I’m out of the office pretty much all next week but ping me a link
17:56:02 <elmiko> i also have a skunkworks project about api-fuzzing at scale (using big data clusters). i would really love to get some time to talk with the syntribos team at some point.
17:56:24 <tmcpeak1> elmiko: +1
17:56:50 <elmiko> i want a huge exploity real-world project to propose for a talk this fall ;)
17:57:12 <tmcpeak1> yeah, browne and I might be saving something for Spain
17:57:17 <elmiko> ooh, neat!
17:57:32 <tmcpeak1> why go to Austin when you can go to… not Austin
17:57:34 <tmcpeak1> lol jk
17:57:36 <tmcpeak1> but Spain tho
17:57:39 <elmiko> lol
17:57:52 <elmiko> well, i need more time to exploit a stack before i'm ready :/
17:58:06 <hyakuhei> hehe
17:58:19 <tmcpeak1> Rob's exploited stacks for his upcoming talk too, huh?
17:58:38 <tmcpeak1> at least, like 10 of them
17:58:45 <hyakuhei> Only laterally :P
17:58:50 <elmiko> oh nice!
17:59:06 <tmcpeak1> can I haz root? have to attend to find out
17:59:10 <hyakuhei> Ok that’s about time.
17:59:12 <hyakuhei> lol tmcpeak1
17:59:13 <elmiko> did you get some nice social engineering attacks at rackspace? ;P
17:59:23 <elmiko> i keed, i keed
17:59:23 <hyakuhei> it’d be rude not to
17:59:27 <elmiko> hahaha!
17:59:28 <hyakuhei> #endmeeting