Retire security-specs repo

This change removes the content from the security-specs repo
as part of the process to retire the repo.

Step 2 as defined in the guide[0].

[0] https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#retiring-a-project

Change-Id: Ifba5759507c4aa73415052458ead08f831b057ce
This commit is contained in:
Gage Hugo 2022-01-31 15:04:17 -06:00
parent b3dcc7a310
commit f8c36fa518
21 changed files with 8 additions and 1221 deletions

18
.gitignore vendored
View File

@ -1,18 +0,0 @@
.DS_Store
AUTHORS
ChangeLog
build
.tox
.venv
*.egg*
*.swp
*.swo
*.pyc
.testrepository
# Editors
*~
.*.swp
.bak
/.project

View File

@ -1,9 +0,0 @@
- project:
templates:
- openstack-specs-jobs
check:
jobs:
- openstack-tox-pep8
gate:
jobs:
- openstack-tox-pep8

View File

@ -1,3 +0,0 @@
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode

View File

@ -1,60 +1,14 @@
========================
Team and repository tags
========================
.. image:: https://governance.openstack.org/tc/badges/security-specs.svg
:target: https://governance.openstack.org/tc/reference/tags/index.html
.. Change things from this point on
======================================
OpenStack Security Specifications
======================================
This git repository is used to hold approved design specifications for
additions to the OpenStack Security Projects. Reviews of the specs
are done in gerrit, using a similar workflow to how we review and
merge changes to the security projects and supporting tools.
This project is no longer maintained.
The layout of this repository is::
The contents of this repository are still available in the Git
source code management system. To see the contents of this
repository before it reached its end of life, please check out the
previous commit with "git checkout HEAD^1".
specs/<release>/
You can find an example spec in `doc/source/specs/template.rst`.
Fill it in with the details of a new blueprint for documentation.
For security projects, blueprints are required for larger, coordinated projects
but not for small fixes. It's a judgement call for whether you need a
spec, so feel free to ask in the
#openstack-security IRC channel or on the openstack-security mailing list.
To propose a specification for a release-specific project, add a new file to
the `specs/<release>` directory and post it for review. The implementation
status of a blueprint for a given release can be found by looking at the
blueprint in Launchpad (and the spec links to Launchpad).
Please realize that not all approved blueprints will get fully implemented.
Security blueprints are being introduced with the Liberty development cycle
using this repository.
Please note, Launchpad blueprints are still used for tracking the
current status of blueprints. For more information, see
https://wiki.openstack.org/wiki/Blueprints.
For more information about working with gerrit, see
http://docs.openstack.org/infra/manual/developers.html#development-workflow.
To validate that the specification is syntactically correct (i.e. get more
confidence in the Jenkins result), please execute the following command::
$ tox
After running ``tox``, the documentation will be available for viewing in HTML
format in the ``doc/build/`` directory. Please do not check in the generated
HTML files as a part of your commit.
The files are published at http://specs.openstack.org/openstack/security-specs.
The git repository is located at
http://git.openstack.org/cgit/openstack/security-specs/.
For any further questions, please email
openstack-discuss@lists.openstack.org or join #openstack-dev on
OFTC.

View File

