[openstack-dev] [new][bandit] Release 1.1.0 (httpoxy, important fixes)

[Kelsey, Timothy John]

Hi folks,
New bandit release 1.1.0 has been tagged. Importantly, this includes a security 
fix for a bug[1] in HTML formatted reports that could permit XSS.

[New Features]
- New test for HTTPoxy bug (CVE-2016-5386)
- Man page added

[Bug Fixes]
- XSS bug fixed in HTML output (Security fix)
- Various typos and spelling errors fixed

[Behind the Scenes]
- Catch general exceptions per-file
- Many docs improvements
- Py3.5 bits

[1] https://bugs.launchpad.net/ossn/+bug/1612988



__
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] [Announce]Bandit 1.0 stable released

[Kelsey, Timothy John]

Bandit release 1.0 stable
-

This milestone release includes a number of major new features, as follow:

- Test IDs: bandit tests are now given unique IDs. These IDs can be used in
  all situations where a test name would have been used previously
  (include, exclude, etc). Additionally new CLI options "-t/-s" take a list
  of test IDs to include or exclude respectively. Terse test IDs are much
  more convenient then long winded names. Support for referring to tests by
  name is now deprecated and will be removed in a future version.

- Configuration Overhaul: The bandit configuration file is now optional. All
  test plugins ship with good defaults that will be used if not overridden.
  The configuration file format has also been re-worked to be much simpler
  and make good use of the new test IDs. While the old config file format is
  still supported, it is deprecated and this support will be removed in a
  future version. Please see the documentation for info on the new format.

- Configuration tool: A new style configuration file may be generated using
  the included configuration generator tool. This contains defaults for all
  discovered plugins. It provides a good base that can then be hand edited
  as needed.

- Profiles Deprecated: Bandit's configuration files previously contained named
  lists of test to include and exclude, known as a "profile". This concept has
  been deprecated in 1.0 and will be removed in future versions when support
  for legacy configurations is dropped. In place of profiles we encourage
  adopters to use several separate config files and pick one using the -c
  command line option. This has the advantage of permitting test configuration
  defaults to be overridden as needed. Adopters may find that the new -t and
  -s CLI options completely remove the need for a "profile" or equivalent.

- Blacklists: Blacklisted items (function calls, module imports) now have test
  IDs. Fine control of blacklisting is now possible using these IDs to include
  or exclude items. A new plugin interface has been created to allow third
  party adopters to extend blacklist items if desired. Suport for legacy
  blacklist data is part of the deprecated legacy configuration support.
  Please see the Configuration Overhaul item.

The plugin API, CLI and configuration scheme should now be considered stable.
No new version of bandit will break this contract without incrementing the
major release number.

This release also includes a number of important bug fixes, we encourage
adopters to upgrade to bandit 1.0 as soon as they are able.

What this means for adopters


In most cases you will simply need to delete your bandit.yaml file and
adjust the invocation used in your tox.ini, adding -t or -s options as needed.
In more advance scenarios, generating a minimal configuration file using the
included config generation tool and tweaking as needed will be sufficient.

Finally, new integration tests have been added bandit in an effort to maintain
good compatibility with projects using bandit in the gate. The following
projects are included:

- barbican
- glance
- keystone
- keystonemiddleware
- magnum
- oslo.config
- oslo.log
- oslo.service
- oslo.utils
- python-keystoneclient
- python-magnumclient
- sahara

If your project would like to use bandit and be included in these tests,
please contact the bandit team.

—

Thank you,

The bandit dev team


__
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] [bandit] [glance] [openstack-ansible] [searchlight] Resigning from core reviewers teams

[Kelsey, Timothy John]

On 28/10/2015 09:35, "Tripp, Travis S"  wrote:

>
>
>On 10/28/15, 11:43 AM, "Flavio Percoco"  wrote:
>
>>On 26/10/15 17:20 +, Ian Cordasco wrote:
>>>Hi everyone,
>>>
>>>
>>>Today I'm removing myself from the core reviewer (and driver)
>>>teams for the
>>>
>>>
>>>following projects:
>>>
>>>- Bandit (bandit-core and transitively security-specs-core)
>>>
>>>- Glance (glance-core and glance-specs-core)
>>>
>>>- OpenStack Ansible (openstack-ansible-core)
>>>
>>>- Searchlight (searchlight-core)
>>>
>>>Recent events both in my position at Rackspace and my personal
>>>life mean I no longer have sufficient time to properly act as a core
>>>reviewer for
>>>These projects. My personal life has suffered from attempts to continue
>>>to uphold my responsibilities to OpenStack and the other open source
>>>projects I
>>>develop, maintain, and direct. Changing responsibilities in my current
>>>role
>>>in the last 8-10 months mean that I don't have sufficient time during
>>>the
>>>normal 0900-1700 period to accurately and thoroughly conduct reviews.
>>>I'm confident
>>>this is only a temporary hiatus and that sometime next year, I will be
>>>able to fully rejoin the OpenStack community.
>>>
>>
>>Ian,
>>
>>I can't stress enough how sorry I am to see you go from the team. Your
>>reviews, comments and contributions have always been excelent and of
>>huge help to our community.
>>
>>I look forward for that time when you'll be able to come back and as a
>>*member* of the community I'd be more than happy to have you back.
>>
>>Thanks for all the time you've spent on these projectes, for your
>>honest and clear email on your situation and availability.
>>
>>Take good care and, please, come back :)
>>Flavio
>>
>>-- 
>>@flaper87
>>Flavio Precook
>
>
>Ian,
>
>Your core status on all of these projects is a true testament to your
>abilities, dedication, and character.  All of which we greatly
>appreciate about having you on the searchlight team and are why
>you will always be welcome on our team. In the meantime, I fully
>support you making decisions that are best for you and your family.
>I hope that you will be able to find a balance which works for you.
>
>
>Thank you for all that you have done and contributed!
>
>-Travis

