Rework and security policy.

CHANGES.rst

@@ -1,10 +1,24 @@
 Changelog
 =========
 
-v0.1.0
-------
+**debops-policy**
 
-*Unreleased*
+This project adheres to `Semantic Versioning <http://semver.org/spec/v2.0.0.html>`_
+and `human-readable changelog <http://keepachangelog.com/>`_.
+
+The current repository maintainer is drybjed.
+
+
+debops-policy v0.1.0 - unreleased
+---------------------------------
+
+Changed
+~~~~~~~
+
+- Use RFC2119 and ISO 8601 for the code signing policy. [ypid]
+
+Added
+~~~~~
 
 - Updated the repository layout to be compatible with the rest of the DebOps
   documentation. [drybjed]
@@ -13,3 +27,4 @@ v0.1.0
   development model, as well a draft of the code signing policy used by the
   project. [drybjed, ypid]
 
+- Wrote initial security policy. [ypid]

COPYRIGHT

@@ -0,0 +1,12 @@
+debops-policy - Documents related to the DebOps project policies and guidelines
+
+Copyright (C) 2015-2016 Maciej Delmanowski <[email protected]>
+Copyright (C) 2016 Robin Schneider <[email protected]>
+Copyright (C) 2015-2016 DebOps Project http://debops.org/
+
+This documentation is part of DebOps.
+
+This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
+International License. To view a copy of this license, visit
+http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to Creative
+Commons, PO Box 1866, Mountain View, CA 94042, USA.

docs/code-signing.rst

@@ -1,38 +1,36 @@
 Code signing policy
 ===================
 
+Code signing policy version: 0.1.0
+
 The configuration management code and other source code used by the DebOps
