<div class="contents">
<div class="textblock"><p ><a href="https://github.com/libcgroup/libcgroup">https://github.com/libcgroup/libcgroup</a></p>
<p >This document describes the processes through which sensitive security relevant bugs can be responsibly disclosed to the libcgroup project and how the project maintainers should handle these reports. Just like the other libcgroup process documents, this document should be treated as a guiding document and not a hard, unyielding set of regulations; the bug reporters and project maintainers are encouraged to work together to address the issues as best they can, in a manner which works best for all parties involved.</p>
-<h2><a class="anchor" id="autotoc_md25"></a>
+<h2><a class="anchor" id="autotoc_md26"></a>
Reporting Problems</h2>
<p >Problems with the libcgroup library that are not suitable for immediate public disclosure should be emailed to the current libcgroup maintainers; see below. We typically request at most a 90 day time period to address the issue before it is made public, but we will make every effort to address the issue as quickly as possible and shorten the disclosure window.</p>
<ul>
<li>Dhaval Giani, <a href="#" onclick="location.href='mai'+'lto:'+'dha'+'va'+'l.g'+'ia'+'ni@'+'gm'+'ail'+'.c'+'om'; return false;">dhava<span class="obfuscator">.nosp@m.</span>l.gi<span class="obfuscator">.nosp@m.</span>ani@g<span class="obfuscator">.nosp@m.</span>mail<span class="obfuscator">.nosp@m.</span>.com</a></li>
<li>Tom Hromatka, <a href="#" onclick="location.href='mai'+'lto:'+'tom'+'.h'+'rom'+'at'+'ka@'+'or'+'acl'+'e.'+'com'; return false;">tom.h<span class="obfuscator">.nosp@m.</span>roma<span class="obfuscator">.nosp@m.</span>tka@o<span class="obfuscator">.nosp@m.</span>racl<span class="obfuscator">.nosp@m.</span>e.com</a></li>
</ul>
-<h2><a class="anchor" id="autotoc_md26"></a>
+<h2><a class="anchor" id="autotoc_md27"></a>
Resolving Sensitive Security Issues</h2>
<p >Upon disclosure of a bug, the maintainers should work together to investigate the problem and decide on a solution. In order to prevent an early disclosure of the problem, those working on the solution should do so privately and outside of the traditional libcgroup development practices. One possible solution to this is to leverage the GitHub "Security" functionality to create a private development fork that can be shared among the maintainers, and optionally the reporter. A placeholder GitHub issue may be created, but details should remain extremely limited until such time as the problem has been fixed and responsibly disclosed. If a CVE, or other tag, has been assigned to the problem, the GitHub issue title should include the vulnerability tag once the problem has been disclosed.</p>
-<h2><a class="anchor" id="autotoc_md27"></a>
+<h2><a class="anchor" id="autotoc_md28"></a>
Public Disclosure</h2>
<p >Whenever possible, responsible reporting and patching practices should be followed, including notification to the linux-distros and oss-security mailing lists.</p>
<ul>
<div class="textblock"><p ><a href="https://github.com/libcgroup/libcgroup">https://github.com/libcgroup/libcgroup</a></p>
<p >This is the process that should be followed when creating a new libcgroup release.</p>
<h3><a class="anchor" id="autotoc_md9"></a>
-1. Verify that all issues assigned to the release milestone have been resolved</h3>
+1. Update the libcgroup-tests submodule</h3>
+<pre class="fragment"># ./bootstrap.sh
+# git submodule update --remote tests
+# git add tests
+# git commit -s
+# git push
+</pre> <h3><a class="anchor" id="autotoc_md10"></a>
+2. Verify that all issues assigned to the release milestone have been resolved</h3>
<ul>
<li><a href="https://github.com/libcgroup/libcgroup/milestones">https://github.com/libcgroup/libcgroup/milestones</a></li>
</ul>
-<h3><a class="anchor" id="autotoc_md10"></a>
-2. Verify that the Github Actions are all passing</h3>
<h3><a class="anchor" id="autotoc_md11"></a>
-3. Verify that the bundled test suite runs without error</h3>
+3. Verify that the Github Actions are all passing</h3>
+<h3><a class="anchor" id="autotoc_md12"></a>
+4. Verify that the bundled test suite runs without error</h3>
<pre class="fragment"># ./bootstrap.sh
# make check
-</pre> <h3><a class="anchor" id="autotoc_md12"></a>
-4. Verify that the packaging is correct</h3>
-<pre class="fragment"># make distcheck
</pre> <h3><a class="anchor" id="autotoc_md13"></a>
-5. Perform any distribution test builds</h3>
+5. Verify that the packaging is correct</h3>
+<pre class="fragment"># make distcheck
+</pre> <h3><a class="anchor" id="autotoc_md14"></a>
+6. Perform any distribution test builds</h3>
<ul>
<li>Oracle Linux</li>
<li>Fedora Rawhide</li>
<li>Red Hat Enterprise Linux</li>
<li>etc.</li>
</ul>
-<h3><a class="anchor" id="autotoc_md14"></a>
-6. If any problems were found up to this point that resulted in code changes, restart the process</h3>
<h3><a class="anchor" id="autotoc_md15"></a>
-7. If this is a new major/minor release, create new 'release-X.Y' branch</h3>
+7. If any problems were found up to this point that resulted in code changes, restart the process</h3>
+<h3><a class="anchor" id="autotoc_md16"></a>
+8. If this is a new major/minor release, create new 'release-X.Y' branch</h3>
<pre class="fragment"># git branch "release-X.Y"
-</pre> <h3><a class="anchor" id="autotoc_md16"></a>
-8. Update the version number in configure.ac AC_INIT(...) macro</h3>
-<h3><a class="anchor" id="autotoc_md17"></a>
-9. Tag the release in the local repository with a signed tag</h3>
+</pre> <h3><a class="anchor" id="autotoc_md17"></a>
+9. Update the version number in configure.ac AC_INIT(...) macro</h3>
+<h3><a class="anchor" id="autotoc_md18"></a>
+10. Tag the release in the local repository with a signed tag</h3>
<pre class="fragment"># git tag -s -m "version X.Y.Z" vX.Y.Z
-</pre> <h3><a class="anchor" id="autotoc_md18"></a>
-10. Build final release tarball</h3>
+</pre> <h3><a class="anchor" id="autotoc_md19"></a>
+11. Build final release tarball</h3>
<pre class="fragment"># make clean
# ./bootstrap.sh
# make dist-gzip
-</pre> <h3><a class="anchor" id="autotoc_md19"></a>
-11. Verify the release tarball in a separate directory</h3>
+</pre> <h3><a class="anchor" id="autotoc_md20"></a>
+12. Verify the release tarball in a separate directory</h3>
<pre class="fragment"><unpack the release tarball in a temporary directory>
# ./configure --sysconfdir=/etc --localstatedir=/var \
--enable-opaque-hierarchy="name=systemd" --enable-python
# make check
-</pre> <h3><a class="anchor" id="autotoc_md20"></a>
-12. Generate a checksum for the release tarball</h3>
-<pre class="fragment"># sha256sum <tarball> > libcgroup-X.Y.Z.tar.gz.SHA256SUM
</pre> <h3><a class="anchor" id="autotoc_md21"></a>
-13. GPG sign the release tarball and checksum using the maintainer's key</h3>
+13. Generate a checksum for the release tarball</h3>
+<pre class="fragment"># sha256sum <tarball> > libcgroup-X.Y.Z.tar.gz.SHA256SUM
+</pre> <h3><a class="anchor" id="autotoc_md22"></a>
+14. GPG sign the release tarball and checksum using the maintainer's key</h3>
<pre class="fragment"># gpg --armor --detach-sign libcgroup-X.Y.Z.tar.gz
# gpg --clearsign libcgroup-X.Y.Z.tar.gz.SHA256SUM
-</pre> <h3><a class="anchor" id="autotoc_md22"></a>
-14. Push the release tag to the main GitHub repository</h3>
-<pre class="fragment"># git push <repo> vX.Y.Z
</pre> <h3><a class="anchor" id="autotoc_md23"></a>
-15. Create a new GitHub release using the associated tag and upload the following files</h3>
+15. Push the release tag to the main GitHub repository</h3>
+<pre class="fragment"># git push <repo> vX.Y.Z
+</pre> <h3><a class="anchor" id="autotoc_md24"></a>
+16. Create a new GitHub release using the associated tag and upload the following files</h3>
<ul>
<li>libcgroup-X.Y.Z.tar.gz</li>
<li>libcgroup-X.Y.Z.tar.gz.asc</li>
<li>libcgroup-X.Y.Z.tar.gz.SHA256SUM</li>
<li>libcgroup-X.Y.Z.tar.gz.SHA256SUM.asc</li>
</ul>
-<h3><a class="anchor" id="autotoc_md24"></a>
-16. Update the GitHub release notes for older releases which are now unsupported</h3>
+<h3><a class="anchor" id="autotoc_md25"></a>
+17. Update the GitHub release notes for older releases which are now unsupported</h3>
<p >The following Markdown text is suggested at the top of the release note, see old GitHub releases for examples.</p>
<div class="fragment"><div class="line">***This release is no longer supported upstream, please use a more recent release***</div>
</div><!-- fragment --> </div></div><!-- contents -->
projects / thirdparty / libcgroup.git / commitdiff