Thank you for your time and dedication Ian, your input will be missed.
Finding a good work/life balance is important and I for one would hate
to see you negatively effected by the time you have generously given to
all the projects your involved in. This is a good move and I¹m sure we
will all look forward to your eventual return.

Thanks again for your hard work.

- Tim

(IRC: tkelsey)

>


__
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] [security][bandit] Looking to the future

[Kelsey, Timothy John]

Hey Bandit Folks,
Thanks for all the great work done during the recent security mid cycle, we 
have made some really solid progress on key areas like documentation, testing, 
and code quality. It was also great to see people in person! This email follows 
on from various conversations with the hope of keeping our momentum and 
planning out our next steps.

Key Focus Areas

Documentation
We made good progress here getting our docs layout and initial content down. 
The next steps now are to keep pushing to bring our docs up to scratch across 
the board, covering all testing and report plugins we have available today. As 
cores, I would suggest we don’t accept any new tests without accompanying 
documentation. Work will now be done to integrate our sphinx build with infra 
to get our stuff available online, much in the same way as Anchor has done 
here: http://docs.openstack.org/developer/anchor/

Testing
We had a strong push to add unit tests to supplement our existing functional 
tests. Going forward we should continue to focus on bringing our coverage up 
and bug fixing as we go. Cores should be mindful of coverage when reviewing new 
patches and significant blocks of new work should of course be accompanied with 
unit tests. To help with this, coverage reporting will be added to the current 
tox output report.

Code Quality
Bandit is growing fast, new and interesting stuff is being added all the time, 
but its worth keeping in mind that there is a lot of code that was hastily 
written for the original prototype and still persists in the code base today. 
This is a source of potential bugs and unnecessary complexity, any effort 
directed in improving this situation would be a good thing. Refactoring is also 
a perfect opportunity to bring up our test coverage as well.

Releases
Up to this point bandit has had a fairly add-hoc release schedule, with new 
releases being pushed once a significant number of new features/bug fixes have 
been accumulated. Going forward we should review this strategy and determine if 
it is still appropriate. We should also consider how our releases could best 
tie into the overarching OpenStack release cadence. I would very much like to 
hear peoples thoughts on this matter.

Anyway, please let me know what people think of this, or anything else that I 
haven’t covered here.

Thanks again for all your hard work

--
Tim Kelsey
Cloud Security Engineer
HP Hellion

__
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] [Security][Bandit] Bandit gate usage

[Kelsey, Timothy John]

On 03/07/2015 09:39, Gorka Eguileor gegui...@redhat.com wrote:


On Thu, Jul 02, 2015 at 07:09:41PM +, Kelsey, Timothy John wrote:
 Hello Stackers,
 A few intrepid projects have started adopting Bandit, an automatic
security linter built by the security project, into their gate tests.
This is very rewarding to see for those of us who have worked on the
project and people with an interest in securing the OpenStack codebase.
The list of (known) adopters so far:
 
 - Keystone
 - Keystone-client
 - Barbican
 - Anchor
 - Sahara
 - Magnum
 
 If you know of, or are involved in a project that¹s using Bandit and
isn¹t on our list then please let us know, it would be great to hear
your feedback. If you would like to begin using it then check out our
wiki for instructions here [1].  If you have no idea what this Bandit
thing is then perhaps this presentation from the Vancouver summit might
be interesting to you [2]. A Bandit gate job can be configured either as
an experimental or none-voting job, so if your interested in trying it
out you can give it a go and decide if its a good fit for your project
before fully committing.

Hi,

At Cinder we are adding [1] basic bandit configuration for high and
medium severity results as a tox option, but not running it by default
for now.

Cheers,
Gorka


Thanks for letting us know Gorka, I¹m pleased bandit is on the Cinder
radar. I hope it¹s working out for you, please reach out if you have any
suggestions or concerns with the tool.



[1]: https://review.openstack.org/#/c/179568/

 
 Bandit is regularly discussed in the Security Project IRC meetings and
