..
   This file was generated from SECURITY.md by docs/Makefile.am.
   Do not edit directly.

PRRTE Security Policy
=====================

Historically, PRRTE (and the runtimes it descends from) operated entirely at
the user level in relatively controlled environments — the typical
high-performance computing cluster embedded in a protected network, and thus
not exposed to the general Internet. That situation has evolved over time,
especially with the advent of containers inside which users operate as "root".
As a result, PRRTE daemons now sometimes find themselves
communicating between entities at different privilege levels (e.g., between a
DVM running as root and a client/tool running as a user), and the head
node a ``prte`` process runs on sometimes has a direct connection to more
exposed networks.

The PRRTE community takes the security of its runtime seriously, recognizing
that our ability to respond to concerns is bound by our limited access to
volunteer resources. We deeply appreciate coordinated efforts done in
partnership with our reporters, as these have the highest probability of a
successful and satisfactory resolution. Reports that simply state something is
wrong while providing no assistance in triaging the problem or developing the
solution will be treated seriously, but with correspondingly longer response
times.

PRRTE does not have formal, contractual relationships with its users. Instead,
we have informal relationships with downstream packagers (e.g., Debian,
Fedora, SUSE), resource managers (e.g., Slurm, PBS, PALS), and libraries
(e.g., Open MPI, OpenSHMEM). This quite frequently takes the form of
individual rather than organizational contacts. It is therefore not possible
for the PRRTE community to offer any guarantee as to the breadth or immediacy
of notification for security issues.

While we recognize that reporters may have a preferred process for dealing
with security-related issues, our limited available resources restricts us
to the somewhat informal process described below. We appreciate your
understanding.

Reporting a vulnerability
-------------------------

**Report potential security issues privately, through GitHub, using the
"Report a vulnerability" form:**

   https://github.com/openpmix/prrte/security/advisories/new

You can also reach the form from the repository's **Security** tab: choose
**Report a vulnerability** under *Advisories*. GitHub's own instructions for
this are at
https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately.

This opens a private conversation visible only to you and the PRRTE
maintainers. Please do **not** open a public GitHub issue, post to a mailing
list, or submit a public pull request for a suspected vulnerability before we
have had a chance to respond — a pull request is public the moment it exists,
including its diff and its commit messages.

A report is most useful when it contains:

* the output of ``prte_info --all`` from the affected build, or, failing that,
  the PRRTE version, how it was configured, and the PMIx, hwloc, and libevent
  versions it was built against;

* the environment: operating system, resource manager, and whether the DVM was
  started by a user, by a system daemon, or as root;

* a minimal reproducer — the command lines, hostfile, and any MCA parameters
  needed to demonstrate the problem;

* what an attacker gains, and what access they need to begin with (unprivileged
  local account on a compute node, a different user on the head node, an
  unauthenticated peer on the network, and so on);

* any suggested fix, and how you would like to be credited — the commit
  that carries the fix is where that credit appears.

What happens after you report
-----------------------------

We handle vulnerabilities with the same small, volunteer-driven process we use
for every other defect, because that is what our resources support. In
particular, **PRRTE does not operate a formal notification, embargo, and
private-release procedure.** We are not able to maintain a vetted list of
embargoed consumers, coordinate a multi-party disclosure timetable, or produce
private pre-release tarballs, and we would rather say so plainly than promise
a process we cannot execute.

What we do instead:

1. **Triage in the private advisory thread.** We work with you to confirm the
   issue, understand its scope, and judge its severity. Expect questions; the
   conversation stays private throughout.

2. **Develop the fix on a private branch.** Work proceeds out of public view,
   so the defect is not advertised by its own repair. We may ask you to review
   or test a candidate patch.

3. **Ship the fix in the next release.** The fix merges to the supported
   branch and is included in the next release of that series. PRRTE releases
   are infrequent and are driven primarily by accumulated bug fixes, so a fix
   may sit on the branch for some time before a release carries it. A
   sufficiently severe issue can prompt a release sooner than the normal
   rhythm, but we cannot commit in advance to a schedule.

