| *** markvoelker has joined #openstack-security | 00:01 | |
| *** markvoelker has quit IRC | 00:05 | |
| *** salv-orlando has joined #openstack-security | 01:06 | |
| *** salv-orlando has quit IRC | 01:11 | |
| *** browne has joined #openstack-security | 01:16 | |
| *** markvoelker has joined #openstack-security | 01:50 | |
| *** markvoelker has quit IRC | 01:55 | |
| *** sdake_ has quit IRC | 03:10 | |
| *** salv-orlando has joined #openstack-security | 03:19 | |
| *** salv-orlando has quit IRC | 03:22 | |
| *** markvoelker has joined #openstack-security | 03:38 | |
| *** markvoelker has quit IRC | 03:43 | |
| *** electrichead has quit IRC | 03:59 | |
| *** sdake has joined #openstack-security | 04:04 | |
| *** redrobot has joined #openstack-security | 04:16 | |
| *** redrobot is now known as Guest47789 | 04:16 | |
| *** Guest47789 has quit IRC | 04:28 | |
| *** salv-orlando has joined #openstack-security | 05:02 | |
| *** salv-orlando has quit IRC | 05:13 | |
| *** markvoelker has joined #openstack-security | 05:27 | |
| *** markvoelker has quit IRC | 05:32 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/security-doc: Imported Translations from Transifex https://review.openstack.org/193944 | 06:01 |
|---|---|---|
| openstackgerrit | Merged openstack/security-doc: Imported Translations from Transifex https://review.openstack.org/193944 | 06:14 |
| *** JAHoagie has joined #openstack-security | 06:18 | |
| *** browne has quit IRC | 06:19 | |
| *** JAHoagie has quit IRC | 06:42 | |
| *** salv-orlando has joined #openstack-security | 07:10 | |
| *** salv-orlando has quit IRC | 07:13 | |
| *** markvoelker has joined #openstack-security | 07:16 | |
| *** salv-orlando has joined #openstack-security | 07:17 | |
| *** markvoelker has quit IRC | 07:21 | |
| *** alex_klimov has joined #openstack-security | 08:20 | |
| *** alex_klimov has quit IRC | 08:51 | |
| *** marzif has joined #openstack-security | 08:56 | |
| openstackgerrit | Merged stackforge/anchor: Ignore the coverage file https://review.openstack.org/188289 | 08:58 |
| openstackgerrit | Merged stackforge/anchor: Fix entry typo https://review.openstack.org/188252 | 09:04 |
| *** markvoelker has joined #openstack-security | 09:05 | |
| *** markvoelker has quit IRC | 09:09 | |
| openstackgerrit | Merged stackforge/anchor: Handle omission of CN on CSR https://review.openstack.org/191899 | 09:11 |
| *** jamielennox is now known as jamielennox|away | 10:25 | |
| openstackgerrit | Stanislaw Pitucha proposed stackforge/anchor: Explicit long is not needed https://review.openstack.org/190892 | 10:27 |
| openstackgerrit | Stanislaw Pitucha proposed stackforge/anchor: Force absolute imports rather than relative ones https://review.openstack.org/190877 | 10:27 |
| openstackgerrit | Stanislaw Pitucha proposed stackforge/anchor: Add explicit decoding to asn1 data https://review.openstack.org/190890 | 10:27 |
| openstackgerrit | Merged stackforge/anchor: Fixed a typo in X509/certificate.py https://review.openstack.org/184608 | 10:40 |
| *** sdake has quit IRC | 10:43 | |
| *** kenj0 has quit IRC | 10:43 | |
| *** sigmavirus24_awa has quit IRC | 10:43 | |
| *** Guest11697 has quit IRC | 10:43 | |
| *** v4s has joined #openstack-security | 10:43 | |
| *** mgagne has joined #openstack-security | 10:43 | |
| *** mgagne is now known as Guest81202 | 10:43 | |
| *** sdake has joined #openstack-security | 10:44 | |
| *** sigmavirus24_awa has joined #openstack-security | 10:46 | |
| *** markvoelker has joined #openstack-security | 10:53 | |
| *** markvoelker has quit IRC | 10:58 | |
| *** daemontool_ has joined #openstack-security | 11:16 | |
| *** marzif has quit IRC | 11:18 | |
| *** alex_klimov has joined #openstack-security | 11:21 | |
| *** sdake_ has joined #openstack-security | 11:27 | |
| *** sdake has quit IRC | 11:30 | |
| openstackgerrit | Merged stackforge/anchor: Refactor the alternative name iteration code https://review.openstack.org/188279 | 11:34 |
| *** daemontool_ has quit IRC | 11:38 | |
| *** marzif has joined #openstack-security | 11:39 | |
| *** markvoelker has joined #openstack-security | 11:54 | |
| *** markvoelker has quit IRC | 11:59 | |
| *** markvoelker has joined #openstack-security | 12:03 | |
| openstackgerrit | Merged stackforge/anchor: CA doesn't need to be read-only https://review.openstack.org/189662 | 12:10 |
| *** edmondsw has joined #openstack-security | 12:22 | |
| openstackgerrit | Merged stackforge/anchor: Add blacklist validator https://review.openstack.org/188280 | 12:31 |
| *** dave-mccowan has joined #openstack-security | 13:02 | |
| *** singlethink has joined #openstack-security | 13:33 | |
| *** singleth_ has joined #openstack-security | 13:45 | |
| *** tmcpeak has joined #openstack-security | 13:48 | |
| *** singlethink has quit IRC | 13:49 | |
| openstackgerrit | Merged openstack/security-doc: Case Studies - Moving Identity case studies into Identity chapter https://review.openstack.org/192877 | 13:50 |
| *** localloop127 has joined #openstack-security | 14:08 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:12 | |
| *** nkinder has joined #openstack-security | 14:31 | |
| *** redrobot has joined #openstack-security | 14:51 | |
| *** redrobot is now known as Guest44405 | 14:51 | |
| *** jebertol has joined #openstack-security | 14:52 | |
| *** sdake_ has quit IRC | 14:52 | |
| *** jebertol has quit IRC | 14:53 | |
| *** browne has joined #openstack-security | 14:53 | |
| *** Guest44405 is now known as redrobot | 14:53 | |
| *** marzif has quit IRC | 14:55 | |
| *** jian5397 has joined #openstack-security | 14:57 | |
| *** dave-mccowan has quit IRC | 15:12 | |
| *** bpokorny has joined #openstack-security | 15:16 | |
| *** dave-mccowan has joined #openstack-security | 15:24 | |
| *** Guest81202 is now known as mgagne | 15:36 | |
| *** mgagne has joined #openstack-security | 15:36 | |
| *** salv-orl_ has joined #openstack-security | 16:00 | |
| *** salv-orlando has quit IRC | 16:03 | |
| openstackgerrit | Merged stackforge/bandit: Add extension entry-points and loading https://review.openstack.org/188997 | 16:08 |
| *** chair6_ is now known as chair6 | 16:12 | |
| *** jian5397 has quit IRC | 16:24 | |
| *** jian5397 has joined #openstack-security | 16:25 | |
| *** jian5397 has left #openstack-security | 16:26 | |
| *** jian5397 has joined #openstack-security | 16:27 | |
| tmcpeak | browne, chair6, sigmavirus24: we're looking at another pushed version now that sigmavirus24's changes have landed. If you have the chance in the next couple of days, could you run Bandit against some code and do a sanity check? please use bandit default profile as well as the profile being used in gates - https://github.com/openstack/keystone/blob/master/bandit.yaml | 16:29 |
| browne | tmcpeak: sure will do | 16:30 |
| tmcpeak | browne: thanks! | 16:30 |
| sigmavirus24 | So how many projects are using pyca/cryptography directly? | 16:42 |
| sigmavirus24 | I'm wondering if we want to add a plugin to check for less than ideal combinations of things in code using cryptography | 16:43 |
| *** sicarie has joined #openstack-security | 16:55 | |
| *** dg___ has joined #openstack-security | 16:57 | |
| elmiko | hey sicarie | 17:00 |
| sicarie | hello! | 17:00 |
| elmiko | how goes? | 17:00 |
| sicarie | pretty well, how was the conference? | 17:01 |
| elmiko | it was really good, very mind-blowing in some ways. just gave me too many good ideas =) | 17:01 |
| dg___ | which conference was that? | 17:02 |
| elmiko | spark summit | 17:02 |
| sicarie | awesome | 17:02 |
| *** shelleea007 has joined #openstack-security | 17:02 | |
| *** pdesai has joined #openstack-security | 17:03 | |
| elmiko | san fran was nice too, had awesome weather all week | 17:03 |
| elmiko | hey shelleea007, pdesai /me waves | 17:03 |
| pdesai | Hi everyone | 17:03 |
| sicarie | hello! | 17:04 |
| shelleea007 | hi | 17:05 |
| sicarie | Sorry about that, was handling internal fun | 17:05 |
| pdesai | :) | 17:05 |
| elmiko | np | 17:05 |
| sicarie | So we have one to traige today: https://bugs.launchpad.net/openstack-manuals/+bug/1467545 | 17:06 |
| openstack | Launchpad bug 1467545 in openstack-manuals "Security guide should contain an appendix with advice on configuring firewalls" [Undecided,New] | 17:06 |
| elmiko | i was figuring this might be wishlist | 17:06 |
| sicarie | elmiko: how do you feel about updating ‘firewalls’ to ‘security groups’? | 17:06 |
| elmiko | sure, that works | 17:06 |
| elmiko | i guess ultimately we could have advice on iptables, firewalld, and the ubuntu service (can't remember the name) | 17:07 |
| sicarie | So let me rephrase that | 17:07 |
| sicarie | Would this be more useful initially as a reference for networking security groups, or firewalls deployed in the environment? | 17:07 |
| elmiko | hmm | 17:07 |
| sicarie | ufw | 17:07 |
| sicarie | (the ubuntu one) | 17:08 |
| elmiko | i was initially thinking just firewalls, maybe a little distinction on security groups would help | 17:08 |
| sicarie | I think a security groups reference might be a bit more useful as firewalls are determined by the environment and deployer | 17:08 |
| elmiko | yea, ufw, thanks | 17:08 |
| elmiko | ok, so make it a little broaded to cover other cases too. i'm good with that. | 17:09 |
| elmiko | *broader | 17:09 |
| sicarie | pdesai dg__ shelleea007 do any of you feel strongly one way or another? | 17:09 |
| pdesai | 0 | 17:09 |
| shelleea007 | no | 17:09 |
| shelleea007 | but I do agree that it should be addressed at some level | 17:09 |
| sicarie | Or maybe we can even comment and suggest a security groups reference first to build into fw rules? | 17:10 |
| shelleea007 | but each entity will have to identify how to secure their own environment as applicable | 17:10 |
| elmiko | i changed the title slighty, s/firewalls/network security groups/ | 17:10 |
| sicarie | Sounds good | 17:10 |
| pdesai | +1 | 17:11 |
| elmiko | shelleea007: agreed, i figured this might address thing by linux distributions to begin with, for example "firewalld service files for fedora, centos and rhel. uwd configs for ubuntu. etc..." | 17:11 |
| dg___ | on the name - firewalls is more familiar to average reader, rather than security group, which is fairly openstack specific | 17:11 |
| shelleea007 | right | 17:12 |
| elmiko | dg___: kinda why i went with the more mundane term originally | 17:12 |
| sicarie | dg__ very true, but I would expect someone looking at an appendix reference to be fairly familiar with openstack terminology | 17:12 |
| dg___ | unless theyre just greping for 'how do i firewall stuff' | 17:12 |
| sicarie | true | 17:12 |
| dg___ | if they started at the beginning, sure, but when did you last read a tech book from the start? | 17:13 |
| elmiko | maybe the appendix could be titled something like "Appendix X, Network security group and firewall configurations"? | 17:13 |
| dg___ | +1 | 17:13 |
| sicarie | elmiko: +1 | 17:13 |
| pdesai | +1 | 17:13 |
| sicarie | dg__ it was the openstack security guide :P | 17:13 |
| sicarie | but that was because I was doing a cover-to-cover bug hunt | 17:14 |
| dg___ | sicarie hero! | 17:14 |
| sicarie | :D | 17:14 |
| sicarie | So I have one general question, and then want to hit the RST conversion | 17:14 |
| sicarie | So over the weekend this bug was opened: https://launchpad.net/bugs/1465037 | 17:14 |
| openstack | Launchpad bug 1465037 in openstack-manuals "Chapter 10. Case studies: Identity management in OpenStack Security Guide - current" [Medium,Invalid] | 17:14 |
| sicarie | It wasn’t tagged sec-guide so I missed it, there is a currently open bug tagged sec-guide that I’ve been working for the last few months to get the case studies in better shape | 17:15 |
| sicarie | That spawned a patch set as well: https://review.openstack.org/#/c/193864/ | 17:15 |
| elmiko | sicarie: i merged yours earlier and commented on that one | 17:15 |
| sicarie | So my general question for anyone who may know: is there a way other than tags to search where a bug came from so I can do a regular search for non-tagged but still secguide bugs? | 17:16 |
| sicarie | elmiko: I saw that :\ | 17:16 |
| sicarie | just amazing timing on the new bug/patchset | 17:16 |
| elmiko | yea | 17:16 |
| elmiko | good question about the bugs, i'm not immediately sure about that | 17:17 |
| sicarie | Okay, no worries, just thought I’d throw it out there | 17:17 |
| sicarie | so the RST migration: https://bugs.launchpad.net/openstack-manuals/+bug/1463111 | 17:17 |
| openstack | Launchpad bug 1463111 in openstack-manuals "OpenStack Security Guide - Convert to RST format" [High,Triaged] | 17:17 |
| pdesai | sicarie, you can go first, i have few comments as well | 17:18 |
| *** sdake_ has joined #openstack-security | 17:18 | |
| sicarie | pdesai: sure | 17:18 |
| sicarie | So after a bit of discussion i think we’re going to do a sec-specs repo | 17:18 |
| elmiko | nice | 17:18 |
| sicarie | and with that I’ll let pdesai take it away, as she’s been doing good work to structure this in the etherpad | 17:19 |
| sicarie | https://etherpad.openstack.org/p/sec-guide-rst | 17:19 |
| pdesai | sure, i have gone through the migration guide lines from here: https://wiki.openstack.org/wiki/Documentation/Migrate | 17:19 |
| pdesai | i have outlined the new dir structure on the etherpad | 17:20 |
| pdesai | security-guide-rst will have all the source files *.rst under security-guide-rst/source | 17:21 |
| sicarie | +1 looks good | 17:21 |
| pdesai | we convert each ch_ and section_ file to *.rst | 17:21 |
| elmiko | pdesai: awesome, +1 | 17:22 |
| pdesai | thanks :) my question is, its recommended that we merge ch_ and their section_ files into one rst file, (does not apply for all though), what are your thoughts? | 17:23 |
| sicarie | Ah, good question | 17:23 |
| pdesai | we have today 100 files including ch_ and section_ | 17:23 |
| elmiko | hmm | 17:23 |
| elmiko | could make for some large rst files | 17:23 |
| sicarie | yeah, i was thinking that was becoming unwiedly | 17:23 |
| elmiko | i don't necessarily have a problem with that, just as long as we accept that reality | 17:23 |
| sicarie | Yeah, it’s either going to be lots of files when doing an ls or a large file being edited (possibly multiple times) | 17:24 |
| pdesai | we can merge files, if its a moderate size rst file, instead of applying this rule for all the files | 17:24 |
| sicarie | So what I’d like to avoid would be a large set of “patch in merge conflict” submissions | 17:24 |
| elmiko | if we break them apart we will most likely need subdirs and then toc files to organize everything, that might be more unwieldly | 17:25 |
| pdesai | we can create a subdir for each chapter to store their section files, or have a flat dir and store everything under source/ | 17:25 |
| elmiko | yea, i was kinda thinking subdir for each chapter (if we break apart the files) | 17:26 |
| *** Vivek_ has joined #openstack-security | 17:26 | |
| elmiko | might be nice to do regardless | 17:26 |
| pdesai | +1 to subdir for each ch. | 17:26 |
| elmiko | no objection from me | 17:27 |
| sicarie | So let’s submit the bp with that arch as a goal, and we’ll invite the docs team to comment | 17:27 |
| elmiko | +1 | 17:27 |
| sicarie | If they have a very persuasive argument we can modify our approach | 17:27 |
| elmiko | yea | 17:27 |
| sicarie | but I do think that’s probably the most reasonable path right now | 17:27 |
| pdesai | awesome, i will create a repo for sec-specs and add my first bp :) | 17:28 |
| sicarie | sweet! | 17:28 |
| Vivek_ | I am new to the OpenStack Security Project. | 17:28 |
| sicarie | Thanks pdesai! | 17:28 |
| *** Vivek_ is now known as Vivek | 17:28 | |
| pdesai | sure | 17:28 |
| elmiko | what are we looking at for a time frame on this? (i'm curious about starting the appendix, if it should be xml or rst) | 17:28 |
| *** Vivek is now known as Guest50031 | 17:28 | |
| tmcpeak | Vivek: how's it going? these guys are having a meeting here, but feel free to PM me or drop a message in here when they're done | 17:29 |
| sicarie | elmiko: good question, I’d prefer to get it done as quickly as possible | 17:29 |
| elmiko | sicarie: ok, i'll wait on the appendix until we are finished with rst. | 17:29 |
| sicarie | I was just going to say I think we should freeze submissions once we start the conversion | 17:29 |
| elmiko | Guest50031: hi, yea what tmcpeak said. we are currently discussing the openstack security guide =) | 17:29 |
| sicarie | but until then I’m going to be pushing new content to case studies and compute :) | 17:29 |
| elmiko | sounds good | 17:30 |
| *** alex_klimov has quit IRC | 17:30 | |
| sicarie | awesome, thanks everyone! | 17:30 |
| pdesai | thanks | 17:30 |
| elmiko | i guess we will have a small window of time where we need to ensure that the new changes and the rst are the same | 17:30 |
| elmiko | cool, thanks! | 17:30 |
| sicarie | yeah | 17:30 |
| Guest50031 | Sure I am the co-author of the OpenStack Beginner's Guide Essex Release,always happy to help out with documentation. | 17:30 |
| sicarie | elmiko: exactly | 17:30 |
| pdesai | yeah we will have to be careful there | 17:30 |
| Guest50031 | Pleae carry on with your meeting.I'll be here. | 17:30 |
| sicarie | Guest50031: we just finished :) | 17:31 |
| *** Guest50031 is now known as Vivek_V_C | 17:31 | |
| tmcpeak | Vivek_V_C - these are the guys you want to talk to if you're interested in documentation | 17:31 |
| elmiko | Vivek_V_C: awesome to hear =) | 17:31 |
| Vivek_V_C | Sure, more about myself, I am a Technical Architect with Tech Mahindra in Chennai India. | 17:32 |
| Vivek_V_C | I use OpenStack daily for fun and for profit :) | 17:33 |
| elmiko | hehe | 17:33 |
| *** dg___ has quit IRC | 17:33 | |
| Vivek_V_C | I am trying to implement a poc on openstack hardening it will be with RH OpenStack Juno. | 17:34 |
| *** Vivek_V_C is now known as Vivek | 17:35 | |
| *** Vivek has quit IRC | 17:35 | |
| *** Vivek has joined #openstack-security | 17:35 | |
| tmcpeak | Vivek: hardening how? | 17:35 |
| Vivek | Well, I am supposed to follow the openstack security guide right ?. RH is our partners and they have the Standard Operating Environment (SOE) which they claim they implement using CloudForms. Data at Rest encryption - (FIPS 140), Data in Motion (AIDE), Authentication tools (Two-factor, IDM, Certificate system), Certifications (Common Criteria, EAL4+) | 17:39 |
| Vivek | s/is/are | 17:39 |
| tmcpeak | ahh cool | 17:39 |
| Vivek | I am not sure if they are giving marketing jargon but I also just wanted to cross check here. | 17:40 |
| elmiko | sounds neat | 17:40 |
| Vivek | elmiko,sicarie: Nice meeting you. | 17:41 |
| tmcpeak | Vivek: some of the people here work for RedHat, they might know more than me | 17:41 |
| elmiko | <-- works for red hat | 17:41 |
| Vivek | I see. | 17:41 |
| elmiko | but i'm not involved directly with the effort you are talking about | 17:41 |
| Vivek | How do I start with Openstack security, the security guide ? | 17:42 |
| Vivek | Also are there any RH specific hardening docs ? | 17:42 |
| elmiko | sec. guide is a great place to start | 17:43 |
| misc | i guess like anything, first start to see what you want to protect, what would be the thread, and then how you can remedy and/or prevent and/or reduce | 17:43 |
| Vivek | elmiko: ok. | 17:43 |
| Vivek | I'll start with the guide then. | 17:43 |
| elmiko | Vivek: there are also some red hat installation guides, i'm not sure about security hardening though. i'd have to look into it, maybe misc knows? | 17:44 |
| sicarie | Vivek: if you run into any issues with the guide, please ping in here - I’m very interested to see how the security guide looks to a new user | 17:44 |
| misc | nope dunno about guides | 17:44 |
| Vivek | sicarie: I am not a new user, been using OpenStack since Essex, new to the security side though. | 17:45 |
| misc | but I think I would likely have a unconventionnal approach of deploying openstack by hand to see how it goes, then start to be fedup and look for a guide :) | 17:45 |
| elmiko | lol | 17:45 |
| sicarie | Vivek: apologies, a new security implementor :) | 17:46 |
| Vivek | misc: I have already done that manually many times :) | 17:46 |
| *** pdesai has quit IRC | 17:46 | |
| Vivek | I will have a phd in manual openstack deployment. | 17:46 |
| elmiko | nice | 17:46 |
| Vivek | tmcpeak,elmiko,sicarie: Are you all core members of the security team ? | 17:47 |
| sicarie | Vivek: they are | 17:47 |
| sicarie | I’m security-guide specific | 17:47 |
| Vivek | awesome. | 17:48 |
| Vivek | Travis,Mike and Nathaniel: Nice to meet you guys. | 17:49 |
| Vivek | I am Vivek Cherian. | 17:50 |
| elmiko | nice to meet you as well =) | 17:50 |
| sicarie | Vivek: nice to meet you too! | 17:50 |
| Vivek | Is the openstack security mailing list active, I sent mail to join the list a few mins back. | 17:53 |
| elmiko | Vivek: that list mainly has automated emails about security review tagged issues. | 17:53 |
| Vivek | Where does all the actual discussion happen ? | 17:54 |
| elmiko | if you are looking for developer related issues you can post to the openstack-dev mailing list with the subject "[security] <topic....>" | 17:54 |
| Vivek | Ok. | 17:54 |
| elmiko | also, see https://security.openstack.org/ for our public facing side | 17:54 |
| Vivek | Ok. | 17:56 |
| elmiko | and for our meetings, see http://eavesdrop.openstack.org/#Security_meeting | 17:56 |
| elmiko | the wiki has some info too (it's linked on security.openstack.org) | 17:56 |
| Vivek | Ok. | 17:56 |
| elmiko | also, don't get me wrong about the openstack-security ML. there are conversations on that as well, it just mostly gets traffic from automated postings. | 17:57 |
| Vivek | But I am wondering why I am not getting a acknowledgement for my join request. | 17:59 |
| elmiko | huh, strange | 17:59 |
| *** salv-orl_ has quit IRC | 18:07 | |
| *** browne has quit IRC | 18:13 | |
| *** browne has joined #openstack-security | 18:13 | |
| Vivek | elmiko: I just got subscribed. | 18:17 |
| *** jian5397 has quit IRC | 18:18 | |
| elmiko | Vivek: great! | 18:18 |
| Vivek | But, I have to leave now. It's late here in India. | 18:18 |
| Vivek | Bye for now. | 18:19 |
| elmiko | take care | 18:21 |
| elmiko | sigmavirus24: ping | 18:24 |
| sigmavirus24 | elmiko: pong | 18:24 |
| elmiko | hey, i'm looking at a security bug and i want to do the backports to kilo/juno | 18:24 |
| elmiko | how do i add those branches as bugs on the original bug report? | 18:24 |
| elmiko | (in launchpad) | 18:24 |
| sigmavirus24 | At the top where it says what project it affects with the status and severity, it should say (beneath that table) "Nominate to series" | 18:25 |
| sigmavirus24 | I think you might need to be a member of the bug team for the project though | 18:25 |
| elmiko | ahh, ok | 18:25 |
| elmiko | i should get them to nominate before i do the review, or does it matter? | 18:26 |
| *** shelleea007 has quit IRC | 18:26 | |
| tmcpeak | good times :\ Bandit bug- https://bugs.launchpad.net/bandit/+bug/1467636 | 18:38 |
| openstack | Launchpad bug 1467636 in Bandit "Incorrect line number in results" [High,New] | 18:38 |
| sigmavirus24 | elmiko: so the nomination has to be accepted | 18:39 |
| sigmavirus24 | elmiko: for what it's worth, I would do it, jeepyb can handle itself | 18:39 |
| sigmavirus24 | tmcpeak: so that's something pep8 had a problem with a while back | 18:39 |
| sigmavirus24 | I think there's a distinguishment in pep8 between "logical line" and "physical line" or something like that | 18:40 |
| * sigmavirus24 goes to look | 18:40 | |
| elmiko | sigmavirus24: ok, thanks for the help, i just went ahead and made the reviews | 18:40 |
| tmcpeak | sigmavirus24: ahh, interesting | 18:40 |
| sigmavirus24 | oh wait, that's right | 18:41 |
| sigmavirus24 | lol | 18:41 |
| tmcpeak | sigmavirus24: I think I'm going to dig in unless you've pre-computed the answer for this already | 18:41 |
| sigmavirus24 | pep8 doesn't use the AST | 18:41 |
| tmcpeak | oh | 18:41 |
| sigmavirus24 | tmcpeak: I haven't | 18:41 |
| tmcpeak | ok cool | 18:41 |
| sigmavirus24 | pep8 uses a tokenizer | 18:41 |
| * tmcpeak cracks knuckles - debug time | 18:41 | |
| * sigmavirus24 's brain is scrambled lately | 18:42 | |
| tmcpeak | :D | 18:42 |
| sigmavirus24 | if you want another hard one: https://github.com/jcrocholl/pep8/issues/408 | 18:45 |
| tmcpeak | sigmavirus24: that's fun | 18:53 |
| sigmavirus24 | yeah | 18:53 |
| sigmavirus24 | Further if you do foo(\n\t"string"),\n it works just fine | 18:54 |
| sigmavirus24 | SUPER WEIRD | 18:54 |
| * sigmavirus24 really wishes he was able to not need sleep | 18:54 | |
| elmiko | lol | 18:57 |
| elmiko | that sounds like something out of an episode of the Twilight Zone | 18:57 |
| * sigmavirus24 has lots of bugs he'd like to fix | 18:57 | |
| sigmavirus24 | elmiko: what does? | 18:58 |
| elmiko | "sigmavirus24: really wishes he was able to not need sleep" | 18:58 |
| sigmavirus24 | lol | 18:58 |
| sigmavirus24 | Sorry, but sleep should be optional | 18:58 |
| elmiko | makes me think of a re-envisioning of the classic "Time Enough at Last" with Burgess Meredith, except instead of wanting to read books he finally has time to fix all the open source bugs... lol | 18:59 |
| bknudson | sleep isn't needed, use events and callbacks instead. | 18:59 |
| elmiko | bknudson: LOL | 18:59 |
| *** salv-orlando has joined #openstack-security | 18:59 | |
| tmcpeak | bknudson: +1 :) | 19:02 |
| tmcpeak | bknudson: we're going to have to find a way to automatically suggest updates to the Bandit profiles in projects | 19:03 |
| tmcpeak | I've got a new Parakmiko call plugin that might be useful | 19:03 |
| tmcpeak | would be cool if we had some way to automatically make pull requests in the relevant projects or something | 19:03 |
| bknudson | the openstack proposal bot does it for requirements, so should be easy | 19:04 |
| bknudson | why does it need to be automatic? | 19:04 |
| tmcpeak | cool, maybe I'll take a look at how they're doing it | 19:04 |
| *** salv-orlando has quit IRC | 19:04 | |
| bknudson | tmcpeak: here's an example script: http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/propose_update.sh | 19:05 |
| bknudson | I'd suggest writing the script yourself and then if it's working for you get it into -infra | 19:05 |
| tmcpeak | bknudson: cool yeah, sounds like a solid approach | 19:07 |
| bknudson | what updates are needed? | 19:07 |
| tmcpeak | so we added this paramiko shell injection plugin | 19:07 |
| bknudson | I've been meaning to go through the keystone one to see if it actually makes sense | 19:07 |
| tmcpeak | one sec, I'll get a link | 19:07 |
| bknudson | the way this works with pep8 is that all the projects eventually enable all the checks | 19:08 |
| tmcpeak | bknudson: https://github.com/stackforge/bandit/blob/master/bandit/config/bandit.yaml#L79 | 19:08 |
| bknudson | there's probably some projects that have never been updated with some checks. | 19:08 |
| tmcpeak | oh, pep8 you mean? | 19:09 |
| tmcpeak | with Bandit I doubt it, I think you guys are our oldest customers | 19:09 |
| bknudson | y, there's probably a project out there that ignores some pep8 checks because they've been too lazy to update. | 19:09 |
| tmcpeak | hah, yeah, and some projects explicitly disabling some checks ;) | 19:09 |
| bknudson | a script to update all the bandit.yaml to add paramiko_injection would be pretty handy. | 19:10 |
| tmcpeak | for sure, approach I was thinking was to have a list of projects, automatically clone them, add the new stuff based on templates, and then submit reviews | 19:11 |
| bknudson | you might even put it in stackforge/bandit/tools/ | 19:11 |
| tmcpeak | yeah, it's a decent little chunk of work, but I think we'll need something like that | 19:12 |
| tmcpeak | browne was talking about something like this too | 19:12 |
| bknudson | browne patched the keystone bandit.yaml since there was something wrong with a plugin name | 19:12 |
| tmcpeak | right, yeah I did see that | 19:13 |
| bknudson | if somebody's using paramiko then your update will fail and you'll have to fix that. | 19:13 |
| bknudson | using paramiko incorrectly | 19:13 |
| tmcpeak | yeah, that's another question, at some point we discussed testing new plugins against projects automatically, and then reporting the findings | 19:15 |
| tmcpeak | to make sure we don't 0 day anybody | 19:15 |
| tmcpeak | "0 day" | 19:15 |
| tmcpeak | but we never got there | 19:15 |
| bknudson | your script could go through an tox -e bandit every project, too | 19:15 |
| bknudson | and only update if it passed. | 19:15 |
| bknudson | nobody would be suspicious | 19:15 |
| tmcpeak | true… another question is how to determine what the project has named their profile | 19:16 |
| bknudson | hackers are probably running bandit already | 19:16 |
| tmcpeak | yeah, I was never super concerned about the 0-day argument | 19:16 |
| tmcpeak | but some people might feel that way | 19:16 |
| bknudson | if somebody's not naming their profile bandit.yaml then change it | 19:16 |
| tmcpeak | that's the config file, but I mean the actual profile name | 19:16 |
| bknudson | maybe we should have a standard name for the profile | 19:17 |
| tmcpeak | yeah, that's what I was thinking… x_conserative and x_verbose | 19:17 |
| tmcpeak | where x is the name of your project? | 19:17 |
| bknudson | why do we have conservative and verbose? | 19:18 |
| tmcpeak | then we just document that if you want your project to have changes submitted automatically for it you should keep those names ;) | 19:18 |
| bknudson | also, don't need the x_, do we? | 19:18 |
| tmcpeak | yeah, probably not | 19:18 |
| tmcpeak | err | 19:18 |
| tmcpeak | certainly not | 19:18 |
| tmcpeak | the idea behind conservative and verbose was that verbose would find more things, but projects that are in deeper could use conservative | 19:19 |
| bknudson | I think we should tailor the bandit.yaml for the automatic runs. | 19:19 |
| bknudson | if somebody wants to run it themselves for fun they can change bandit.yaml | 19:20 |
| tmcpeak | well we can at least have profiles geared for that | 19:20 |
| tmcpeak | we can actually have profiles for both | 19:20 |
| tmcpeak | can live happily together inside the bandit.yaml file | 19:20 |
| tmcpeak | we could just call the gate profile "gate" | 19:20 |
| bknudson | I like that. descriptive. | 19:20 |
| sigmavirus24 | why not "Hey Egon, here's your mucus" | 19:24 |
| *** sicarie has quit IRC | 19:29 | |
| tmcpeak | sigmavirus24: sounds like a solid second choice | 19:35 |
| tmcpeak | Bandit seems to just mark the first line for a multiline string... | 19:36 |
| sigmavirus24 | tmcpeak: link to that part of the code? | 19:36 |
| tmcpeak | sigmavirus24: well I just ran debugger and found the way context is getting passed, but basically this: | 19:37 |
| tmcpeak | 'lineno': 7, | 19:38 |
| tmcpeak | ... | 19:38 |
| tmcpeak | 'str': 'sudo innobackupex --stream=xbstream %(extra_opts)s /var/lib/mysql 2>/tmp/innobackupex.log'} | 19:38 |
| tmcpeak | from this: | 19:38 |
| tmcpeak | cmd = ('sudo innobackupex' | 19:38 |
| tmcpeak | ' --stream=xbstream' | 19:38 |
| tmcpeak | ' %(extra_opts)s' | 19:38 |
| tmcpeak | ' /var/lib/mysql 2>/tmp/innobackupex.log' | 19:38 |
| tmcpeak | ) | 19:38 |
| bknudson | yikes! | 19:38 |
| tmcpeak | so AST seems to roll those up as if it was one super long string on the first line | 19:39 |
| tmcpeak | lol, well yeah, there's that | 19:39 |
| tmcpeak | bknudson: lol | 19:39 |
| tmcpeak | is that in production code you ask? well yes, it is | 19:39 |
| tmcpeak | I should probably check with ukbelch, he might have some ideas for how to handle this | 19:43 |
| sigmavirus24 | so | 19:45 |
| sigmavirus24 | that's what I was expecting | 19:45 |
| sigmavirus24 | I'm going to see if pyflakes handles anything like this | 19:45 |
| tmcpeak | sigmavirus24: awesome, thanks | 19:45 |
| tmcpeak | I can think of some solutions, but none of them are great | 19:45 |
| *** elo has joined #openstack-security | 19:52 | |
| sigmavirus24 | So I'm not seeing anything immediately jump out at me but I also can't think of a situation where pyflakes would issue a warning on a multiline expression | 19:52 |
| tmcpeak | sigmavirus24: yeah, multiline expressions are generally handled with ukbelch's statement buffer code, but the thing is that AST is actually collapsing each line of the string into one, so we don't even know it's happening | 19:53 |
| tmcpeak | to fix it we'd probably have to read the file and do some simple parse logic :\ | 19:54 |
| sigmavirus24 | so | 19:54 |
| tmcpeak | or find the next statement and walk backwards, strip the whitespace, and then report the line range | 19:54 |
| sigmavirus24 | the AST would do the same with a multiline if too | 19:54 |
| tmcpeak | either way is kind of jank | 19:54 |
| tmcpeak | sigmavirus24: yeah, you're right, it probably would | 19:54 |
| sigmavirus24 | so reading ahead wouldn't be bad but that still wouldn't give us much except a range | 19:54 |
| sigmavirus24 | i.e., the error is between [7, 11) | 19:55 |
| tmcpeak | I think the range is all we need | 19:55 |
| tmcpeak | oh, I see | 19:55 |
| tmcpeak | yeah... | 19:55 |
| sigmavirus24 | in your specific example | 19:55 |
| * sigmavirus24 wonders if we could tokenize the file and easily associate it with the parsed AST | 19:55 | |
| sigmavirus24 | tokenizing it would preserve multiline statements (which is why pep8 doesn't have this problem) | 19:55 |
| tmcpeak | yeah, it seems like we'll have to get something like that | 19:56 |
| tmcpeak | also not an insignificant change | 19:57 |
| sigmavirus24 | yep | 19:57 |
| sigmavirus24 | tokenize is at least stdlib | 19:57 |
| sigmavirus24 | =P | 19:57 |
| tmcpeak | seems like we should probably wait until we have something to address this before we push a new version though :\ | 19:57 |
| sigmavirus24 | oh | 19:58 |
| sigmavirus24 | hm | 19:58 |
| sigmavirus24 | I have an idea | 19:58 |
| tmcpeak | what's up? | 19:58 |
| sigmavirus24 | So tokenize doesn't need to take the whole file | 19:58 |
| sigmavirus24 | we could use the range idea and then tokenize those lines and figure out the offending line based on that | 19:59 |
| tmcpeak | sigmavirus24: ooh, yeah.. that sounds good | 19:59 |
| sigmavirus24 | that should minimize the impact and we could avoid tokenization if it really is just a single line | 19:59 |
| sigmavirus24 | *I think tokenize doesn't need to take the whole file | 19:59 |
| tmcpeak | I haven't used tokenize before, I'll go have a quick peek | 19:59 |
| sigmavirus24 | tokenize.generate_tokens I think | 19:59 |
| sigmavirus24 | Should return a generator | 19:59 |
| tmcpeak | sigmavirus24: yeah, looks like it could work with a range, anything that provides the readline interface is fair game | 20:02 |
| sigmavirus24 | yep | 20:02 |
| sigmavirus24 | we could buffer that stuff into a StringIO or BytesIO (whichever is appropriate) and use that | 20:02 |
| tmcpeak | yeah, makes sense. So is the idea to do this for every statement or just known problems? | 20:03 |
| tmcpeak | I guess every statement makes sense | 20:03 |
| tmcpeak | we don't want to get into the if(edgecase1) elif (edgecase2) business | 20:04 |
| *** edmondsw has quit IRC | 20:04 | |
| sigmavirus24 | uh | 20:05 |
| sigmavirus24 | I think we can simply do it if (next_lineno - current_lineno) > 1 | 20:06 |
| sigmavirus24 | in other words, if it's a multiline statement | 20:06 |
| tmcpeak | also yeah, we have to walk backwards from the next statement to get the proper line range | 20:06 |
| tmcpeak | yeah | 20:06 |
| sigmavirus24 | yeah that might not be ideal | 20:06 |
| sigmavirus24 | Idk | 20:06 |
| sigmavirus24 | we should experiment with it | 20:06 |
| tmcpeak | yep | 20:06 |
| tmcpeak | fairly big change regardless, you agree on holding up next Bandit version while we sort this? | 20:06 |
| *** jian5397 has joined #openstack-security | 20:10 | |
| sigmavirus24 | So I guess my question is "What is Bandit's release ideology?" | 20:12 |
| sigmavirus24 | Is it "release numbers are cheap, let's get good features to the users now and fix up bugs in a minor bug fix later next week" or is it "releases should be few and far between to ensure stability and adoption"? | 20:12 |
| tmcpeak | my feeling is the latter, but consensus on this would be good | 20:13 |
| tmcpeak | chair6, browne: ^ thoughts? | 20:13 |
| * sigmavirus24 has a proposal for a new check but he doesn't think it'll ever actually be used in openstack | 20:25 | |
| tmcpeak | sigmavirus24: what you got? | 20:26 |
| * sigmavirus24 forgot that urllib3 allows people to assert a specific hostname when doing certification validation for a connection | 20:27 | |
| sigmavirus24 | e.g., assert_hostname='https://malicioushostname.com' | 20:27 |
| sigmavirus24 | pretty sure we never ever want people to do that | 20:27 |
| sigmavirus24 | Basically "don't use the hostname from the request uri, use this one instead" | 20:27 |
| *** jian5397 has quit IRC | 20:27 | |
| tmcpeak | sorry, I'm confused :) | 20:28 |
| tmcpeak | example? | 20:28 |
| sigmavirus24 | tmcpeak: so look at https://github.com/sigmavirus24/requests-toolbelt/blob/master/requests_toolbelt/adapters/fingerprint.py#L48 for example | 20:29 |
| sigmavirus24 | That allows for fingerprint pinning | 20:30 |
| sigmavirus24 | Something similar could be used for hostname pinning | 20:30 |
| tmcpeak | ahh, so make sure that urllib is being called with the hostname to validate? | 20:30 |
| sigmavirus24 | make sure it isn't | 20:31 |
| tmcpeak | what's wrong with it doing so? | 20:31 |
| sigmavirus24 | consider setting up a MITM proxy that presents a certificate with a hostname of "malicioushostname.com" and registering a transport adapter such that every HTTPS request verifies it gets the certificate the hostname it's checking for is "malicioushostname.com" | 20:32 |
| tmcpeak | but that only works if you aren't validating certificates, right? | 20:32 |
| browne | tmcpeak, bknudson: i used -ll on bandit command line to check for high and mediums in other projects rather than crating a 'conservative' and 'verbose' profile | 20:33 |
| tmcpeak | browne: ahh ok | 20:34 |
| *** elo has quit IRC | 20:34 | |
| bknudson | browne: do you have an example? | 20:34 |
| tmcpeak | sigmavirus24: so I MITM and present a response for every request to malicioushostname.com, but I my response isn't signed with a certificate you trust, so hostname validation checks, but cert validation doesn't | 20:35 |
| sigmavirus24 | tmcpeak: true | 20:36 |
| browne | bknudson: https://review.openstack.org/#/c/179568/ | 20:37 |
| browne | commands = bandit -c bandit.yaml -r cinder -n 5 -ll | 20:37 |
| bknudson | that has all sorts of profiles | 20:37 |
| tmcpeak | browne: does that work then? I think even some of the mediums need to be filtered out, like binding to 0.0.0.0 | 20:37 |
| tmcpeak | bknudson: but he's not using them.. | 20:37 |
| browne | that's the default bandit.yaml basically | 20:38 |
| tmcpeak | projects I've seen bind to 0.0.0.0 all over the place, if we have that enabled in a gate it's bad news bears | 20:38 |
| browne | i just wanted to gate on mediums and highs | 20:38 |
| tmcpeak | that's a sensible approach | 20:38 |
| browne | well, 0.0.0.0 is controversial, guess # nosec could be used | 20:39 |
| tmcpeak | yeah | 20:39 |
| tmcpeak | profile is essentially mostly filtering out the lows anyway :) | 20:39 |
| tmcpeak | I believe there are some from blacklist call I removed also | 20:39 |
| tmcpeak | is it working for Cinder browne? | 20:40 |
| browne | i forgot to put the output on pastebin for cinder. let me do that now | 20:40 |
| browne | i did for the nova patch however, https://review.openstack.org/#/c/179566/ | 20:41 |
| browne | guess my plan was to introduce bandit to these projects, checking the medium and highs, then determine which ones the cores care about in the scan | 20:41 |
| browne | it would be non-voting to start anyway | 20:42 |
| tmcpeak | I think the problem with this approach though, is that we (Bandit) can't introduce any medium or high severity findings without potentially breaking gates | 20:42 |
| browne | well, any new version of bandit has the possibility to do that since an existing check may get better or worse at finding problems | 20:43 |
| Daviey | bandit jobs probably need 2 modes, gate and advisory | 20:43 |
| Daviey | with advisory non-voting... probably good for introucing new tasks | 20:43 |
| tmcpeak | browne: good point | 20:44 |
| browne | i like the gate vs. advisory. are there any jobs like that today? | 20:44 |
| tmcpeak | Daviey: yeah… that would translate to voting/non-voting? | 20:44 |
| Daviey | right! | 20:44 |
| tmcpeak | yeah, makes sense | 20:44 |
| Daviey | Then as advisory is clean for a project, it gets added to the voting task | 20:45 |
| tmcpeak | Daviey: +1, this provides an encouragement to resolve issues | 20:45 |
| browne | well, that would work for the most part | 20:45 |
| *** salv-orlando has joined #openstack-security | 20:56 | |
| *** sdake_ has quit IRC | 20:56 | |
| *** timkennedy has quit IRC | 21:03 | |
| *** alex_klimov has joined #openstack-security | 21:17 | |
| *** jian5397 has joined #openstack-security | 21:26 | |
| *** dave-mccowan has quit IRC | 21:39 | |
| *** jian5397 has quit IRC | 21:40 | |
| *** localloop127 has quit IRC | 21:44 | |
| *** nkinder has quit IRC | 21:53 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 22:06 | |
| *** dave-mccowan has joined #openstack-security | 22:07 | |
| openstackgerrit | Michael McCune proposed openstack/security-doc: Add OSSN-0049 https://review.openstack.org/194416 | 22:16 |
| *** dave-mccowan has quit IRC | 22:31 | |
| tmcpeak | browne: I'm just afraid without a profile, if we add any new medium or high severity test, we might break the Cinder gate | 22:41 |
| *** salv-orlando has quit IRC | 22:42 | |
| browne | ok, i can create a profile of just the current medium/highs. | 22:43 |
| tmcpeak | browne: ok cool, I think I'd feel more comfortable with that | 22:46 |
| tmcpeak | browne: check out Brant's change, I'd like to standardize on an approach so when I implement code to suggest profile changes it's easy :) | 22:46 |
| browne | tmcpeak: sure. on bknudson's patch i wasn't sure why some checks are excluded in the keystone case | 22:48 |
| bknudson | browne: there's probably a way to add some docs to the yaml to say why checks are excluded. | 22:49 |
| *** alex_klimov has quit IRC | 22:51 | |
| browne | bknudson: did you use #nosec anywhere? | 22:51 |
| bknudson | browne: not in keystone | 22:51 |
| bknudson | but then I would have excluded any test that required me adding #nosec. | 22:51 |
| browne | ah | 22:52 |
| browne | is there any noticeable performance difference when excluding some tests? | 22:53 |
| bknudson | browne: I didn't notice any | 22:53 |
| browne | tmcpeak: not sure we can standardize on the profile for all projects. | 22:54 |
| browne | for example, execute_with_run_as_root_equals_true might be useful for nova, but useless for keystone | 22:54 |
| bknudson | keystone has no use for that since we don't rootwrap | 22:55 |
| browne | right | 22:55 |
| browne | and if every project excluded a check, then i wonder the usefulness of the check | 22:55 |
| browne | but i guess we could provide a variety of profiles in the default yaml that matches most of the projects | 22:56 |
| browne | then each project can select the profile to check in their tox.ini | 22:57 |
| *** singleth_ has quit IRC | 23:15 | |
| *** markvoelker has quit IRC | 23:16 | |
| tmcpeak | browne: no, I don't think we need to standardize on one profile, just a format | 23:18 |
| tmcpeak | like if the profile name is the same | 23:18 |
| tmcpeak | and, for example, alphabetized checks | 23:18 |
| bknudson | here's another yikes: https://review.openstack.org/#/c/186201/ | 23:19 |
| browne | bknudson: ha, yep, saw that earlier. ugh | 23:19 |
| browne | it would be nice if bandit could run like flake8, so that profiles weren't necessary. just configure in tox an inclusive list of checks to use | 23:25 |
| bknudson | flake8 doesn't have configurable checkers | 23:27 |
| browne | appears to have ways to exclude at least | 23:28 |
| browne | or ignore i should say | 23:28 |
| bknudson | y, you can exclude specific tests | 23:28 |
| bknudson | you set ignore = H405 in your flake8. | 23:28 |
| bknudson | I mean in the tox.ini | 23:29 |
| bknudson | of course you can have a whole list of ignores | 23:29 |
| bknudson | but that's also what requires us to pin flake8 | 23:30 |
| *** nkinder has joined #openstack-security | 23:42 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 23:48 | |
| sigmavirus24 | bknudson: actually you can select only the checks you want to run | 23:49 |
| sigmavirus24 | flake8 --select=E1 will take all E1xx checks and run them | 23:50 |
| sigmavirus24 | you can also do flake8 --select=E1 --ignore=E123 | 23:50 |
| *** sigmavirus24 is now known as sigmavirus24_awa | 23:51 | |
| openstackgerrit | Stanislaw Pitucha proposed stackforge/anchor: Update documentation https://review.openstack.org/190503 | 23:54 |
| *** dave-mccowan has joined #openstack-security | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!