diff --git a/.gitignore b/.gitignore deleted file mode 100644 index a310ca9..0000000 --- a/.gitignore +++ /dev/null @@ -1,18 +0,0 @@ -.DS_Store - -AUTHORS -ChangeLog -build -.tox -.venv -*.egg* -*.swp -*.swo -*.pyc -.testrepository - -# Editors -*~ -.*.swp -.bak -/.project diff --git a/.zuul.yaml b/.zuul.yaml deleted file mode 100644 index 962d878..0000000 --- a/.zuul.yaml +++ /dev/null @@ -1,9 +0,0 @@ -- project: - templates: - - openstack-specs-jobs - check: - jobs: - - openstack-tox-pep8 - gate: - jobs: - - openstack-tox-pep8 diff --git a/LICENSE b/LICENSE deleted file mode 100644 index 75a29c4..0000000 --- a/LICENSE +++ /dev/null @@ -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 diff --git a/README.rst b/README.rst index 5117500..d64ae75 100644 --- a/README.rst +++ b/README.rst @@ -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// - -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/` 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. diff --git a/doc/source/conf.py b/doc/source/conf.py deleted file mode 100755 index 831976f..0000000 --- a/doc/source/conf.py +++ /dev/null @@ -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} diff --git a/doc/source/contributing.rst b/doc/source/contributing.rst deleted file mode 100644 index d83e94b..0000000 --- a/doc/source/contributing.rst +++ /dev/null @@ -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 diff --git a/doc/source/index.rst b/doc/source/index.rst deleted file mode 100644 index e2d87c3..0000000 --- a/doc/source/index.rst +++ /dev/null @@ -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 - Specification Template - contributing - - -Indices and tables -================== - -* :ref:`search` - diff --git a/doc/source/readme.rst b/doc/source/readme.rst deleted file mode 100644 index a6210d3..0000000 --- a/doc/source/readme.rst +++ /dev/null @@ -1 +0,0 @@ -.. include:: ../../README.rst diff --git a/doc/source/specs b/doc/source/specs deleted file mode 120000 index 87a4030..0000000 --- a/doc/source/specs +++ /dev/null @@ -1 +0,0 @@ -../../specs \ No newline at end of file diff --git a/requirements.txt b/requirements.txt deleted file mode 100644 index f0f1b8d..0000000 --- a/requirements.txt +++ /dev/null @@ -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 diff --git a/setup.cfg b/setup.cfg deleted file mode 100644 index e82a1d5..0000000 --- a/setup.cfg +++ /dev/null @@ -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 - diff --git a/setup.py b/setup.py deleted file mode 100644 index f63cc23..0000000 --- a/setup.py +++ /dev/null @@ -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) diff --git a/specs/kilo/anchor/seperate-validator-functionality.rst b/specs/kilo/anchor/seperate-validator-functionality.rst deleted file mode 100644 index 7789d45..0000000 --- a/specs/kilo/anchor/seperate-validator-functionality.rst +++ /dev/null @@ -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 diff --git a/specs/liberty/anchor/template.rst b/specs/liberty/anchor/template.rst deleted file mode 100644 index e62f617..0000000 --- a/specs/liberty/anchor/template.rst +++ /dev/null @@ -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: - - -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 diff --git a/specs/liberty/bandit/template.rst b/specs/liberty/bandit/template.rst deleted file mode 100644 index e62f617..0000000 --- a/specs/liberty/bandit/template.rst +++ /dev/null @@ -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: - - -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 diff --git a/specs/liberty/ossn/template.rst b/specs/liberty/ossn/template.rst deleted file mode 100644 index e62f617..0000000 --- a/specs/liberty/ossn/template.rst +++ /dev/null @@ -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: - - -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 diff --git a/specs/liberty/security-guide/template.rst b/specs/liberty/security-guide/template.rst deleted file mode 100644 index e62f617..0000000 --- a/specs/liberty/security-guide/template.rst +++ /dev/null @@ -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: - - -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 diff --git a/specs/mitaka/bandit/config-change.rst b/specs/mitaka/bandit/config-change.rst deleted file mode 100644 index 97a1b95..0000000 --- a/specs/mitaka/bandit/config-change.rst +++ /dev/null @@ -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 diff --git a/specs/mitaka/killick/template.rst b/specs/mitaka/killick/template.rst deleted file mode 100644 index e62f617..0000000 --- a/specs/mitaka/killick/template.rst +++ /dev/null @@ -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: - - -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 diff --git a/specs/template.rst b/specs/template.rst deleted file mode 100644 index e62f617..0000000 --- a/specs/template.rst +++ /dev/null @@ -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: - - -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 diff --git a/tox.ini b/tox.ini deleted file mode 100644 index d22a4a4..0000000 --- a/tox.ini +++ /dev/null @@ -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