Merge branch 'dev' into 'master'

Security

See merge request !4

SECURITY/README.md

+## TODO
+
+* Create <opensource-security@ieee.org>
+* Determine how we will obtain CVE numbers
+
+We encourage you to use or adapt our SECURITY.md template. The
+following outlines the general security process for all Official IEEE
+Open Source Projects.
+
+## Security process
+
+All Official IEEE Open Source Projects should follow the following
+security reporting process. 
+
+1. Security vulnerabilities are reported to
+   <opensource-security@ieee.org>. Security reports are confidential.
+
+2. The Open Source Community Manager will contact the *security
+   contact* listed by the Official IEEE Open Source Project and ensure
+   that the security vulnerability is reviewed to determine if it is
+   accepted or rejected. You may choose to list the maintainer that is
+   the appropraite security contact on your project (such as in your
+   SECURITY.md page) or you may provide the contact (or list of
+   contacts) to the Open Source Community Manager to maintain
+   privately.
+
+3. The Open Source Community Manager will notify the reporter if their
+   report has been accepted or rejected
+
+4. If a report is accepted the following protocol shall be followed: 
+
+  a. The Open Source Community Manager will determine if a CVE number
+     should be obtained, and if so, IEEE shall obtain a CVE number.
+
+  b. The project will patch the vulernability and stage a release and
+     draft a short announcement that includes the CVE number,
+     severity, and impact.
+
+  c. The Open Source Community Manager will review the release and
+     announcement and coordinate to schedule a date and time for
+     public releaes. At this time, your project may discuss with the
+     Open Source Community Manager any private disclosures you wish to
+     make in advance of the public disclosure, such as to the reporter
+     of the vulernability or to any identified stakeholders. The Open
+     Source Community Manager will only deny requests if there are any
+     suspicion that permitting such a request would violate IEEE
+     Policy or if the private disclosure would in effect be equivalent
+     of making a public disclosure.
+
+  d. The release shall be made as it normally would, but without
+     disclosing that it is patching a security vulnerability.
+
+  e. The release shall be timed so that a release announcement will be
+     sent out to immediately after the release. The announcement shall
+     go out to all relevant security announcement mailing lists as
+     well as any external security lists or portals the Open Source
+     Community Manager deems appropriate (e.g.,
+     oss-security@lists.openwall.com).
+
+5. If a report is accepted and this project is also an IEEE Standard
+   that incorporates an IEEE Open Source Project, then the additional
+   standards protocol will be followed as well.
+
+  a. If the project is incorporated through an undated/unversioned
+     reference, then the above protocol suffices with the caveat that
+     there may be additional mailing list or forums where the
+     announcement will be posted.
+
+  b. If the project is incorporated through a versioned reference,
+     then it must be determined if it is an errata or corrigenda. If
+     it is an errata, the above protocol shall be followed with the
+     announcement timed to coincide with the errata. If a corrigenda
+     is required, then the above protocol shall be followed and the
+     corrigenda process shall be followed after the announcement is
+     made, and additional notices shall be placed on apporpriate
+     places warning users about the issue.
+

SECURITY/SECURITY.md

+## TODO
+
+* Create <opensource-security@ieee.org>
+* Determine how we will obtain CVE numbers
+
+You may choose to adapt our standard template or to construct your own
+security process documentation. In all cases, your documentation
+should be inline with the following process.
+
+## Security Reporting
+
+If you wish to report a security vulnerability -- thank you! -- we ask
+that you follow the following process, which complies with the Open
+Source Committee Maintainers Manual.
+
+Please fill out the following template:
+
+Please report security vulnerabilities by filling out the following template:
+
+* PROJECT: A URL to project's repository
+* PUBLIC: Please let us know if this vulnerability has been made or discussed publicly already, and if so, please let us know where. 
+* DESCRIPTION: Please provide precise description of the security vulnerability you have found with as much information as you are able and willing to provide.
+
+Please send the above info, along with any other information you feel
+is pertinant to: <opensource-security@ieee.org>.
+
+In addition, you may request that the project provide you a patched
+release in advance of the release announcement, however, we can not
+gaurantee that such information will be provided to you in advance of
+the public release and announcement. However ,the Open Source
+Community Manager will email you at the same time the public
+announcement is made.
+
+The IEEE SA Open Source Community Manager will let you know within two
+business weeks whether or not your report has been accepted or
+rejected. We ask that you please keep the report confidential until we
+have made a public announcement.
+