Re: [openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo.

2015-11-03 Thread Victor Stinner 

Le 02/11/2015 19:40, Brant Knudson a écrit :

(...) by typing something like:

$ bandit-conf-generator --disable try_except_pass --out bandit.yaml
oslo.messaging ~/openstack/bandit/bandit/config/bandit.yaml


(...) we should have a config file for bandit-conf-generator...
but then why not just have bandit know how to read the
bandit-conf-generator config file and skip the extra step?


Hi,

I don't like very long command lines, it's hard to document them or 
comment them. I prefer configuration files. But bandit.yaml, the 
"template", is already a configuration file!?


As Brant wrote, we should enhance Bandit to use a simpler configuration 
file. Or maybe we should have our own configuration file which on ly 
contains "differences" between the YAML template and the expected YAML 
output configuration file. Basically, the "differences" is what you 
wrote on the command line.


Anyway, it would be better to add this new bandit-conf-generator tool 
(or making config simpler) directly in Bandit. What do you think Cyril?


Victor

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo.

2015-11-03 Thread Cyril Roelandt 

On 11/03/2015 10:50 AM, Victor Stinner wrote:

Hi,

I don't like very long command lines, it's hard to document them or
comment them. I prefer configuration files. But bandit.yaml, the
"template", is already a configuration file!?



Yes, the config file provided by bandit is some kind of "enable all 
checkers" configuration. Basically, it seems to me that people just 
re-use that with minor tweaks.



As Brant wrote, we should enhance Bandit to use a simpler configuration
file. Or maybe we should have our own configuration file which on ly
contains "differences" between the YAML template and the expected YAML
output configuration file. Basically, the "differences" is what you
wrote on the command line.



I think we do not want bandit to start supporting N different 
configuration formats. I like that "bandit" reads "bandit.yaml", in its 
current state. It is *simple*.


Now, writing a working "bandit.yaml" could be less of a burden. To 
achieve this, bandit could provide a tool that allows developers to say 
"well, I want everything but this particular checker" or "well, I need 
this tweak to the configuration of that checker".


The right "architecture" would be:
- bandit-conf-generator (possibly included in the bandit git repo) reads 
a 'bandit-conf' config file and generates 'bandit.yaml';

- 'bandit' reads 'bandit.yaml' and does its job.

The configuration file for bandit-conf-generator could look something like:

[general]
project_name = oslo.messaging
path_to_src = oslo_messaging
disabled_tests = try_except_pass,assert_used

And then some code to configure the checkers that require additional 
configuration. It might be harder to think of something easy to write, 
though :)



Anyway, it would be better to add this new bandit-conf-generator tool
(or making config simpler) directly in Bandit. What do you think Cyril?



Yes. I should write a blueprint :)

Cyril.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo.

2015-11-03 Thread Cyril Roelandt 

On 11/02/2015 07:32 PM, Davanum Srinivas wrote:


If we can add this command directly in our tox.ini and entirely avoid
having the bandit.yaml would that be even better?


Why not, but it'd have some drawbacks as well:

- should the conf generator be broken for some reason, the gate may end 
up being blocked for a while, because fixing it would be harder than 
fixing a bandit.yaml file;
- newcomers will feel overwhelmed knowing that a tool writes a config 
file for another tool that generates a report, so I'd rather keep it 
stupid simple.


WDYT?

Cyril.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo

2015-11-03 Thread McPeak, Travis 
Hi Cyril,

This is a really cool idea.  It should be fairly easy to implement and
can only help make Bandit more usable.  To be honest enhancing the way
we're using the 'bandit.yaml' file has been on our list for a while.

A tool like this seems like it would be a nice intermediate solution
until we get a better config file approach.  I'd like for it to live
in the Bandit repo.

The best way forward is probably to create a quick blueprint to
track the work and whoever wants to take it forward can assign it to
themselves.

By the way, it's really cool to see Oslo using Bandit!

Thanks,
 -Travis




On Mon, Nov 2, 2015 at 1:22 PM, Cyril Roelandt 
wrote:


>Whenever a new version of bandit comes out, one can grab the latest
>config file example from the bandit release, and re-run the above
>command. The generated config file will include all the new checkers.
>
>What do you think? Could this be a useful tool to handle bandit
>configurations?

smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo.

2015-11-03 Thread Cyril Roelandt 

On 11/02/2015 07:40 PM, Brant Knudson wrote:


We could use something like this in keystone since we've got a few
repositories. There should be a way to document why the test was skipped
since otherwise we'll have to figure it out every time we update the
file. Putting a comment on the command line would wind up being
unwieldy, so we should have a config file for bandit-conf-generator...
but then why not just have bandit know how to read the
bandit-conf-generator config file and skip the extra step?



The bandit.yaml from python-keystoneclient supports multiple profiles, 
which is already something my tool, in its current state, cannot do.


I don't know exactly which set of features should be supported by a 
configuration generator. If it becomes too hard to write the 
configuration for the configuration generator, we might as well just 
write the configuration for bandit manually :⁾


See my answer to Victor about enhancing Bandit so that it can read a 
"simpler" config file. I'm not a big fan of it.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo.

2015-11-03 Thread Doug Hellmann 
Excerpts from Cyril Roelandt's message of 2015-11-03 16:46:25 +0100:
> On 11/02/2015 07:32 PM, Davanum Srinivas wrote:
> >
> > If we can add this command directly in our tox.ini and entirely avoid
> > having the bandit.yaml would that be even better?
> 
> Why not, but it'd have some drawbacks as well:
> 
> - should the conf generator be broken for some reason, the gate may end 
> up being blocked for a while, because fixing it would be harder than 
> fixing a bandit.yaml file;
> - newcomers will feel overwhelmed knowing that a tool writes a config 
> file for another tool that generates a report, so I'd rather keep it 
> stupid simple.

We have a hacking plugin for flake8 that we use to apply common rules
across projects. Unfortunately, since not all projects are ready to
apply those rules at the same time we have to carefully upgrade hacking
in a way that doesn't break anyone's gate jobs until their code matches
the rules in the new version.

That said, since we already have the pattern of a plugin providing a
common set of rules, I wonder if we could do something similar for
bandit. Maybe the bandit developers don't want a plugin, which would
make a wrapper program easier to implement. The wrapper could own the
common contents of the YAML file, with each application able to override
the settings by updating its local copy of the file. We could then
manage updates of this tool in the same way we do for
hacking/flake8/pep8.

Doug

PS - Bonus points for naming the wrapper program "smokey" [1].

[1] https://en.wikipedia.org/wiki/Smokey_and_the_Bandit

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo.

2015-11-03 Thread Brant Knudson 
On Tue, Nov 3, 2015 at 9:41 AM, Cyril Roelandt  wrote:

> On 11/02/2015 07:40 PM, Brant Knudson wrote:
>
>>
>> We could use something like this in keystone since we've got a few
>> repositories. There should be a way to document why the test was skipped
>> since otherwise we'll have to figure it out every time we update the
>> file. Putting a comment on the command line would wind up being
>> unwieldy, so we should have a config file for bandit-conf-generator...
>> but then why not just have bandit know how to read the
>> bandit-conf-generator config file and skip the extra step?
>>
>
>
> The bandit.yaml from python-keystoneclient supports multiple profiles,
> which is already something my tool, in its current state, cannot do.
>
>
The only reason for that is because I haven't updated it yet to match the
normal usage where there is only the 1 gate profile.

:: Brant


> I don't know exactly which set of features should be supported by a
> configuration generator. If it becomes too hard to write the configuration
> for the configuration generator, we might as well just write the
> configuration for bandit manually :⁾
>
> See my answer to Victor about enhancing Bandit so that it can read a
> "simpler" config file. I'm not a big fan of it.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo.

2015-11-02 Thread Cyril Roelandt 

Hello,

The libraries from the Oslo project are used everywhere in OpenStack, 
which means that a security issue in Olso code might have an impact on a
lot of other projects. This is why I am currently trying to add support 
for the bandit[1] static checker in all of the Oslo libraries.


While reviewing one of my patches[2], Victor Stinner noticed that the 
bandit configuration file (bandit.yaml) I proposed, which is basically a

copy of the example config file[3] provided by the bandit project with
some minor changes, might be a bit hard to maintain across all Oslo 
projects. Indeed, all configuration files could potentially have to be

changed whenever a new checker is added to bandit, for instance.

In order to make it easier to keep an up-to-date configuration file, I
quickly wrote a proof of concept[4] that allows developers to generate a
configuration file that fits their needs. One can now generate a working
bandit.yaml configuration file by typing something like:

$ bandit-conf-generator --disable try_except_pass --out bandit.yaml 
oslo.messaging ~/openstack/bandit/bandit/config/bandit.yaml


Whenever a new version of bandit comes out, one can grab the latest
config file example from the bandit release, and re-run the above
command. The generated config file will include all the new checkers.