-Project and committed to its repositories [#debops-org]_ must be signed by a
-valid PGP key of a DebOps Developer. This does not yet apply to contributors
-(but is highly encouraged).
+Project and committed to its repositories [#debops-org]_ MUST be signed by a
+valid PGP key of a DebOps Developer. For contributors it is RECOMMENDED to do
+the same.
 
-Patches from DebOps Contributors must be reviewed by one of the
-DebOps Developers and the merge commit must by signed by the DebOps Developer
+Patches from DebOps Contributors MUST be reviewed by one of the
+DebOps Developers and the merge commit MUST by signed by the DebOps Developer
 for this patch to enter the DebOps Project. This should ensure that the last
 commit of every repository of the DebOps Project has a valid signature by a
 DebOps Developer.
 
 To proof that DebOps Developers and DebOps Contributors have full control over
 their account on the source code management platform used to work on the DebOps
-Project (currently GitHub) it is expected to provide a proof via the means of
+Project (currently GitHub) it RECOMMENDED to provide a proof via the means of
 https://keybase.io/.
 
-Additionally, it is recommended to take part in the Web Of Trust to make
+Additionally, it is RECOMMENDED to take part in the Web Of Trust to make
 it harder for an adversary to fake signatures by pretending to be one of the
-DebOps Developers. In particular as the DebOps Project is related to the Debian
-project it is recommended to get your key signed by Debian Developers.
+DebOps Contributors or Developers. In particular as the DebOps Project is related to the Debian
+Project it is RECOMMENDED to get your key signed by Debian Developers.
 A signature from another DebOps Developer is sufficient as well.
 
 This should allow for secure code authentication. That means that tampering
 with the code on the source code management platform can be reliable detected
-by DebOps tools, DebOps Developers and all of the users of the project and thus
-the integrity of the project does not rely on centralized parties anymore.
+by DebOps tools, DebOps Developers and all of the users of the Project and thus
+the integrity of the Project does not rely on centralized parties anymore.
 Additionally, this ensures a trusted audit trail.
 
-This rule takes effect for DebOps Developer on **1st September 2016**.
-
-DebOps Contributors are expected to sign their work after **1st September 2018**. Before this date, it is highly encouraged.
-
 For background about this refer to:
 
 * `A Git Horror Story: Repository Integrity With Signed Commits <https://mikegerwitz.com/papers/git-horror-story.html>`_
@@ -41,3 +39,21 @@ For background about this refer to:
 
 .. [#debops-org] All repositories in the DebOps core project currently hosted at: https://github.com/debops/.
    This does not apply for `DebOps Contrib <https://github.com/debops-contrib/>`_.
+
+Policy enforcement schedule
+---------------------------
+
++---------+-----------------+
+| Version | Takes effect on |
++=========+=================+
+| 0.1.0   | 2016-09-01      |
++---------+-----------------+
+| 0.2.0   | 2018-09-01      |
++---------+-----------------+
+
+Planed changes
+--------------
+
+.. versionadded:: 0.2.0
+
+   * DebOps Contributors MUST sign their work.

docs/copyright.rst

@@ -1,22 +1,5 @@
 Copyright
 =========
 
-::
-
-    Copyright (C) 2015 Maciej Delmanowski <[email protected]>
-    Copyright (C) 2015 DebOps Project http://debops.org/
-
-    This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
-    International License. To view a copy of this license, visit
-    http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to Creative
-    Commons, PO Box 1866, Mountain View, CA 94042, USA.
-
-Credits
--------
-
-* Maciej Delmanowski <drybjed_at_gmail.com>
-
-  * creator of the DebOps Project
-
-  * current project maintainer
+.. literalinclude:: ../COPYRIGHT
 

docs/distributed-development.rst

@@ -10,8 +10,7 @@ without a single point of failure.
 
 The GnuPG software, along with it's Web Of Trust is used for user
 authentication and authorization. A special ``git`` repository,
-``debops-keyring`` contains the ``gpg`` keyrings with the set of current Developers,
-Project Leader and Contributors keys which can be used for code authentication.
-SSH keys derived from these GPG keys allow access to the Project's assets as
-needed.
-
+`debops-keyring <https://github.com/debops/debops-keyring>`_ contains the
+``gpg`` keyrings with the set of current Developers, Project Leader and
+Contributors keys which can be used for code authentication.  SSH keys derived
+from these GPG keys allow access to the Project's assets as needed.

docs/index.rst

@@ -10,6 +10,7 @@ DebOps Policy and Guidelines
    organizational-structure
    distributed-development
    code-signing
+   security-policy
    references
    copyright
    changelog

docs/introduction.rst

@@ -2,10 +2,10 @@ Introduction
 ============
 
 This document describes the computer systems, networks, services and other
-elements of the data cneter environment deployed and managed by the DebOps
+elements of the data center environment deployed and managed by the DebOps
 Project software.
 
-The software and applications written by the DebOps Project is used in many
+The software and applications written by the DebOps Project are used in many
 different environments and different contexts. Here you will find documentation
 which describes common elements of such environments. This document is written
 in hopes that it can be used to guide the development of the Project in the
@@ -15,6 +15,14 @@ At the moment this document is only a draft and does not reflect the current
 state of the DebOps Project. You should read the list of references to get
 a better idea of what the Project might look like and behave in the future.
 
+Terminology
+-----------
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in BCP 14, [`RFC2119
+<https://tools.ietf.org/html/rfc2119>`_].
+
 ..
  Local Variables:
  mode: rst

docs/organizational-structure.rst

@@ -24,7 +24,7 @@ last word in any issues that arise withing the project and his decisions are
 final. The Leader creates the version tags in the ``git`` repositories signed
 by his/her GPG key.
 
-The UNIX group for DebOps Leader used on the project assets should be named
+The UNIX group for the DebOps Leader used on the project assets should be named
 ``debops-leader``.
 
 Contributors

docs/security-policy.rst

@@ -0,0 +1,91 @@
+Security policy
+===============
+
+.. Based on: https://www.openssl.org/docs/faq.html#BUILD19
+   Based on: http://rubyonrails.org/security/
+             A: Only legacy HTTP?
+   See also: https://security.stackexchange.com/q/34871
+
+   Big parts of the policy have been copied from http://rubyonrails.org/security/.
+   Thus, this file is licensed under MIT.
+
+   Copyright (c) 2016 http://rubyonrails.org
+   Copyright (C) 2016 Robin Schneider <[email protected]>
+   Copyright (C) 2016 DebOps Project http://debops.org/
+
+   Permission is hereby granted, free of charge, to any person obtaining a copy
+   of this software and associated documentation files (the "Software"), to
+   deal in the Software without restriction, including without limitation the
+   rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+   sell copies of the Software, and to permit persons to whom the Software is
+   furnished to do so, subject to the following conditions:
+
+   The above copyright notice and this permission notice shall be included in
+   all copies or substantial portions of the Software.
+
+   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+   FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+   AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+   LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+   FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+   IN THE SOFTWARE.
+
+Reporting a vulnerability
+-------------------------
+
+If you think your bug has security implications then please send it to the
+Project Leader (Maciej Delmanowski <[email protected]>) and additionally to
+the maintainers of the affected part of the project.
+If you can fix the vulnerability (or have already done so) please consider
+attaching a patch.
+If you wish to use PGP to send
+in a report please use one or more of the keys of the team members listed at
+`debops-keyring <https://github.com/debops/debops-keyring>`_.
+
+Disclosure process
+------------------
+
+#. Security report received and is assigned a primary handler. This person will
+   coordinate the fix and release process. Problem is confirmed and a list of
+   all affected versions is determined. Code is audited to find any potential
+   similar problems.
+
+#. Fixes are prepared for all releases which are still supported. These fixes
+   are not committed to the public repository but rather held locally pending
+   the announcement.
+#. A suggested embargo date for this vulnerability is chosen and potential
+   downstream projects of DebOps are notified. This notification will include
+   patches for all versions still under support and a contact address for
+   packagers who need advice backporting patches to older versions.
+#. On the embargo date, the debops-security list is sent a copy of the
+   announcement. The changes are pushed to the public repository and affected
+   parts of the project are released. Additionally, an GitHub issue is opened
+   against the affected repository on GitHub with the intend to inform people
+   watching the repository.
+
+This process can take some time, especially when coordination is required with
+maintainers of other projects. Every effort will be made to handle the bug in
+as timely a manner as possible, however it’s important that we follow the
+release process above to ensure that the disclosure is handled in a consistent
+manner.
+
+Receiving disclosures
+---------------------
+
+The best way to receive all the security announcements is to subscribe to the
+`DebOps security mailing list
+<https://lists.debops.org/mailman/listinfo/debops-security>`_. The mailing list
+is very low traffic, and it receives the public notifications the moment the
+embargo is lifted. If you produce packages of DebOps and require prior
+notification of vulnerabilities, you should get in touch with the DebOps Project.
+
+No one outside the core team, the initial reporter or downstream projects will be
+notified prior to the lifting of the embargo. We regret that we cannot make
+exceptions to this policy for high traffic or important sites, as any
+disclosure beyond the minimum required to coordinate a fix could cause an early
+leak of the vulnerability.
+
+If you have any suggestions to improve this policy, please get in touch for
+example via
+the `debops-policy repository on GitHub <https://github.com/debops/debops-policy>`_.