@ -1,104 +0,0 @@
# -*- coding: utf-8 -*-
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
# implied.
# See the License for the specific language governing permissions and
# limitations under the License.
import datetime
import os
import sys
sys.path.insert(0, os.path.abspath('../..'))
# -- General configuration ----------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
extensions = [
#'sphinx.ext.intersphinx',
'openstackdocstheme',
'yasfb',
]
# openstackdocstheme options
openstackdocs_repo_name = 'openstack/security-specs'
openstackdocs_auto_name = False
openstackdocs_bug_project = 'bandit'
openstackdocs_bug_tag = ''
html_theme = 'openstackdocs'
# Feed configuration for yasfb
feed_base_url = 'https://specs.openstack.org/openstack/security-specs'
feed_author = 'OpenStack Development Team'
exclude_patterns = [
'template.rst',
'**/**/template.rst'
]
suppress_warnings = [
'image.nonlocal_uri',
]
# Optionally allow the use of sphinxcontrib.spelling to verify the
# spelling of the documents.
try:
import sphinxcontrib.spelling
extensions.append('sphinxcontrib.spelling')
except ImportError:
pass
# autodoc generation is a bit aggressive and a nuisance when doing heavy
# text edit cycles.
# execute "export SPHINX_DEBUG=1" in your terminal to disable
# The suffix of source filenames.
source_suffix = '.rst'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = 'security-specs'
copyright = 'OpenStack Foundation'
# If true, '()' will be appended to :func: etc. cross-reference text.
add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
add_module_names = True
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'native'
# -- Options for HTML output --------------------------------------------------
# The theme to use for HTML and HTML Help pages. Major themes that come with
# Sphinx are currently 'default' and 'sphinxdoc'.
# html_theme_path = ["."]
# html_theme = '_theme'
# html_static_path = ['static']
# Output file base name for HTML help builder.
htmlhelp_basename = '%sdoc' % project
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass
# [howto/manual]).
latex_documents = [
('index',
'%s.tex' % project,
'%s Documentation' % project,
'OpenStack Foundation', 'manual'),
]
# Example configuration for intersphinx: refer to the Python standard library.
#intersphinx_mapping = {'http://docs.python.org/': None}

View File

@ -1,26 +0,0 @@
=============================================
Contributing to: security-specs
=============================================
If you would like to contribute to the development of OpenStack,
you must follow the steps in this page:
http://docs.openstack.org/infra/manual/developers.html
Once those steps have been completed, changes to OpenStack
should be submitted for review via the Gerrit tool, following
the workflow documented at:
http://docs.openstack.org/infra/manual/developers.html#development-workflow
Pull requests submitted through GitHub will be ignored.
Bugs should be filed on Launchpad, not GitHub.
For OpenStack Security Guide and OpenStack Security Notes:
https://bugs.launchpad.net/openstack-manuals
For Bandit:
https://bugs.launchpad.net/bandit

View File

@ -1,46 +0,0 @@
Security Design Specifications
==============================
This repository contains specifications and policies that apply to OpenStack
Security Projects. These projects include OpenStack Security Guide, OpenStack
Security Notes, and Bandit.
Mitaka Approved Specs
~~~~~~~~~~~~~~~~~~~~~
.. toctree::
:glob:
:maxdepth: 1
specs/mitaka/*/*
Liberty Approved Specs
~~~~~~~~~~~~~~~~~~~~~~
None.
Kilo Approved Specs
~~~~~~~~~~~~~~~~~~~
.. toctree::
:glob:
:maxdepth: 1
specs/kilo/*/*
Repository Information
======================
.. toctree::
:maxdepth: 1
README <readme>
Specification Template <specs/template>
contributing
Indices and tables
==================
* :ref:`search`

View File

@ -1 +0,0 @@
.. include:: ../../README.rst

View File

@ -1 +0,0 @@
../../specs

View File

@ -1,8 +0,0 @@
# The order of packages is significant, because pip processes them in the order
# of appearance. Changing the order has an impact on the overall integration
# process, which may cause wedges in the gate later.
pbr>=2.0.0
doc8 # Apache-2.0
openstackdocstheme>=2.2.1 # Apache-2.0
sphinx>=2.0.0,!=2.1.0 # BSD
yasfb>=0.5.1

View File

@ -1,21 +0,0 @@
[metadata]
name = security-specs
summary = OpenStack Security Specifications
description-file =
README.rst
author = OpenStack
author-email = openstack-discuss@lists.openstack.org
home-page = http://specs.openstack.org/openstack/security-specs/
python-requires = >=3.6
classifier =
Environment :: OpenStack
Intended Audience :: Developers
License :: OSI Approved :: Apache Software License
Operating System :: POSIX :: Linux
Programming Language :: Python
Programming Language :: Python :: 3
Programming Language :: Python :: 3.6
Programming Language :: Python :: 3.7
Programming Language :: Python :: 3 :: Only
Programming Language :: Python :: Implementation :: CPython

View File

@ -1,21 +0,0 @@
# Copyright (c) 2013 Hewlett-Packard Development Company, L.P.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
# implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# THIS FILE IS MANAGED BY THE GLOBAL REQUIREMENTS REPO - DO NOT EDIT
import setuptools
setuptools.setup(
setup_requires=['pbr>=2.0.0'],
pbr=True)

View File

@ -1,77 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
==========================================================
Seperate Anchor validation functionality to enable reuse
==========================================================
https://blueprints.launchpad.net/anchor/+spec/anchor-separate-package
Problem description
===================
Currently the Anchor CSR validation functionality is all located in the
Anchor package. This prevents the validation functionality from being
easily imported and used by other projects. Therefore, the validation
functionality should be split out into a module under anchor, so it can
be imported by other projects. This will provide a simple API to the
validation functionality, that can be used by both Anchor and other
projects.
This will enable re-use of the CSR validation functionality in other
projects, such as the proposed CA/RA Killick, or in Barbican.
Secondly, the code that performs validation of a CSR aborts when one of
the validators fails - this works ok for Anchor, but the validation
engine can be extended to provide added value for other services by
running all validators and returning a dictionary, giving the result
of each validator that was run.
Proposed change
===============
Break out the code that iterates over the validators from
certificate_ops.py into a new file 'validation.py'. Extend this to
return a dictionary giving the validator name and its return value, or
throw an exception if an error occured.
Modify certificate_ops.py to work with the new validation.py and
dictionary return, while catching any exceptions thrown.
Fix the tests to work with this new functionality.
Implementation
==============
doug-chivers
Milestones
----------
Target Milestone for completion:
Kilo
Work Items
----------
1 - Break out validation functionality into new file
2 - Return the dictionary
3 - Fix testing to work with this, make sure that exceptions thrown by
validators are still caught by certificate_ops.py
Dependencies
============
Anchor
References
==========
N/A

View File

@ -1,110 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. The filename in the git
repository should match the launchpad URL, for example a URL of
https://blueprints.launchpad.net/openstack-manuals/+spec/awesome-thing should
be named awesome-thing.rst . Please do not delete any of the sections in
this template. If you have nothing to say for a whole section, just write:
None For help with syntax, see http://sphinx-doc.org/rest.html
To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
=============================
The title of your blueprint
=============================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-manuals/+spec/example
Or
https://blueprints.launchpad.net/bandit/+spec/example
Introduction paragraph -- why are we doing anything?
Problem description
===================
A detailed description of the problem.
Proposed change
===============
Here is where you cover the change you propose to make in detail. How do you
propose to solve this problem?
If this is one part of a larger effort make it clear where this piece ends. In
other words, what's the scope of this effort?
Include which OpenStack security project this will apply to (OpenStack Security
Guide, OpenStack Security Notes, Bandit, etc). Also include where in the
OpenStack security project tree hierarchy this will reside.
Alternatives
------------
This is an optional section, where it does apply we'd just like a demonstration
that some thought has been put into why the proposed approach is the best one.
Implementation
==============
Assignee(s)
-----------
Who is leading the writing of the code? Or is this a blueprint where you're
throwing it out there to see who picks it up?
If more than one person is working on the implementation, please designate the
primary author and contact.
Primary assignee:
<launchpad-id or None>
Can optionally can list additional ids if they intend on doing
substantial implementation work on this blueprint.
Milestones
----------
Target Milestone for completion:
Liberty-1
Work Items
----------
Work items or tasks -- break the feature up into the things that need to be
done to implement it. Those parts might end up being done by different people,
but we're mostly trying to understand the timeline for implementation.
Dependencies
============
- Include specific references to specs and/or blueprints in openstack-manuals,
or in other projects, that this one either depends on or is related to.
- Does this feature require any new library dependencies or code otherwise not
included in OpenStack? Or does it depend on a specific version of library?
References
==========
Please add any useful references here. You are not required to have any
reference. Moreover, this specification should still make sense when your
references are unavailable. Examples of what you could include are:
* Links to mailing list or IRC discussions
* Links to notes from a summit session
* Links to relevant research, if appropriate
* Related specifications as appropriate
* Anything else you feel it is worthwhile to refer to

View File

@ -1,110 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. The filename in the git
repository should match the launchpad URL, for example a URL of
https://blueprints.launchpad.net/openstack-manuals/+spec/awesome-thing should
be named awesome-thing.rst . Please do not delete any of the sections in
this template. If you have nothing to say for a whole section, just write:
None For help with syntax, see http://sphinx-doc.org/rest.html
To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
=============================
The title of your blueprint
=============================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-manuals/+spec/example
Or
https://blueprints.launchpad.net/bandit/+spec/example
Introduction paragraph -- why are we doing anything?
Problem description
===================
A detailed description of the problem.
Proposed change
===============
Here is where you cover the change you propose to make in detail. How do you
propose to solve this problem?
If this is one part of a larger effort make it clear where this piece ends. In
other words, what's the scope of this effort?
Include which OpenStack security project this will apply to (OpenStack Security
Guide, OpenStack Security Notes, Bandit, etc). Also include where in the
OpenStack security project tree hierarchy this will reside.
Alternatives
------------
This is an optional section, where it does apply we'd just like a demonstration
that some thought has been put into why the proposed approach is the best one.
Implementation
==============
Assignee(s)
-----------
Who is leading the writing of the code? Or is this a blueprint where you're
throwing it out there to see who picks it up?
If more than one person is working on the implementation, please designate the
primary author and contact.
Primary assignee:
<launchpad-id or None>
Can optionally can list additional ids if they intend on doing
substantial implementation work on this blueprint.
Milestones
----------
Target Milestone for completion:
Liberty-1
Work Items
----------
Work items or tasks -- break the feature up into the things that need to be
done to implement it. Those parts might end up being done by different people,
but we're mostly trying to understand the timeline for implementation.
Dependencies
============
- Include specific references to specs and/or blueprints in openstack-manuals,
or in other projects, that this one either depends on or is related to.
- Does this feature require any new library dependencies or code otherwise not
included in OpenStack? Or does it depend on a specific version of library?
References
==========
Please add any useful references here. You are not required to have any
reference. Moreover, this specification should still make sense when your
references are unavailable. Examples of what you could include are:
* Links to mailing list or IRC discussions
* Links to notes from a summit session
* Links to relevant research, if appropriate
* Related specifications as appropriate
* Anything else you feel it is worthwhile to refer to

View File

@ -1,110 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. The filename in the git
repository should match the launchpad URL, for example a URL of
https://blueprints.launchpad.net/openstack-manuals/+spec/awesome-thing should
be named awesome-thing.rst . Please do not delete any of the sections in
this template. If you have nothing to say for a whole section, just write:
None For help with syntax, see http://sphinx-doc.org/rest.html
To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
=============================
The title of your blueprint
=============================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-manuals/+spec/example
Or
https://blueprints.launchpad.net/bandit/+spec/example
Introduction paragraph -- why are we doing anything?
Problem description
===================
A detailed description of the problem.
Proposed change
===============
Here is where you cover the change you propose to make in detail. How do you
propose to solve this problem?
If this is one part of a larger effort make it clear where this piece ends. In
other words, what's the scope of this effort?
Include which OpenStack security project this will apply to (OpenStack Security
Guide, OpenStack Security Notes, Bandit, etc). Also include where in the
OpenStack security project tree hierarchy this will reside.
Alternatives
------------
This is an optional section, where it does apply we'd just like a demonstration
that some thought has been put into why the proposed approach is the best one.
Implementation
==============
Assignee(s)
-----------
Who is leading the writing of the code? Or is this a blueprint where you're
throwing it out there to see who picks it up?
If more than one person is working on the implementation, please designate the
primary author and contact.
Primary assignee:
<launchpad-id or None>
Can optionally can list additional ids if they intend on doing
substantial implementation work on this blueprint.
Milestones
----------
Target Milestone for completion:
Liberty-1
Work Items
----------
Work items or tasks -- break the feature up into the things that need to be
done to implement it. Those parts might end up being done by different people,
but we're mostly trying to understand the timeline for implementation.
Dependencies
============
- Include specific references to specs and/or blueprints in openstack-manuals,
or in other projects, that this one either depends on or is related to.
- Does this feature require any new library dependencies or code otherwise not
included in OpenStack? Or does it depend on a specific version of library?
References
==========
Please add any useful references here. You are not required to have any
reference. Moreover, this specification should still make sense when your
references are unavailable. Examples of what you could include are:
* Links to mailing list or IRC discussions
* Links to notes from a summit session
* Links to relevant research, if appropriate
* Related specifications as appropriate
* Anything else you feel it is worthwhile to refer to

View File

@ -1,110 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. The filename in the git
repository should match the launchpad URL, for example a URL of
https://blueprints.launchpad.net/openstack-manuals/+spec/awesome-thing should
be named awesome-thing.rst . Please do not delete any of the sections in
this template. If you have nothing to say for a whole section, just write:
None For help with syntax, see http://sphinx-doc.org/rest.html
To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
=============================
The title of your blueprint
=============================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-manuals/+spec/example
Or
https://blueprints.launchpad.net/bandit/+spec/example
Introduction paragraph -- why are we doing anything?
Problem description
===================
A detailed description of the problem.
Proposed change
===============
Here is where you cover the change you propose to make in detail. How do you
propose to solve this problem?
If this is one part of a larger effort make it clear where this piece ends. In
other words, what's the scope of this effort?
Include which OpenStack security project this will apply to (OpenStack Security
Guide, OpenStack Security Notes, Bandit, etc). Also include where in the
OpenStack security project tree hierarchy this will reside.
Alternatives
------------
This is an optional section, where it does apply we'd just like a demonstration
that some thought has been put into why the proposed approach is the best one.
Implementation
==============
Assignee(s)
-----------
Who is leading the writing of the code? Or is this a blueprint where you're
throwing it out there to see who picks it up?
If more than one person is working on the implementation, please designate the
primary author and contact.
Primary assignee:
<launchpad-id or None>
Can optionally can list additional ids if they intend on doing
substantial implementation work on this blueprint.
Milestones
----------
Target Milestone for completion:
Liberty-1
Work Items
----------
Work items or tasks -- break the feature up into the things that need to be
done to implement it. Those parts might end up being done by different people,
but we're mostly trying to understand the timeline for implementation.
Dependencies
============
- Include specific references to specs and/or blueprints in openstack-manuals,
or in other projects, that this one either depends on or is related to.
- Does this feature require any new library dependencies or code otherwise not
included in OpenStack? Or does it depend on a specific version of library?
References
==========
Please add any useful references here. You are not required to have any
reference. Moreover, this specification should still make sense when your
references are unavailable. Examples of what you could include are:
* Links to mailing list or IRC discussions
* Links to notes from a summit session
* Links to relevant research, if appropriate
* Related specifications as appropriate
* Anything else you feel it is worthwhile to refer to

View File

@ -1,152 +0,0 @@
=============================
Refactored Config for Bandit
=============================
Problem Description
===================
Bandit's config file has grown in complexity and size as more testing plugins
and options have been added to the project. It has been highlighted by adopters
that maintaining a Bandit config file in each projects repository is an
undesirable pain point.
Proposed Change
===============
This proposal aims to refactor the Bandit configuration system with the aim of
removing the need to include any per project configuration files if no major
deviation from preset defaults is required. To accomplish this goal, we first
looked at the existing configuration system. The configuration file breaks down
into three main areas, and each of these will be dealt with individually.
These areas are:
1) Tunable options, used to tweak miscellaneous bits in the Bandit runtime
2) Plugin options, used to control the operation of individual test plugin
3) Profiles, used to select the desired set of test plugins to run or not
Tunable Options
---------------
A number of tunable options are provided in the Bandit config. It was
originally foreseen that these would be useful in configuring Bandit's runtime
behavior. In all practical scenarios however, these options are redundant and
remain at the default setting.
Our proposed strategy is to remove these unnecessary config options and rely on
sensible values provided by the Bandit authors.
Plugin Options
--------------
This section represents the largest block of configuration data and thus the
largest pain point for adopters. It contains a lengthy set of configuration
options for all available test plugins, without these options many plugins will
malfunction or fail to run at all. The usefulness of many plugins is also
directly dependent upon the data provided in this section of the config (e.g.
the blacklist plugins) and as such this data should be considered part of the
plugins functionality.
Our proposed strategy is to modify the plugin system to provide sensible
defaults for all configurable test plugins, directly in the plugin code. This
data can then be overridden in an external configuration only when desirable.
This removes the need for any configuration data when default functioning is
sufficient, and this should be in the majority of cases.
To accomplish this, the test plugin system will be modified to use classes for
each plugin instead of the function that is currently used. Each class will
provide one or more testing methods, equivalent to the current testing
functions, and one method to return a default configuration shared by all
testing methods provided by that class. In the default case, this configuration
data will be sent back to each test method, or it may be overridden by an
external configuration if present.
In addition to removing the need for a configuration file this approach has two
advantages. Firstly, it allows external plugins from third parties to provide
configuration data along with their plugins without the need to edit a central
default config file shipped by the Bandit project. Secondly, it allows for a
config generation tool to auto-discover all available plugins and create a
default configuration file by simply invoking the config method on each
discovered plugin class, or on some desirable subset of these.
Profiles
--------
This section is the primary concern for gate adopters, it is here that they may
select the set of plugin tests that they wish to run on their project. It is
nearly always configured as part of the initial Bandit setup.
Our proposed strategy is to provide a number of new mechanisms to indicate the
desired set of tests to run, deprecating the current situation. Firstly, we
allow profiles to be configured in their own individual files that use a much
simpler layout than than the current single config file. Secondly, we will
permit the specification of test sets directly from the command line interface
of Bandit.
The first option will allow manual users of Bandit to easily create and re-use
various test profiles that they might need to use frequently.
The second option will permit gate adopters to list their desired test set as
part of the Bandit command invocation given within their existing tox.ini file.
This has precedent and matches closely to the way PEP8 tests are currently
configured.
To further improve upon the current state of affairs, again borrowing from
hacking/flake8/pep8, Bandit will support a canonical numbering system for test
plugins. These numeric names may be used anywhere that the usual descriptive,
but often unwieldy, full test names would be used.
An example canonical scheme may look like the following
B1xx - blacklisted functions
B2xx - blacklisted imports
B3xx - injections
...
A Note On Blacklists
--------------------
As implied from the example scheme given above, each blacklisted module and
import now will also be assigned a unique identifier. The intention here is to
aid in configuration of these lengthy blacklists. So while blacklisted modules
and methods will share common logic, individual items will be distinguishable
as if they were separate tests when configuring Bandit.
Implementation
==============
See Proposed change, the indicated changes will be made to Bandit to enact the
new approach to configuration. Support for the old configuration file will
remain, but its use will be marked as deprecated and a message indicating this
will be presented to the user when utilizing the text formatted output and an
old style configuration.
Assignee(s)
-----------
The Bandit core team will lead the development of these changes.
Primary assignee:
tkelsey
tmcpeak
Milestones
----------
Target Milestone for completion:
Mitaka 3
Work Items
----------
- Strip out miscellaneous options from Bandit config
- Add a separate text formatter that includes terminal output colors, removing
the need for these to be configurable.
- Add support for external profile files.
- Convert plugins to classes which implement one or more tests and provide a
config generation function.
- Assign canonical numbers to each plugin, including blacklist modules and
imports.
- Add support for test selection via the CLI.
- Update the config generator to output default configs.
- Delete the config file bundled with Bandit.
Dependencies
============
N/A
References
==========
- https://blueprints.launchpad.net/bandit/+spec/config-change

View File

@ -1,110 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. The filename in the git
repository should match the launchpad URL, for example a URL of
https://blueprints.launchpad.net/openstack-manuals/+spec/awesome-thing should
be named awesome-thing.rst . Please do not delete any of the sections in
this template. If you have nothing to say for a whole section, just write:
None For help with syntax, see http://sphinx-doc.org/rest.html
To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
=============================
The title of your blueprint
=============================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-manuals/+spec/example
Or
https://blueprints.launchpad.net/bandit/+spec/example
Introduction paragraph -- why are we doing anything?
Problem description
===================
A detailed description of the problem.
Proposed change
===============
Here is where you cover the change you propose to make in detail. How do you
propose to solve this problem?
If this is one part of a larger effort make it clear where this piece ends. In
other words, what's the scope of this effort?
Include which OpenStack security project this will apply to (OpenStack Security
Guide, OpenStack Security Notes, Bandit, etc). Also include where in the
OpenStack security project tree hierarchy this will reside.
Alternatives
------------
This is an optional section, where it does apply we'd just like a demonstration
that some thought has been put into why the proposed approach is the best one.
Implementation
==============
Assignee(s)
-----------
Who is leading the writing of the code? Or is this a blueprint where you're
throwing it out there to see who picks it up?
If more than one person is working on the implementation, please designate the
primary author and contact.
Primary assignee:
<launchpad-id or None>
Can optionally can list additional ids if they intend on doing
substantial implementation work on this blueprint.
Milestones
----------
Target Milestone for completion:
Liberty-1
Work Items
----------
Work items or tasks -- break the feature up into the things that need to be
done to implement it. Those parts might end up being done by different people,
but we're mostly trying to understand the timeline for implementation.
Dependencies
============
- Include specific references to specs and/or blueprints in openstack-manuals,
or in other projects, that this one either depends on or is related to.
- Does this feature require any new library dependencies or code otherwise not
included in OpenStack? Or does it depend on a specific version of library?
References
==========
Please add any useful references here. You are not required to have any
reference. Moreover, this specification should still make sense when your
references are unavailable. Examples of what you could include are:
* Links to mailing list or IRC discussions
* Links to notes from a summit session
* Links to relevant research, if appropriate
* Related specifications as appropriate
* Anything else you feel it is worthwhile to refer to

View File

@ -1,110 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. The filename in the git
repository should match the launchpad URL, for example a URL of
https://blueprints.launchpad.net/openstack-manuals/+spec/awesome-thing should
be named awesome-thing.rst . Please do not delete any of the sections in
this template. If you have nothing to say for a whole section, just write:
None For help with syntax, see http://sphinx-doc.org/rest.html
To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
=============================
The title of your blueprint
=============================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-manuals/+spec/example
Or
https://blueprints.launchpad.net/bandit/+spec/example
Introduction paragraph -- why are we doing anything?
Problem description
===================
A detailed description of the problem.
Proposed change
===============
Here is where you cover the change you propose to make in detail. How do you
propose to solve this problem?
If this is one part of a larger effort make it clear where this piece ends. In
other words, what's the scope of this effort?
Include which OpenStack security project this will apply to (OpenStack Security
Guide, OpenStack Security Notes, Bandit, etc). Also include where in the
OpenStack security project tree hierarchy this will reside.
Alternatives
------------
This is an optional section, where it does apply we'd just like a demonstration
that some thought has been put into why the proposed approach is the best one.
Implementation
==============
Assignee(s)
-----------
Who is leading the writing of the code? Or is this a blueprint where you're
throwing it out there to see who picks it up?
If more than one person is working on the implementation, please designate the
primary author and contact.
Primary assignee:
<launchpad-id or None>
Can optionally can list additional ids if they intend on doing
substantial implementation work on this blueprint.
Milestones
----------
Target Milestone for completion:
Liberty-1
Work Items
----------
Work items or tasks -- break the feature up into the things that need to be
done to implement it. Those parts might end up being done by different people,
but we're mostly trying to understand the timeline for implementation.
Dependencies
============
- Include specific references to specs and/or blueprints in openstack-manuals,
or in other projects, that this one either depends on or is related to.
- Does this feature require any new library dependencies or code otherwise not
included in OpenStack? Or does it depend on a specific version of library?
References
==========
Please add any useful references here. You are not required to have any
reference. Moreover, this specification should still make sense when your
references are unavailable. Examples of what you could include are:
* Links to mailing list or IRC discussions
* Links to notes from a summit session
* Links to relevant research, if appropriate
* Related specifications as appropriate
* Anything else you feel it is worthwhile to refer to

20
tox.ini
View File

@ -1,20 +0,0 @@
[tox]
minversion = 3.1.0
envlist = docs,py36
ignore_basepython_conflict = True
skipsdist = True
[testenv]
basepython = python3
usedevelop = True
deps = -r{toxinidir}/requirements.txt
[testenv:pep8]
commands = doc8 -e .rst specs/ doc/ README.rst
[testenv:venv]
commands = {posargs}
[testenv:docs]
commands =
sphinx-build -a -W -b html doc/source doc/build/html