feedback is very welcome. If you have questions or suggestions then feel
free to drop in or reply here.
 
 [1] https://wiki.openstack.org/wiki/Security/Projects/Bandit
 [2] https://www.youtube.com/watch?v=hxbbpdUdU_k
 
 Many thanks
 
 --
 Tim Kelsey
 OpenStack Security member
 
 
_
_
 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 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] [Security][Bandit] Bandit gate usage

[Kelsey, Timothy John]

Hello Stackers,
A few intrepid projects have started adopting Bandit, an automatic security 
linter built by the security project, into their gate tests. This is very 
rewarding to see for those of us who have worked on the project and people with 
an interest in securing the OpenStack codebase. The list of (known) adopters so 
far:

- Keystone
- Keystone-client
- Barbican
- Anchor
- Sahara
- Magnum

If you know of, or are involved in a project that’s using Bandit and isn’t on 
our list then please let us know, it would be great to hear your feedback. If 
you would like to begin using it then check out our wiki for instructions here 
[1].  If you have no idea what this Bandit thing is then perhaps this 
presentation from the Vancouver summit might be interesting to you [2]. A 
Bandit gate job can be configured either as an experimental or none-voting job, 
so if your interested in trying it out you can give it a go and decide if its a 
good fit for your project before fully committing.

Bandit is regularly discussed in the Security Project IRC meetings and feedback 
is very welcome. If you have questions or suggestions then feel free to drop in 
or reply here.

[1] https://wiki.openstack.org/wiki/Security/Projects/Bandit
[2] https://www.youtube.com/watch?v=hxbbpdUdU_k

Many thanks

--
Tim Kelsey
OpenStack Security member

__
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] [barbican] Using KMIP with Barbican (Utkarsh Simha)

[Kelsey, Timothy John]

Hi Utkarsh,


I am also happy to help figure out whats going in here, as Kaitlin says,
the first step is get some more log info.

-- 
Tim Kelsey

Cloud Security Engineer
HP Helion




On 25/03/2015 15:24, Farr, Kaitlin M. kaitlin.f...@jhuapl.edu wrote:

Hi Utkarsh,

Specifying kmip_plugin in the barbican-api.conf is the correct way to
configure the plugin. In my previous debugging experience, I've found
that I
get CryptoPluginNotFound if an error occurred during the plugin's __init__
method. For the KMIP plugin, this means the key file permissions were not
set to 400 or the PyKMIP KMIPProxy object could not be created with the
configuration options set. To debug this further, we'll need to log at the
logs for more clues.

Hope this helps!

Kaitlin Farr
Johns Hopkins University Applied Physics Laboratory


--

Date: Mon, 23 Mar 2015 16:56:43 +0530
From: Utkarsh Simha utkarshsi...@gmail.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [barbican] Using KMIP with Barbican
Message-ID:

CAHYfr2UcytKpNRrzsv+-jkkVmxEwz=rhcs2ybuj3bgmu8vd...@mail.gmail.com
Content-Type: text/plain; charset=UTF-8

Hello!

I was wondering how it is possible to use an external Key Management
Server with Barbican? I have configured the barbican-api.conf file for
the KMIP Plugin and also set enabled_crypto_plugins to
kmip_plugin, but it says CryptoPluginNotFound

Any help is appreciated! Thank you :)

--
Regards



--

*

__
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

Re: [openstack-dev] [barbican] Secret store API validation

[Kelsey, Timothy John]

On 18/11/2014 21:07, Nathan Reller rellerrel...@yahoo.com wrote:

 It seems we need to add some validation to the process

Yes, we are planning to add some validation checks in Kilo. I would
submit a bug report for this.

The big part of the issue is that we need to be clearer about the
expected input types to the API as well as the SecretStores. This was
a big topic of discussion at the summit. I hope to have a spec out
soon, I hope, that will address this issue.

-Nate

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OK, I¹ll file a bug and look forward to reviewing your spec. Thanks Nate.





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Secret store API validation

[Kelsey, Timothy John]

Hello Barbican folks,
Recently I was experimenting with the KMIPSecretStore and observed the 
following behaviour. Issuing the API call:

curl -X POST -H 'content-type:application/json' -H 'X-Project-Id:12345' -d 
'{payload: my-secret-here, payload_content_type: text/plain, 
algorithm: aes, bit_length:256}' 
http://localhost:9311/v1/secrets”http://localhost:9311/v1/secrets%22

worked to store a secret in the backend HSM, but upon retrieving the secret I 
was presented with “mysecrethere”, instead of the expected value 
“my-secret-here”. This corruption of the secret occurs because internally it is 
assumed to be encoded as base64 and the base64 decoder drops invalid bytes, in 
this case the “-“ characters. For more discussion please see the comments on 
this review: https://review.openstack.org/#/c/133725/

It seems we need to add some validation to the process so I would like to get a 
discussion going on what we should be validating and where in the pipeline it 
might fit best. Im happy to code up a patch to make this happen but want to get 
some input and a consensus on things first.

--
Tim Kelsey
Cloud Security Engineer
HP Helion

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev