Tuesday, 2015-07-28

Davieyviraptor: Yeah, i'll do that tomorrow.  Bed is calling me00:01
Davieyviraptor: But if you have time, do try that devstack plugin ^^00:01
openstackgerritDave Walker proposed openstack/anchor: [WIP] Initial commit of devstack plugin  https://review.openstack.org/20626400:03
*** markvoelker has joined #openstack-security00:09
*** jmckind has joined #openstack-security00:27
*** salv-orlando has joined #openstack-security00:33
*** salv-orlando has quit IRC00:37
*** openstackgerrit has quit IRC00:46
*** openstackgerrit has joined #openstack-security00:47
*** sicarie__ has quit IRC00:49
*** elo1 has joined #openstack-security00:51
*** dave-mcc_ has joined #openstack-security00:53
*** elo has quit IRC00:54
*** bpokorny_ has joined #openstack-security00:55
*** dave-mccowan has quit IRC00:57
*** bpokorny has quit IRC00:58
*** jmckind has quit IRC01:05
*** jmckind has joined #openstack-security01:07
*** jmckind has quit IRC01:09
*** sicarie__ has joined #openstack-security01:09
*** sicarie__ has quit IRC01:11
*** bpokorny_ has quit IRC01:26
*** salv-orlando has joined #openstack-security01:44
*** salv-orlando has quit IRC01:48
*** lexholden has quit IRC01:51
*** sigmavirus24 has quit IRC02:07
*** jhfeng has joined #openstack-security02:20
*** viraptor has quit IRC02:24
*** jhfeng has quit IRC02:33
*** bpokorny has joined #openstack-security02:51
*** bpokorny has quit IRC02:51
*** bpokorny has joined #openstack-security02:52
*** bpokorny has quit IRC02:52
*** bpokorny has joined #openstack-security02:56
*** tkelsey has joined #openstack-security03:05
*** tkelsey has quit IRC03:10
*** rmarathu has quit IRC04:02
*** markvoelker has quit IRC04:04
*** bpokorny has quit IRC04:11
*** bpokorny has joined #openstack-security04:11
*** bpokorny has quit IRC04:14
*** rmarathu_ has joined #openstack-security04:19
*** bpokorny has joined #openstack-security04:20
*** rmarathu has joined #openstack-security04:20
*** bpokorny has quit IRC04:22
*** rmarathu_ has quit IRC04:24
*** rmarathu has quit IRC05:02
*** rmarathu has joined #openstack-security05:02
*** markvoelker has joined #openstack-security05:05
*** tmcpeak has quit IRC05:07
*** markvoelker has quit IRC05:10
*** jamielennox is now known as jamielennox|away05:52
*** viraptor has joined #openstack-security05:53
*** salv-orlando has joined #openstack-security05:55
*** jamielennox|away is now known as jamielennox05:56
*** cx has joined #openstack-security06:41
*** cx has quit IRC06:46
*** salv-orlando has quit IRC06:59
*** markvoelker has joined #openstack-security07:06
*** sdake has joined #openstack-security07:07
*** markvoelker has quit IRC07:11
openstackgerritDarren Chan proposed openstack/security-doc: Renamed Future section and added domain information  https://review.openstack.org/19939307:11
*** elo1 has quit IRC07:17
*** elo has joined #openstack-security07:22
*** browne has quit IRC07:35
*** alex_klimov has joined #openstack-security07:38
*** salv-orlando has joined #openstack-security07:50
*** sdake has quit IRC07:57
*** maikol1 has joined #openstack-security08:06
maikol1hola quien para08:07
maikol1 hablar08:07
*** shohel has joined #openstack-security08:09
Davieyrmarathu: if you install bandit using pip, it should install stevedore aswell.08:11
*** maikol1 has left #openstack-security08:12
*** shohel has quit IRC08:18
*** hyakuhei has joined #openstack-security08:33
*** y_sawai has joined #openstack-security08:44
*** markvoelker has joined #openstack-security09:07
*** markvoelker has quit IRC09:11
*** tkelsey has joined #openstack-security09:13
*** dg_ has joined #openstack-security09:15
*** y_sawai has quit IRC09:29
*** shohel has joined #openstack-security09:36
*** dg_ has quit IRC09:53
*** lexholden has joined #openstack-security10:03
*** alex_klimov has quit IRC10:29
*** salv-orl_ has joined #openstack-security10:34
*** salv-orlando has quit IRC10:37
*** salv-orl_ has quit IRC10:47
*** salv-orlando has joined #openstack-security11:00
*** salv-orl_ has joined #openstack-security11:01
*** salv-orlando has quit IRC11:05
*** alex_klimov has joined #openstack-security11:06
*** rmarathu has quit IRC11:07
*** markvoelker has joined #openstack-security11:08
*** markvoelker has quit IRC11:13
*** hyakuhei has quit IRC11:37
*** hyakuhei has joined #openstack-security11:38
*** hyakuhei has quit IRC11:38
*** dave-mcc_ has quit IRC11:49
*** shohel1 has joined #openstack-security11:58
*** rmarathu has joined #openstack-security11:58
*** shohel has quit IRC12:00
*** markvoelker has joined #openstack-security12:09
*** shohel1 has quit IRC12:11
*** markvoelker has quit IRC12:14
*** markvoelker has joined #openstack-security12:29
*** bknudson has joined #openstack-security12:30
*** shohel has joined #openstack-security12:32
*** edmondsw has joined #openstack-security12:33
*** jmckind has joined #openstack-security12:36
*** dave-mccowan has joined #openstack-security12:44
*** tmcpeak has joined #openstack-security12:47
*** y_sawai has joined #openstack-security12:50
*** y_sawai has quit IRC12:54
*** bknudson has quit IRC12:59
*** lexholden has quit IRC13:02
*** jmckind has quit IRC13:11
*** edmondsw has quit IRC13:14
*** lexholden has joined #openstack-security13:17
*** browne has joined #openstack-security13:19
*** bknudson has joined #openstack-security13:20
rmarathucan anybody help me to understand profiles, plugins in bandit.yaml file here - https://github.com/openstack/keystone/blob/master/bandit.yaml please?13:21
tkelseyhello rmarathu whats up?13:22
tkelseyso the profile is given a name and the list under "include" is a list of tests to run. When you use bandit with the -p option and the profile name, it will only run the tests that are listed13:23
tkelseyso in that example, if running with "-p keystone_conservative" bandit would only run..13:23
tkelseyblacklist_calls             - blacklist_imports             - request_with_no_cert_validation             - exec_used             - set_bad_file_permissions             - subprocess_popen_with_shell_equals_true             - linux_commands_wildcard_injection             - ssl_with_bad_version13:23
tkelseyand nothing else13:23
tkelseythe names like "set_bad_file_permissions" are the plugin test names13:25
tkelseyI have started documenting all of them here: https://review.openstack.org/#/c/205505/4/docs/source/tests/index.rst13:26
rmarathutkelsey: thank you for the immediate response13:27
tkelseyno problem rmarathu :)13:27
rmarathui have few questions, let me put all together and post...give me few min13:28
tkelseyok sure13:28
*** singlethink has joined #openstack-security13:31
*** edmondsw has joined #openstack-security13:51
*** rmarathu_ has joined #openstack-security13:53
*** rmarathu has quit IRC13:55
*** rmarathu_ is now known as rmarathu13:55
*** sigmavirus24_awa has joined #openstack-security13:57
*** sigmavirus24_awa is now known as sigmavirus2413:57
*** maikol1 has joined #openstack-security13:59
*** shohel has quit IRC14:00
maikol1para hablar14:00
*** shohel has joined #openstack-security14:00
*** viraptor has quit IRC14:04
*** jmckind has joined #openstack-security14:14
*** maikol1 has left #openstack-security14:16
*** alex_klimov has quit IRC14:22
*** alex_klimov has joined #openstack-security14:23
rmarathutkelsey: these are the questions I have, please help14:24
rmarathu1. keystone_conservative and  keystone_verbose are the profiles? and those names are user defined and can be given any name?14:24
rmarathu2. include - list mentions the name of plugins? the bandit help lists the plugins and these are the from that list right?(ex: blacklist_calls,blacklist_imports etc)14:24
rmarathu3. under those plugins, there is mention of some data like this -14:24
rmarathu    bad_name_sets:14:24
rmarathu        - pickle:14:24
rmarathu            qualnames: [pickle.loads, pickle.load, pickle.Unpickler,14:24
rmarathu                        cPickle.loads, cPickle.load, cPickle.Unpickler]14:24
rmarathu            message: "Pickle library appears to be in use, possible security issue."14:24
rmarathu        - marshal:14:24
rmarathu            qualnames: [marshal.load, marshal.loads]14:25
rmarathu            message: "Deserialization with the marshal module is possibly dangerous."14:25
rmarathu        - md5:14:25
rmarathu            qualnames: [hashlib.md5]14:25
rmarathu            message: "Use of insecure MD5 hash function."14:25
rmarathu        - mktemp_q:14:25
rmarathu    bad_import_sets:14:25
rmarathu        - telnet:14:25
rmarathu            imports: [telnetlib]14:25
rmarathu            level: ERROR14:25
rmarathu            message: "Telnet is considered insecure. Use SSH or some other encrypted protocol."14:25
tmcpeakramarathu: 1) yes14:25
rmarathuwhat goes they specify?14:25
tmcpeak2) yes14:26
elmikormarathu: for future reference, please use something like http://paste.openstack.org/ for code listings =)14:26
tkelseyrmarathu: ok that may have been better in a pastebin :)14:26
elmikojinx ;)14:26
tkelseyelmiko: heh yeah :)14:26
tkelseyrmarathu: so lets see now14:26
tmcpeak3) they specify plugin specific parameters, in the case of blaclist_calls we have qualnames which lists the qualified name of the function we're testing, ie libname.function_name, and the messasge it should display if its found14:27
tkelseyfor question 1, yes, thats right. They can be anything14:27
tkelseyfor question 2) yes, thats right14:27
tmcpeakrmarathu: tkelsey is working on plugin specific documentation as we speak that should make this more clear14:27
tkelseyquestion 3, that is plugin specific configuration data, some stuff got documented in this patch: https://review.openstack.org/#/c/204136/14:28
tkelseybut it is being reworked, there may still be good info for you though14:28
tkelseyrmarathu: there will be full data on all this soon as a few patches I have in the works land and I can work on it again :)14:29
tkelseyfor now, ask here or read the source if its not covered by that patch I linked14:30
*** shohel has quit IRC14:32
tmcpeakDaviey, sigmavirus24, browne14:33
tmcpeakhave you guys seen the XML thing?14:34
tkelseyhey guys14:34
sigmavirus24tmcpeak: the patch? yes14:34
sigmavirus24I'm on the fence about it14:34
tkelseyso, I cant really continue work on the docs effort until the fate of that patch is decided14:34
tmcpeakso I guess more generally we should decide the future of blacklist calls14:34
tkelseysince it will have a major impact on the names of plugins etc14:34
Davieytmcpeak: Yeah, it was me that complained about the code -> config :)14:34
tmcpeakand then apply our decision universally14:34
tmcpeakDaviey: right14:35
tkelseyto blacklist or not, that is the question14:35
tmcpeakso as most active members I'm hoping we can come to some agreement, and reviews are not.. interactive enough14:35
*** shohel has joined #openstack-security14:35
tmcpeakI've also sent an email to Fletcher asking him to come14:35
tmcpeakbut it's 7:30 over there so he probably hasn't gone to bed yet :P14:35
tkelseyI have a 30 min slot now, then im out for the day14:36
tmcpeakok for starters, does anybody think it makes sense to have mix-and-match14:36
tkelseybut lets try and chat it over now14:36
tmcpeakas in some checks go in blacklist and some are separate functions?14:36
* Daviey is in a conference call... but not one that i am terribly involved with.14:37
tkelseyno, its just confusing for users and confusing for contributors14:37
tkelseywe should have a clear choice, one way or the other14:37
tmcpeakhaha Daviey14:37
tmcpeakright, IMO mix and match is arbitrary14:37
rmarathutkelsey: ok I will look through the patch and ask questions14:37
tkelseyrmarathu: ok cool14:37
tmcpeakone additional fringe option is we could list unsafe XML functions in a separate unsafe XML config, but that seems to be going backwards rather than forwards14:38
brownei actually would rather have plugins rework so that a exploiter of bandit just specified checks, not plugin names.  similar to flake814:38
DavieyWhat do you chaps think about having a layered config?  Ie, default values that can be overridden by user config?14:38
browneand move the profiles out of bandit.yaml14:38
DavieyThat would perhaps solve the issue of configuration ability, but also keeping sane defaults and simple main conifg.14:38
tkelseyDaviey: +10 yes14:38
tmcpeakok two simultaneous ideas at once14:38
tmcpeaksimultaneous=at once14:39
tmcpeaksorry, early :P14:39
DavieyI also agree with browne..14:39
tmcpeakoh ok14:39
tkelseylets stick to one thing, though I have that config on my TODO list Daviey14:39
tmcpeakso same idea14:39
DavieyI am not sure either of those ideas contrasts tho14:39
tmcpeakbrowne: what's the difference between specifying checks and plugin names?14:40
Davieya plugin can support more than 1 test.. Is a check another name for a test?14:40
sigmavirus24Daviey: actually they way we're registering plugins 1 plugin name should be 1 check. A check can probably have multiple tests14:41
brownetmcpeak: well, pretty much the same, but would like it available on the command line.  bandit -x S101, S102  …  where S101 was a well defined code for a check, rather than a plugin name14:41
sigmavirus24i.e. something that checks if a function is called, if it has x, y, z keyword arguments passed to it14:41
sigmavirus24browne: that would be plausible, certainly14:41
tmcpeakbrowne: oh ok, gotcha14:41
Davieysigmavirus24: Maybe i am wrong, but I thought a few plugins had multiple functions?  But bubbled up as one test?14:41
tmcpeakso some way or organizing better14:41
sigmavirus24Would need to rework some stuff though14:41
* Daviey groks code14:42
tmcpeakyeah, that's a fairly big push14:42
sigmavirus24Daviey: perhaps. I'm not intimately certain of all of them14:42
tmcpeakI agree though, as Bandit gets bigger that's the best way to keep organization14:42
tmcpeakso injections are in the 100 range, etc14:42
tmcpeakunsafe functions 20014:42
tmcpeaklike that?14:42
Davieyfunnily enough, https://github.com/openstack/bandit/blob/master/bandit/plugins/xml.py14:42
tkelseyOK, are we not getting off the point now? we can name/map/whatever stuff for sure. But the question is many distinct tests, vs a few configurable ones14:43
sigmavirus24tmcpeak: we can figure those out later14:43
sigmavirus24== tkelsey14:43
brownesure, kinda separate item14:43
tmcpeakso onto this14:43
tmcpeaktests defined in config vs tests defined in tests14:44
sigmavirus24(Daviey: those are individual plugins as far as our plugin system is concerned: https://github.com/openstack/bandit/blob/master/setup.cfg#L97..L114)14:44
DavieyI *think* we are all agreed this doesn't belong in the primary bandit.yaml?14:44
sigmavirus24Daviey: no, I don't think we *all* agreed on that14:44
Davieysigmavirus24: right, yes - that is true.14:44
tkelseyDaviey: whats that?14:44
sigmavirus24tkelsey: the xml config bits for blacklist calls14:44
*** jmckind has quit IRC14:45
Davieytkelsey: Growing the bandit.yaml by 68 lines for a no-op is pretty distasteful IMO.14:45
sigmavirus24So, I'm personally in agreement that as it currently is, the xml module is reimplementing blacklist calls and that it makes sense for those to be included as blacklist calls in the config14:45
tkelseyright, I actually have no problem with the list being in the config. But I am OK with putting it some place else, so long as that place is not in a bunch of functions :P14:45
tmcpeakthe nice part about blacklist functions was that it recognizes a bunch of tests all do the *exact* same thing and just moved it to YAML definitions14:46
tkelseyDaviey: maybe this highlights a problem with the config then? rather than the approach14:46
Davieytkelsey: I'm wondering if there should be a yaml config in the library, then a more sparse one that inherits the library config.14:46
DavieyThat would satisfy my main concern14:46
sigmavirus24Daviey: yeah that's what we were talking about previously14:47
brownethe config is kinda problematic because each time it changes, then a project using it needs to change their copy14:47
sigmavirus24Kind of like having a bunch of ansible roles with their own variables that you can override from a global variables file, yes?14:47
tmcpeakbrowne: yeah, agreed14:47
Davieysigmavirus24: right!14:47
*** jmckind has joined #openstack-security14:47
sigmavirus24browne: yeah that's kind of the main problem with the current patch, right?14:47
tmcpeaksigmavirus24, Daviey: yeah I like that14:47
sigmavirus24It will hurt anyone who's turned off the xml checks14:47
tkelseya "hidden" config stashed some place in the lib might be surprising to people dont you think?14:48
tkelseyim not adverse to it though14:48
sigmavirus24That said, are people turning that off in the projects we know are using bandit?14:48
tmcpeaktkelsey: yeah, I think it needs to be explicit: [OVER-RIDING CONFIG FROM xyz.yaml]14:48
sigmavirus24tkelsey: yes, and I'm not sure it has to be hidden14:48
browne sigmavirus24: yep, i leaning towards having a solution such that projects don't have to have a bandit.yaml14:48
Davieytkelsey: we currently have a hidden config :)14:48
tmcpeakWE DO?! awesome :)14:48
tkelseyDaviey: for sure, but since we are talking about improvements ... :014:49
sigmavirus24browne: right and if we start moving towards flake8, we don't need the yaml bits that we currently have if we don't want them =P14:49
sigmavirus24(i.e., one less dependency :^D)14:49
tmcpeakok so seems like most of us like this idea, is anybody not sold?14:49
tkelseysigmavirus24: could you put a spec/doc/words together about how this might work?14:49
tkelseyits an interesting idea14:49
DavieyActually... the child config could declare what it inherits from14:49
Davieysimilar to how we handle the word-list now14:50
sigmavirus24tkelsey: we should be more explicit about "this", we aren't writing javascript ... yet14:50
sigmavirus24Daviey: like jinja templates? =P14:50
tkelseyso, I have 9mins here lol14:51
tmcpeakyeah.. tkelsey still isn't unblocked14:51
sigmavirus24tkelsey: send an email to the list about the idea and I'll see if I can blueprint/spec something out for us14:51
tkelseylets agree that the config sucks, we need a new one, how about specific vs configured ?14:51
tmcpeaklet's get a path forward so tkelsey can finish docs while he has momentum14:51
sigmavirus24I'm in favor of the patch although I'm concerned about the backwards compatibility problems. That said, semver is what we follow and we've not promised stability (within semver) until 1.014:51
DavieyWHat is the blocking question ?14:52
tmcpeakthe blocking question is how should the XML tests be documented14:52
tmcpeakand for that matter, the blacklist calls14:52
tkelseyno, its how should this be done going forward14:52
tkelseygeneric configured tests or specific names functions14:52
tmcpeaktkelsey: well what's actually holding up your doc effort?14:53
DavieySo it is more how we need to style the config.14:53
tmcpeakwanting to avoid the rework I suppose?14:53
tkelseyI cant document stuff thats going to be ripped out/changed14:53
tmcpeakyeah, fair enough14:53
DavieyWell you can.... Having a basis of current reality isn't so bad14:53
tmcpeakwell, sadly it seems like we're about to make a big push one way or the other - and docs are going to be stale soon anyway14:54
DavieyAs in, it would be smaller to change to the new world than writing from scratch, right?14:54
tkelseywell maybe its, I wont rather than cant. But same difference unless someone wants to step up and do it :P14:54
tmcpeakDaviey: it's a huge doc effort, would suck to rework14:54
DavieyOk, i think i underestimated how much doc this would require14:54
tmcpeaktkelsey: how about this - you push the doc structure, leave document the functionality of our tests, and then if we have to do some copy paste later so be it14:55
tmcpeak^ that without the word "leave"14:55
*** sdake has joined #openstack-security14:55
tkelseythat isnt answering the question. Thats just leaving it haging14:55
DavieyWould it be a really bad time to suggest we consider switching to oslo.config?14:56
tkelseyI also want to say "this is how you do X" and I cant unless we have a clear choice14:56
tkelseyDaviey: yes, stick to the point please14:56
tmcpeaktkelsey: well I guess the other choice is just to leave the docs unfinished for now since we don't have a resolution14:56
tkelseywell with people like rmarathu asking for them I dont think thats a good idea14:57
tmcpeakwe could pick a time, say tomorrow at 9 PST to meet in here and then come to a conclusion one way or another14:57
tkelseyim not sure how we can expect people to use bandit more whole sale without docs14:57
tmcpeaktkelsey: what do you suggest?14:57
DavieyI really think the current implementation is OK with inheritance of config support.14:58
DavieyThat is my only blocker with the branch as is.14:58
tkelseywe come to a decision on what we do vs named funcs or configured tests. I write the docs accordingly. We worry about fixing our config in a nice way after14:58
tmcpeakok well config might be another big doc change14:58
tkelsey not as big as the plugins14:59
DavieySo other than the big config file, what other snags do we have with the branch?14:59
tkelseyok im in a meeting now, sorry, out fo time14:59
tmcpeakyeah, moving out blacklist_calls, blacklist_imports into separate/overridden configs works for me14:59
tmcpeakallright tkelsey, thanks15:00
*** fletcher_ has joined #openstack-security15:00
tmcpeakfletcher_ just in time :)15:00
Davieytmcpeak: did you grasp any other issues?15:00
tmcpeakDaviey: I'm honestly fine either way as long as we can be consistent15:00
rmarathuHaving good documentation is better choice, that helps users like me to try things and give back something back to community in the form of feedback or bugs :)15:00
tmcpeakrmarathu: agreed :)15:01
fletcher_Helllllo, all :)15:01
tmcpeakfletcher_: we're trying to figure out where we want to put "blacklist calls" going forward15:01
fletcher_So i was going to craft a response to Tim's message this morning15:02
sigmavirus24Opinion Daviey will hate me for: Those xml tests belong in blacklist_calls and that's where they should be. The rest of the config topics being discussed are tangential and not helpful at the moment. I'm +2 on the review as it is15:02
tmcpeakI think we can all agree that your XML checks are basically blacklist calls and imports, and it would be better to be consistent.  Either call them as such, or move all the existing blacklist calls and imports into functions15:02
DavieyI can't see any blocker with the current blacklist_calls implementation on the branch15:02
rmarathuapart from keystone yaml file do we have yaml configuration files for other components like nova, cinder, glance,neutron etc?15:02
fletcher_but the tl;dr is, managing a config is harder than post processing, and were still left with the issue of not having any context on these calls15:02
rmarathuplease share the link if they are already existing for openstack gate tests15:02
fletcher_we claim these are 'medium' severity and 'high' confidence - we can't say high confidence at all when we flag things like urllib.open("https://www.google.com")15:03
tmcpeakrmarathu: yeah, although Keystone is the best example and what we point people to, most just copied it15:03
fletcher_If the goal is Bandit to be a Static Analyzer, not just an advanced grep, then it seems we should take advantage of the context and check for things like that15:03
Davieysigmavirus24: No, i don't hate that.. I'm saying that i *am* ok with it, providing the user config complexity remains no worse.15:03
Davieywhich is why the side conversation of configuration IS relevant15:03
sigmavirus24Daviey: I didn't say they weren't relevant15:04
sigmavirus24I said they weren't helpful15:04
Davieysigmavirus24: Well, that i disagree with15:04
fletcher_tmcpeak: so in my opinion, blacklist_calls itself should be deprecated. It's not doing Static Analyzer things, leads to a lot of false positives, and makes management more difficult15:04
tmcpeakfletcher_: agreed, some plugins will want to really dig in to AST15:04
sigmavirus24They're side-tracking the discussion from what's important to discuss so we can help unblock tkelsey15:04
rmarathutmcspack: thank you15:04
tmcpeakfletcher_: well blacklist_calls makes it easy for people who know they have unsafe functions to track the use of those functions without having to be a Bandit dev15:05
fletcher_for example, if I maintain my own bandit.yaml config and we decide to add a new function to the blacklist_calls list (say XML things), then I'm left to either do some weird merging, or miss out on the new check15:05
tmcpeakfletcher_: yeah, I think we're all agreeing that is an issue.  Daviey/sigmavirus24 are suggesting that we allow over-ridden configs15:06
tmcpeakso basically bandit.yaml is base, and on top of that you can add keystone.yaml15:06
tmcpeakDaviey, sigmavirus24: is that a fair description?15:06
Davieysigmavirus24: We haven't really distilled what is the blocking part for tkelsey.  As far as i understand the only thing standing in the way is config file complexity?15:06
Davieyfletcher_ brings up the issue of blacklist being dropped.. but that doesn't block this branch, does it?15:07
fletcher_In my opinion, making it easier for people to add functions to a blacklist versus generating a ton of un-context aware warnings with inaccurate confiences seems to be the wrong approach15:07
fletcher_I agree it makes it easier, but at the cost of the tool's accuracy and usability15:07
sigmavirus24fletcher_: so at the moment no one is writing plugins for bandit except for us15:07
fletcher_I've had this opinion for a while and was going to bring it up at the meeting or whatever, but we just happen to get into it :)15:07
sigmavirus24That said, the xml plugin *currently* is acting exactly like blacklist_calls15:08
fletcher_totally agree with that15:08
sigmavirus24But it's reimplementing that logic for each of its functions15:08
*** bpokorny has joined #openstack-security15:08
sigmavirus24So while blacklist_calls is probably not ideal for most of the checks we currently have there, those xml functions/checks/whatever you want to call them are duplicating logic and acting the same way15:08
fletcher_my point is, we should be moving aware from blacklist_calls. While the first effort at XML is essentially the same functionality, it's the basis to add things like context aware checking15:08
Davieysigmavirus24: I am working on an external deployment specific plugin right now.15:08
sigmavirus24fletcher_: the thing with blacklist_calls is that it gives us flexibility to develop those xml-specific plugins without breaking people15:09
sigmavirus24So while right now it's a hammer15:09
sigmavirus24It's a hammer that people can use until we have a chisel15:09
fletcher_So is the claim that a lot of people add things to the blacklist_calls that we currently aren't checking for?15:09
fletcher_And those people are incapable of writing proper plug-ins?15:09
fletcher_I'm just trying to understand. blacklist_calls seems, to me, to be the obviously wrong approach if Bandit is a Static Analyzer15:10
tmcpeakproviding people with at least an option to easily define functions that they want to detect the usage of is useful15:10
*** bpokorny has quit IRC15:10
sigmavirus24fletcher_: so consider blacklist_calls the entry drug15:10
tmcpeakBandit can be used as a static analyzer, but really it's just a tool to solve problems, and one such problem is "audit the usage of x, y, and z"15:10
sigmavirus24People add stuff to it and realize it isn't powerful enough15:11
tmcpeakin fact we're going to use that very capability for our crypto audit15:11
sigmavirus24Then they write their own plugin15:11
Davieyfletcher_: Where are you saying that blacklist functionality belongs?15:11
sigmavirus24Daviey: I think fletcher_ wants it dead altogether15:11
sigmavirus24It isn't dynamic enough15:11
fletcher_I'm saying that things like XML, urllib, md5, pickle and the other blacklist calls are inaccurate and resultin fatigue15:11
DavieySo.. if i wanted to opt-out of a test, is it by config?15:11
fletcher_i can agree having  blacklist_calls for random functions people want to add, would be useful15:11
sigmavirus24So the thing is you're saying that `urllib.open('https://google.com/')` should or shouldn't be flagged?15:12
fletcher_but moving a bunch of stadnard calls to it seems counter to how we could use the AST and really make Bandit rock15:12
tmcpeakfletcher_: well what additional analysis are you going to do on a md5 call to know if it's an issue?15:12
sigmavirus24tmcpeak: I was wondering the same about urllib.open and the xml functions15:12
fletcher_fair enough, maybe md5 was a bad example. I'd still imagine a statc string, versus a variable named '.*pass.*' might warrant a higher confidence15:13
tmcpeakright, it seems in some cases just detecting usage of potentially unsafe functions is the best you can do and adds some value15:13
fletcher_sigmavirus24: shouldn't15:13
fletcher_sometimes, but a lot of these could15:13
fletcher_and, imo, we shouldn't be adding functions to the list that could15:14
tmcpeakfletcher_: so it seems that some functions could definitely take advantage of additional detection like that, but in some cases you can only detect a usage which does in itself provide some value to draw attention for pentesting etc15:14
fletcher_(i'm not being short, if it reads I am; just a million windows open at once)15:14
sigmavirus24fletcher_: why wouldn't urllib.open('https://something.com') be a problem?15:14
fletcher_they clami is that we should audit protocol on that15:15
tmcpeakso personally I use Bandit for two completely different flows - gate test, I want to make sure devs aren't checking in crap and pentesting, where I can accept false positives as they are easy to rule out and sometimes draw my attention to cool issues15:15
fletcher_if it's a static string, then I would flag that has confidence low, versus if it was a variable15:15
fletcher_e.g. urllib.open(requiest.iv.get('url'))15:15
tmcpeakthat's why configuration is good, there's a pentest config and a gate config15:15
sigmavirus24fletcher_: ah, but you're missing the point where (except for very very very very recent versions of urllib(2)) it doesn't do HTTPS verification and that in and of itself is really bad, and we're all very confident about that15:16
fletcher_imo, Bandit should be at it's core a Python security static analyzer15:16
fletcher_so maybe its a conflict of philosophy15:16
sigmavirus24or maybe that particular example is a really bad one given the terrible-ness that is urllib.open15:17
sigmavirus24(disclaimer: I'm a core developer of requests)15:17
tmcpeakwe're kind of down in the weeds a bit15:17
fletcher_"Audit url open for permitted schemes. Allowing use of file:/ or custom schemes is often unexpected."15:17
fletcher_that is the message, unrelating to HTTPS at all15:17
tmcpeakremoving the ability to check function calls to make Bandit fit in more with the traditional static analysis concept doesn't make a lot of sense15:18
sigmavirus24fletcher_: so the message is bad, not the check15:18
fletcher_tmcpeak: agreed! I was thinking an in person convo would be better :)15:18
fletcher_No, i disagree with that as well15:18
tmcpeakyeah, sadly IRC is probs the best we can do currently :)15:18
fletcher_in general, the blacklist_calls checks are unaware and report confidences and severities that are inaccurate15:18
tmcpeakfletcher_: well we're also getting ready to use Bandit to audit all the places in the code where crypto is used15:19
tmcpeakwe can't do that without configurable blacklist calls15:19
tmcpeakin pentesting I've also found a function is insecure, added it to blacklist calls, and used that to trace through the end-to-end exploit15:19
fletcher_so I also totally agree we should provide that functionality, the ability to add a simple list of function calls. I'm saying we shouldn't continuously add functions (like XML and pickle) checks that are unaware to the list15:19
fletcher_it should be a very minimal (ideally empty) list that you can add to15:20
tmcpeakfletcher_: ok I see some merit in that15:20
tmcpeakfletcher_: so let's talk about the XML calls15:20
tmcpeakwhat are we going to add to those, or are they finished?15:20
tmcpeakif they're finished, I'm in favor of moving all of the calls into a config file that is separate from the main bandit.yaml15:21
fletcher_the current diff that was suggested was to delete them from plugins and move them to blcaklist_calls, so they're already done15:21
tmcpeakfletcher_: were you planning to add more?15:21
*** dwyde has joined #openstack-security15:21
tmcpeakcontextual awareness, etc?15:21
fletcher_all the XML checks exist now, I had planned to add some of that yes15:21
tmcpeakfletcher_: ok cool, that in that case they should certainly live in code, as blacklist calls will not  support adding additional contextual awareness15:22
fletcher_tbh, I don't think that should be the blocker on the diff if everyone besides me thinks blacklist_calls is the right choice15:22
fletcher_I think we're kind of at a fork in the road on deciding what blacklist_calls and what it should be going forward15:22
fletcher_sounds dramatic, lol15:23
tmcpeakwell I'm ok with that being the line we draw: "is it a simple function qualname check? if so —> blacklist calls", "are we checking additional factors or will we in the future? —> separate functions"15:23
sigmavirus24tmcpeak: so I would say, "Will we in the future?" is a bad question15:23
fletcher_Wouldn't it be better to have them all in plug-ins? If people want to contribute, it becomes much easier than ripping things out and starting completely fresh15:23
DavieyI suppose it is ok for a plugin to begin life as a blacklist call then migrate over to a separate plugin.15:24
sigmavirus24Because saying "Okay let's duplicate the blacklist calls functionality until someone sometime in the ambiguous future adds to this"15:24
tmcpeakDaviey: I agree, it's a simple move15:24
sigmavirus24== Daviey15:24
tmcpeaksigmavirus24: sure, that makes sense15:24
fletcher_fair enough, but that seems like it just means "continue to add to blacklist_calls"15:24
fletcher_Maybe we start requiring plug-ins to be more context aware15:24
tmcpeakfletcher_: I don't want to go down that road, contextual aware isn't proven and I want to keep a low barrier to entry for newer users15:25
*** bpokorny has joined #openstack-security15:25
sigmavirus24also, a reminder, a plugin can begin its life as a third-party thing15:25
sigmavirus24and that can be as contextually aware or not15:25
tmcpeakso I'm ok with the approach that "if blacklist calls/blacklist imports fills your need, it belongs there, otherwise separate function"15:26
sigmavirus24and based on adoption we can absorb it upstream15:26
fletcher_tmcpeak: i can agree with that, but it seems like a that point you just write your own config for your own functions. landing unaware checks in the main tool in the main repo is destined to make the tool less accurate15:26
tmcpeakI do want blacklist calls, imports to be over-rideable like I believe Daviey was suggesting so bandit.yaml doesn't balloon and projects don't get stuck having to merge everytime Bandit changes15:27
tmcpeakfletcher: yeah I think you can just write your own config files instead15:27
tmcpeakor own plugins works too15:27
fletcher_Sure, but now the tool is inherently noisey15:27
fletcher_with a bunch of checks that are inaccurate15:27
tmcpeakfletcher_: yeah, that's why we have profiles - if you don't like the results from a plugin, disable it15:28
Davieyfletcher_: Flipping things on their head slightly towards your concern, what if a plugin is a test which exposes attributes such as "tests_blacklist".. then the type of test isn't the identifier, but the attributes a test exposes is the identifier.  Not saying it is worth the effort, but is that the direction you were thinking?15:28
tmcpeakDaviey: I didn't follow that15:28
* sigmavirus24 either15:29
DavieyHmm, i need a whiteboard.15:29
DavieyDon't worry... carry on.15:29
fletcher_tmcpeak: fair enough, i'm not overly familiar with profiles. that essentially leaves us in a situation of "oh, is this too inaccurate and nosiey for you, tweak it down and manage". It seems we should have the opposite approach "this tool will only report really relevant things, but you can add noisier checks easily if you'd like"15:29
tmcpeakfletcher_ true although adding in stuff seems harder than removing it in my mind15:30
Davieyfletcher_: That is a risky approach IMO, as people will start off with a small test suite and just make it even smaller.15:30
tmcpeakprofiles actually support the ability to exclude: "oh I hate the x test" - boom: new profile, excluded15:31
DavieyOr are people turning up more knobs themselves with their own profiles ?15:31
tmcpeaknobody actually uses it currently, but it works15:31
tmcpeakDaviey: basically the profile the gates are using is based on Keystone, which we wrote and provided to them15:32
fletcher_I think this comes back to this tool being tied to OpenStack and that workflow versus making it useful to the Security community as a whole. If I'm random developer X, I want to check my Python code with Bandit, I run it and get a bunch of useless messages, I'm way less likely to use it in the future15:32
*** browne has quit IRC15:32
fletcher_i might be bikeshedding at this point :)15:33
tmcpeakfletcher_: yeah, although like I said I use it for pentesting as well15:33
tmcpeaksecurity engineer doing code review and gate test are our two main use cases, and we want to make it equally useful for both.  That is a major design goal15:34
Davieytmcpeak: How do you filter 'too much noise' from useful stuff?15:34
tmcpeakDaviey: in my use I just leave it all on.  False positives are trivial to spot, but sometimes they catch something interesting15:35
*** sdake has quit IRC15:35
tmcpeakI've actually seen the hardcoded password test find something good15:35
tmcpeakalthough it generates pure crap 95% + of the time15:35
Davieytmcpeak: you just grep / paginate through it?15:35
fletcher_In my opinion, false positives and fatigue are some of the most crucial pain points for tools like this. Ultimately leading to developers ignoring any warnings returned by the tool15:36
fletcher_if I'm running this on all commits to a repo, and it complains on almost everyone about things that aren't issues, it becomes problematic (not claiming Bandit is that noisey)15:36
tmcpeakfletcher_: that's why it's configurable though, if you think the x test sucks, create a profile that doesn't include it or removes it15:37
fletcher_and yes, I could tweak this and do different things, but that makes the barrier to entry pretty high to have something useful15:37
fletcher_whoops, simpatico :)15:37
tmcpeakwhat's crap for your use might be good for me though, or I might be willing to tolerate the false positives for the payout of getting that good issue15:37
fletcher_getting good issues and reporting high false positibves aren't related, imo15:37
fletcher_eliminating false positives, doesn't mean you will miss the good ones15:38
tmcpeakyeah, it pretty much does15:38
fletcher_how so?15:38
tmcpeakin any system if you tune the detection too specifically than you will get false negatives15:38
tmcpeakthat's kind of the age old tradeoff, isn't it?15:38
sigmavirus24fletcher_: so, I would have to say that this the default argument (would almost go so far as to say strawman) against *EVERY* linter15:39
fletcher_Sure, i agree with regards to 'too specifically'. But that's the balance we have to try and find15:39
fletcher_right now we're just erring on the side of now confidence or specificity15:39
tmcpeaksure so if we get better plugins, everything gets better15:39
tmcpeakI think the question is, how do we want to go ahead with what we have15:39
sigmavirus24Until we get those plugins, we should continue to use the hammer we have though15:40
fletcher_but allowing people to add anything to blacklist_calls doesn't move us towards that15:40
DavieySo i guess we need to document what knobs are available to users?  I mean, suggest starting off with just HIGH confidence issues.. and expand on to custom Profiles for needs?15:40
tmcpeakDaviey: sure, we can bundle some profiles too15:40
tmcpeak"SourceReview" and "Gate"15:40
tmcpeakas examples15:40
sigmavirus24So, gertty is another tool that's built buy the openstack community that wants to not just target the openstack community15:40
sigmavirus24They currently have a bunch of different example configs (openstack, plain gerrit, others)15:41
sigmavirus24We could do something similar and have the keystone one be an example, etc.15:41
fletcher_My vote: blacklist_calls should be a minimal list and we should work on getting most functions out of it (even if intially they are just like XML plug-in now, mimicing blacklist_call functionality). People should be able to easily extend this list for functionality.15:41
sigmavirus24My experience makes me lean the opposite way15:42
sigmavirus24People will not improve something unless it's really annoying to them15:42
sigmavirus24People are more inclined to scratch their own itches15:42
fletcher_people won't use it or pay attention to it if it's annoying15:42
sigmavirus24I disagree15:42
fletcher_that's my entire point15:42
tmcpeakso like I said, I'm a Bandit dev obviously, but I also use Bandit in both ways that I believe we care to support15:43
tmcpeakpentester and gate15:43
tmcpeakI'm not in favor of anything that makes either of those uses more difficult than it needs15:43
tmcpeakand it seems like bundling example profiles for both solves both uses15:43
fletcher_I agree, we should support both of those15:43
fletcher_I think this ignores the facts that the blacklist_calls are inherently inaccurate, and this doesn't do anything to solve that15:44
tmcpeakadditionally let's keep blacklist_calls because it's useful, but move it to a separate config so bandit.yaml doesn't get huge and projects don't constantly have to merge their changes in with new bandit.yaml15:44
tmcpeakfletcher_: tolerably so for some uses though15:44
DavieyMy first experience of Bandit was flood fatigue.. I had NFI how i'd even start to use it on real code that was't written from the start being tested against Bandit.15:44
fletcher_We can probably curb this discussion until we meet up in seattle if you want tho, and obviously, I'm not a blocking vote anyways :)15:44
tmcpeakand to be clear, they aren't inaccurate, they're completely accurate.  It just doesn't mean anything in some cases15:44
fletcher_a confidence of HIGH is inaccurate when it doesn't mean anything15:45
fletcher_by definition15:45
fletcher_maybe that's just a matter of tweaking the way we report blacklist_calls though15:45
tmcpeak"we're 100% sure that you are calling this function" it's severity that doesn't mean anything15:45
fletcher_Ah, you're right, I got those flopped15:46
tmcpeakok so to summarize - here's where we are:15:46
tmcpeak1) we're in debate about usefulness about blacklist_calls but we're going to leave it for now.  Fletcher, I and anybody else that wants to will go out for beers one night in Seattle and figure it out :P15:46
tmcpeak2) tests that don't implement any functionality beyond blacklist_calls should use that15:47
tmcpeak3) tests that do implement functionality beyond blacklist_calls should be in a function by themselves.  We will move them at the time that the functionality is extended15:47
*** elo has quit IRC15:47
tmcpeak4) config needs to be over-rideable, bandit.yaml is not the single source of config - blacklist_calls is an initial candidate for things that should be moved to a separate file15:48
tmcpeakfletcher_, Daviey, browne, sigmavirus24, tkelsey: everybody happy with 1-4?15:48
tmcpeakor "can live with it"15:48
fletcher_I disagree with #2 (as I'm sure everyone knows), but I can agree that seems to be the conesnsus15:48
* fletcher_ can live with it for now15:48
tmcpeakfair enough :)15:49
Davieytmcpeak: succulently summarised.. +415:49
fletcher_boom, good convo15:49
tmcpeakfletcher_: thanks for dropping in15:49
sigmavirus24Yeah I can live with it I think15:50
sigmavirus24tmcpeak: I'd rather be able to be part of the discussion though in Seattle even if remotely, so doing this over beers might not be the most productive =P15:50
Davieytmcpeak: So with this, do we consider tkelsey unblocked?15:50
tmcpeaksigmavirus24: ok cool we'll get you in conversation for sure15:51
tmcpeakDaviey: yeah, I believe so :)15:51
tmcpeakyeah cool, good stuff15:51
tmcpeakso buy in from browne, tkelsey and I think we're gtg15:51
* sigmavirus24 is also being pulled in 3 directions right now so please excuse the delayed responses15:52
tmcpeaksigmavirus24: cool, thanks for the time15:52
sigmavirus24tmcpeak: no problem15:55
tkelseyHeh, so my next meeting just got cancelled :) Im back15:59
tmcpeakjust in time :)15:59
tkelseyreading over the scrollback, seems like we got to a good place ?15:59
tkelseyI like you summation tmcpeak16:00
*** fletcher_ has quit IRC16:00
tkelseyfletcher_: I would be happy to work with you around point 2, if you have specific things you want to see16:00
tmcpeakfletcher has left the building16:00
tmcpeakwe'll figure it out in Seattle16:01
tmcpeakand bridge in sigmavirus24, Daviey etc for the discussion16:01
tkelseyok cool. Sorry I had to drop out before, 'murrica woke up :)16:01
tkelseythanks for continuing things in my abscence tmcpeak16:02
*** lexholden has quit IRC16:02
tmcpeaksure, sounds like we have a good way forward here16:02
sigmavirus24So Daviey my only concern that I have with merging/overriding config is that people are going to want something more than what we're going to offer16:03
sigmavirus24It's a thing I've seen in Flake8 that has broken things in the past16:03
sigmavirus24People have radically different ideas of how configs should be merged/overlayed/extended/etc and no one will be happy, so this will *always* be a problem16:04
sigmavirus24As soon as we start merging things, I think it'll be a bad time for us16:04
sigmavirus24Unless we come to a design decision early and stay firm on it unless something really enticing is proposed16:04
sigmavirus24(Which isn't exactly friendly seeming to new contributors, but at this point I'm worried more about not getting stuck in the hell that is the extents to which configuration management can be stretched in lint/analysis tooling)16:05
Davieysigmavirus24: Yeah, i think we'd need a spec for it TBH16:07
sigmavirus24Put it like this, people (I won't name names) wanted Flake8 to look at some global config, then their personal config, then the project config and then subproject configs16:08
sigmavirus24The order of operations there might seem natural that each level closer to the project overrides the previous but they wanted the project config to override the subproject config16:08
tmcpeakDaviey, sigmavirus24: yes, this is a perfect use for a spec16:10
*** shohel has quit IRC16:11
sigmavirus24I think we should discuss exactly how far we want to actually go with configuration of bandit and its behaviour16:12
Davieysigmavirus24: Yeah, good point.  Nobody will ever be happy :)16:12
sigmavirus24Some people will want to just remove something from blacklist calls which in their personal config would mean copying everything but16:13
sigmavirus24Which means then when we add new things that they want, they need to be aware of that and copy those too16:13
sigmavirus24(if they want them)16:13
sigmavirus24The way to make that not be a problem would be to allow them to blacklist blacklist_calls16:13
sigmavirus24Which then becomes a really bad headache16:13
Davieyhah, i was about to say that.  Sounds wrong!16:14
sigmavirus24Which lends more credibility to fletcher's argument that blacklist_calls is bad, although in a different direction (configurability rather than accuracy)16:14
*** rmarathu has quit IRC16:15
tmcpeakwell no, I think they don't have to copy everything but16:16
tmcpeakI think we're talking about moving blacklist calls to its own config for starter16:16
tmcpeakso if they want to remove something, they just go remove it16:16
tmcpeakcomment it out, etc16:16
sigmavirus24So having per-plugin config files?16:17
sigmavirus24That might be ... interesting16:17
Davieytmcpeak: Are you saying, cp $stockconfig $myconfig ; sed 's/somethingihate//' $myconfig ?16:17
*** Windir has quit IRC16:20
*** alex_klimov has quit IRC16:20
Davieytmcpeak: Also, is that hardcoded password issue you found on an open source project?16:20
*** sdake has joined #openstack-security16:22
*** Windir has joined #openstack-security16:22
tmcpeakDaviey: yeah, pretty much that16:23
Davieytmcpeak: With that model, will people bother pulling in a new config getting latest goodness?16:23
*** rmarathu has joined #openstack-security16:23
*** browne has joined #openstack-security16:25
tmcpeakDaviey: most interesting bug wasn't in open source, but there's also this: https://bugs.launchpad.net/nova/+bug/142045716:25
openstackLaunchpad bug 1420457 in OpenStack Compute (nova) "Insecurely generated session ID in vpn_ping()" [Low,Fix released] - Assigned to Tony Breeds (o-tony)16:25
tmcpeakDaviey: maybe, they should, but if they don't that's kind of on them16:25
tmcpeaksome people intentionally don't adopt new flake8 plugins too16:26
tmcpeakworkflow could be as easy as "get new profiles" go back and comment the ones I don't like16:26
tmcpeak20 seconds of effort16:26
DavieyThat does go someway of reducing complexity16:28
tmcpeakyeah, shouldn't be too bad16:29
sigmavirus24tmcpeak: so re flake8 plugins: there are lots of 3rd party ones16:36
sigmavirus24No one pulls those in by default16:36
sigmavirus24Further, Hacking is now taking advantage of Flake8's ability to have checks off by default16:36
tmcpeaksigmavirus24: it seems like even stock ones though people are constantly disabling some16:36
sigmavirus24Although that needs a bit more work in Flake8 to allow them to be enabled16:37
sigmavirus24tmcpeak: right, that's actively disabling rather than not pulling in new ones ;)16:37
sigmavirus24the language confused me16:37
sigmavirus24carry on16:37
tmcpeakoh right, we might be saying the same thing16:37
sigmavirus24different language, same idea16:37
tmcpeakI'm saying workflow is disable some, then at some point "give me all the new bandit" which drops new configs and then you can go and copy over your disabling16:38
sigmavirus24ignore= in Flake8 land16:38
sigmavirus24and that would work well if browne's idea of having static codes assigned to checks is something we want16:48
sigmavirus24then you can just say ignore=XML100124 =P16:48
* sigmavirus24 is making up codes and names for the same of illustration16:48
brownesigmavirus24: +116:52
openstackgerritMerged openstack/anchor: Check for exception code and not type  https://review.openstack.org/20625716:53
tmcpeakfor sure, that seems to tie in nicely16:57
*** dwyde has quit IRC17:00
*** elo has joined #openstack-security17:04
*** tkelsey has quit IRC17:22
*** dwyde has joined #openstack-security17:27
*** nkinder has quit IRC17:32
*** markvoelker has quit IRC17:47
*** jmckind has quit IRC17:55
*** jmckind has joined #openstack-security17:59
*** nkinder has joined #openstack-security18:01
*** b10n1k has joined #openstack-security18:14
*** singleth_ has joined #openstack-security18:20
*** singlethink has quit IRC18:23
*** markvoelker has joined #openstack-security18:42
*** markvoelker_ has joined #openstack-security18:46
*** markvoelker has quit IRC18:48
*** singlethink has joined #openstack-security19:08
*** voodookid has joined #openstack-security19:09
*** singleth_ has quit IRC19:11
*** markvoelker_ has quit IRC19:29
*** singleth_ has joined #openstack-security19:29
*** singlet__ has joined #openstack-security19:31
*** singlethink has quit IRC19:32
*** singleth_ has quit IRC19:34
*** elo1 has joined #openstack-security19:55
*** elo has quit IRC19:57
*** b10n1k has quit IRC20:01
*** b10n1k has joined #openstack-security20:02
*** alex_klimov has joined #openstack-security20:18
*** y_sawai has joined #openstack-security20:21
*** dwyde has quit IRC20:30
*** salv-orlando has joined #openstack-security20:31
*** salv-orl_ has quit IRC20:34
*** lexholden has joined #openstack-security20:39
*** tkelsey has joined #openstack-security21:11
*** dwyde has joined #openstack-security21:12
*** tkelsey has quit IRC21:16
*** y_sawai has quit IRC21:18
*** bknudson has quit IRC21:59
*** bpokorny_ has joined #openstack-security22:01
*** bpokorny has quit IRC22:04
*** bpokorny_ has quit IRC22:04
*** bpokorny has joined #openstack-security22:04
*** dwyde has quit IRC22:07
*** dwyde has joined #openstack-security22:16
*** jmckind has quit IRC22:18
openstackgerritDarren Chan proposed openstack/security-doc: Renamed Future section and added domain information  https://review.openstack.org/19939322:28
*** bpokorny has quit IRC22:29
*** bpokorny has joined #openstack-security22:29
*** singlet__ has quit IRC22:40
*** dwyde has quit IRC22:41
*** alex_klimov has quit IRC22:43
*** elo has joined #openstack-security22:48
*** elo1 has quit IRC22:52
*** bpokorny has quit IRC22:52
*** bpokorny has joined #openstack-security22:53
*** viraptor has joined #openstack-security23:02
*** voodookid has quit IRC23:06
*** edmondsw has quit IRC23:07
*** sigmavirus24 is now known as sigmavirus24_awa23:07
*** maikol1 has joined #openstack-security23:11
maikol1quien para hablar23:12
*** dave-mccowan has quit IRC23:14
*** maikol1 has left #openstack-security23:15
openstackgerritDave Walker proposed openstack/anchor: [WIP] Initial commit of devstack plugin  https://review.openstack.org/20626423:18
Davieyviraptor: Upstream pecan worked on the non-determinsitic 500 issue today.. but working around it still makes sense i think (to support older versions) - https://github.com/ryanpetrello/pecan/commit/f52d3b4fe2aca0a09fb313e60dcd63ee0a1c88e023:22
DavieyBut it was good to see they validated that it was a bug in pecan, not our stuff.23:22
viraptorI was just going to send you the link :)23:22
viraptoryeah, yesterday on a call we decided to accept the patch as it is to unbreak the CI, but I'll try to make a nicer version today23:23
viraptorwhen global requirements move past this patch in pecan, we could drop our version23:24
DavieyYeah, that is true23:25
Davieyviraptor: what do you want to improve about the patch?23:25
viraptormaybe make it a bit closer to what pecan does - actually raise the right exception every time for consistency, instead of using .abort()23:27
viraptorI like the idea of tests working explicitly on the right exception as they did before23:27
Davieyviraptor: meh, I prefer using object wrappers aswell for the application itself.. but standardising on error code in tests feels reasonable to me.23:30
*** elo1 has joined #openstack-security23:36
*** jmckind has joined #openstack-security23:37
*** elo has quit IRC23:38
*** salv-orlando has quit IRC23:52
*** sdake has quit IRC23:56

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!