If the reported behavior turns out not to be a vulnerability, we will say so
and explain why, and — where there is a real defect underneath it — move the
discussion to a public issue and fix it there like any other bug.

Supported versions
------------------

Support for PRRTE is limited to infrequent releases driven primarily by
collected bug fixes.

.. list-table::
   :header-rows: 1

   * - Series
     - Status
   * - v5.0.x
     - Supported once released — fixes land here
   * - earlier series
     - End of life; no fixes, including security fixes


**Fixes are not backported to earlier release series.** If you are running an
older series, the remedy for a security issue is to upgrade. Note also that
every process in a DVM must come from the same PRRTE build: upgrading means
installing one new build and ensuring every node reaches that installation —
there is no supported way to mix versions within a DVM. See
`Software Version Numbers <https://docs.prrte.org/en/latest/versions.html>`_.

Scope
-----

This policy covers PRRTE itself — the ``prte``, ``prted``, ``prun``, ``pterm``, and
``prte_info`` executables and the code in this repository.

Issues in closely related components belong to their own projects, and we will
happily help you find the right contacts and coordinate:

* **PMIx** (OpenPMIx): report it privately through that repository's own
  form, https://github.com/openpmix/openpmix/security/advisories/new, under
  the policy in
  `openpmix/SECURITY.md <https://github.com/openpmix/openpmix/blob/master/SECURITY.md>`_,
  which mirrors this one. PRRTE consumes a great deal of PMIx internal
  machinery, so if you are unsure which side of that boundary a problem lies
  on, report it to either and say so; we will route it.

* **libevent, hwloc, jansson, MUNGE, resource managers** (Slurm, PBS, LSF,
  PALS, Flux), and third-party MCA plugins: these are separate upstreams.
  Raise the issue with us if you cannot tell where it belongs, and we will
  work out where the fix has to be written.

A few behaviors are intentional and are not, by themselves, vulnerabilities:

* **A DVM is a single user's trust domain.** Anyone able to authenticate to
  your DVM as you can launch processes as you. What *is* a vulnerability is a
  way for some *other* user, or an unauthenticated party, to do that — for
  instance through session directory permissions, a predictable rendezvous
  path, or a connection that skips authentication.

* **Running PRRTE as root.** PRRTE refuses to run as root unless explicitly
  overridden with ``--allow-run-as-root`` (or the corresponding environment
  variables), and the documentation states the risk that the override accepts.
  Damage a root-run DVM does to the system it was pointed at is that accepted
  risk. A privilege escalation reachable *without* that override is very much
  in scope.

If you are unsure whether what you have found is in scope, report it. We would
much rather read a report that turns out to be benign than miss one that is
not.

Software authenticity and integrity
-----------------------------------

The authenticity and integrity of PRRTE software should always be confirmed by
computing the checksum of the downloaded archive and comparing it against the
value listed on the [GitHub release
page](https://github.com/openpmix/prrte/releases). Assuming you downloaded the
file ``prrte-5.0.0.tar.bz2``, you can run the ``sha1sum`` command like this:

.. code-block:: sh

   shell$ sha1sum prrte-5.0.0.tar.bz2


Check that the output matches what is printed in the release announcement,
which may look like this:

.. code-block:: sh

   b4e1cb79dfd94c1b9db8eaba02f725c07ef9df2b  prrte-5.0.0.tar.bz2


To avoid having to compare the string by eye, use ``sha1sum -c``:

.. code-block:: sh

   shell$ echo 'b4e1cb79dfd94c1b9db8eaba02f725c07ef9df2b  prrte-5.0.0.tar.bz2' | sha1sum -c


Note that a checksum confirms only that you received the archive the release
page describes. It says nothing about a snapshot tarball built from an
arbitrary Git commit, and nothing about a tree you assembled yourself — for
those, verify the Git history you built from.
