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:
parent
b3dcc7a310
commit
f8c36fa518
|
@ -1,18 +0,0 @@
|
||||||
.DS_Store
|
|
||||||
|
|
||||||
AUTHORS
|
|
||||||
ChangeLog
|
|
||||||
build
|
|
||||||
.tox
|
|
||||||
.venv
|
|
||||||
*.egg*
|
|
||||||
*.swp
|
|
||||||
*.swo
|
|
||||||
*.pyc
|
|
||||||
.testrepository
|
|
||||||
|
|
||||||
# Editors
|
|
||||||
*~
|
|
||||||
.*.swp
|
|
||||||
.bak
|
|
||||||
/.project
|
|
|
@ -1,9 +0,0 @@
|
||||||
- project:
|
|
||||||
templates:
|
|
||||||
- openstack-specs-jobs
|
|
||||||
check:
|
|
||||||
jobs:
|
|
||||||
- openstack-tox-pep8
|
|
||||||
gate:
|
|
||||||
jobs:
|
|
||||||
- openstack-tox-pep8
|
|
3
LICENSE
3
LICENSE
|
@ -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
|
|
62
README.rst
62
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
|
OpenStack Security Specifications
|
||||||
======================================
|
======================================
|
||||||
|
|
||||||
This git repository is used to hold approved design specifications for
|
This project is no longer maintained.
|
||||||
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.
|
|
||||||
|
|
||||||
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>/
|
For any further questions, please email
|
||||||
|
openstack-discuss@lists.openstack.org or join #openstack-dev on
|
||||||
You can find an example spec in `doc/source/specs/template.rst`.
|
OFTC.
|
||||||
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/.
|
|
||||||
|
|
|
@ -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}
|
|
|
@ -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
|
|
|
@ -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`
|
|
||||||
|
|
|
@ -1 +0,0 @@
|
||||||
.. include:: ../../README.rst
|
|
|
@ -1 +0,0 @@
|
||||||
../../specs
|
|
|
@ -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
|
|
21
setup.cfg
21
setup.cfg
|
@ -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
|
|
||||||
|
|
21
setup.py
21
setup.py
|
@ -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)
|
|
|
@ -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
|
|
|
@ -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
|
|
|
@ -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
|
|
|
@ -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
|
|
|
@ -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
|
|
|
@ -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
|
|
|
@ -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
|
|
|
@ -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
20
tox.ini
|
@ -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
|
|
Loading…
Reference in New Issue