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.

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.

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.

Support for PRRTE is limited to infrequent releases driven primarily by collected bug 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.

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, 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.

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. Assuming you downloaded the file prrte-5.0.0.tar.bz2, you can run the sha1sum command like this:

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:

b4e1cb79dfd94c1b9db8eaba02f725c07ef9df2b  prrte-5.0.0.tar.bz2

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

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.