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