What do you think? Could this be a useful tool to handle bandit
configurations?


Cyril Roelandt.
---

[1] https://wiki.openstack.org/wiki/Security/Projects/Bandit
[2] https://review.openstack.org/#/c/239666/
[3] 
https://github.com/openstack/bandit/blob/master/bandit/config/bandit.yaml

[4] https://github.com/CyrilRoelandteNovance/bandit_conf_generator

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo.

2015-11-02 Thread Davanum Srinivas 
Cyril,

If we can add this command directly in our tox.ini and entirely avoid
having the bandit.yaml would that be even better?

-- Dims

On Mon, Nov 2, 2015 at 1:22 PM, Cyril Roelandt  wrote:

> Hello,
>
> The libraries from the Oslo project are used everywhere in OpenStack,
> which means that a security issue in Olso code might have an impact on a
> lot of other projects. This is why I am currently trying to add support
> for the bandit[1] static checker in all of the Oslo libraries.
>
> While reviewing one of my patches[2], Victor Stinner noticed that the
> bandit configuration file (bandit.yaml) I proposed, which is basically a
> copy of the example config file[3] provided by the bandit project with
> some minor changes, might be a bit hard to maintain across all Oslo
> projects. Indeed, all configuration files could potentially have to be
> changed whenever a new checker is added to bandit, for instance.
>
> In order to make it easier to keep an up-to-date configuration file, I
> quickly wrote a proof of concept[4] that allows developers to generate a
> configuration file that fits their needs. One can now generate a working
> bandit.yaml configuration file by typing something like:
>
> $ bandit-conf-generator --disable try_except_pass --out bandit.yaml
> oslo.messaging ~/openstack/bandit/bandit/config/bandit.yaml
>
> Whenever a new version of bandit comes out, one can grab the latest
> config file example from the bandit release, and re-run the above
> command. The generated config file will include all the new checkers.
>
> What do you think? Could this be a useful tool to handle bandit
> configurations?
>
>
> Cyril Roelandt.
> ---
>
> [1] https://wiki.openstack.org/wiki/Security/Projects/Bandit
> [2] https://review.openstack.org/#/c/239666/
> [3]
> https://github.com/openstack/bandit/blob/master/bandit/config/bandit.yaml
> [4] https://github.com/CyrilRoelandteNovance/bandit_conf_generator
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo.

2015-11-02 Thread Brant Knudson 
On Mon, Nov 2, 2015 at 12:22 PM, Cyril Roelandt  wrote:

> Hello,
>
> The libraries from the Oslo project are used everywhere in OpenStack,
> which means that a security issue in Olso code might have an impact on a
> lot of other projects. This is why I am currently trying to add support
> for the bandit[1] static checker in all of the Oslo libraries.
>
> While reviewing one of my patches[2], Victor Stinner noticed that the
> bandit configuration file (bandit.yaml) I proposed, which is basically a
> copy of the example config file[3] provided by the bandit project with
> some minor changes, might be a bit hard to maintain across all Oslo
> projects. Indeed, all configuration files could potentially have to be
> changed whenever a new checker is added to bandit, for instance.
>
> In order to make it easier to keep an up-to-date configuration file, I
> quickly wrote a proof of concept[4] that allows developers to generate a
> configuration file that fits their needs. One can now generate a working
> bandit.yaml configuration file by typing something like:
>
> $ bandit-conf-generator --disable try_except_pass --out bandit.yaml
> oslo.messaging ~/openstack/bandit/bandit/config/bandit.yaml
>
> Whenever a new version of bandit comes out, one can grab the latest
> config file example from the bandit release, and re-run the above
> command. The generated config file will include all the new checkers.
>
> What do you think? Could this be a useful tool to handle bandit
> configurations?
>
>
We could use something like this in keystone since we've got a few
repositories. There should be a way to document why the test was skipped
since otherwise we'll have to figure it out every time we update the file.
Putting a comment on the command line would wind up being unwieldy, so we
should have a config file for bandit-conf-generator... but then why not
just have bandit know how to read the bandit-conf-generator config file and
skip the extra step?

- Brant


> Cyril Roelandt.
> ---
>
> [1] https://wiki.openstack.org/wiki/Security/Projects/Bandit
> [2] https://review.openstack.org/#/c/239666/
> [3]
> https://github.com/openstack/bandit/blob/master/bandit/config/bandit.yaml
> [4] https://github.com/CyrilRoelandteNovance/bandit_conf_generator
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev