|
| 1 | +<!-- SPDX-License-Identifier: Apache-2.0 --> |
| 2 | +<!-- Copyright Contributors to the Rez Project --> |
| 3 | + |
| 4 | +# Security Policy |
| 5 | + |
| 6 | +## Reporting a Vulnerability |
| 7 | + |
| 8 | +If you think you've found a potential vulnerability in rez, please |
| 9 | +report it by filing a GitHub [security |
| 10 | +advisory](https://github.com/AcademySoftwareFoundation/rez/security/advisories/new). Alternatively, |
| 11 | +email [email protected] and provide your contact info for further |
| 12 | +private/secure discussion. If your email does not receive a prompt |
| 13 | +acknowledgement, your address may be blocked. |
| 14 | + |
| 15 | +Our policy is to acknowledge the receipt of vulnerability reports |
| 16 | +within 48 hours. Our policy is to address critical security vulnerabilities |
| 17 | +rapidly and post patches within 14 days if possible. |
| 18 | + |
| 19 | +## Known Vulnerabilities |
| 20 | + |
| 21 | +The only currently known security vulnerability is issue [#937](https://github.com/AcademySoftwareFoundation/rez/issues/937). |
| 22 | +No others are known at this time. |
| 23 | + |
| 24 | +See the [release notes](CHANGES.md) for more information. |
| 25 | + |
| 26 | +## Supported Versions |
| 27 | + |
| 28 | +In general, the rez project release strategy is purely sequential, and we will drop support for any |
| 29 | +major version which is not the current development major version. However, we may at our discretion issue |
| 30 | +patches for prior major versions with compelling reasoning. The rez project team takes compatibility very |
| 31 | +seriously, deprecations are telegraphed, and forward compatibility is incredibly important, making it |
| 32 | +reasonable to expect that users of rez attempt to stay close to the newest version as possible. |
| 33 | + |
| 34 | +## Signed Releases |
| 35 | + |
| 36 | +Signed releases are not yet supported. |
| 37 | + |
| 38 | +We plan to add signed releases soon. The following details are speculative but likely: |
| 39 | + |
| 40 | +Release artifacts are signed via |
| 41 | +[sigstore](https://www.sigstore.dev). See |
| 42 | +[release-sign.yml](.github/workflows/release-sign.yml) for details. |
| 43 | + |
| 44 | +To verify a downloaded release at a given tag: |
| 45 | + |
| 46 | + % pip install sigstore |
| 47 | + % sigstore verify github --cert-identity https://github.com/AcademySoftwareFoundation/rez/.github/workflows/release-sign.yml@refs/tags/<tag> rez-<tag>.tar.gz |
| 48 | + |
| 49 | +## Security Expectations |
| 50 | + |
| 51 | +### Software Features |
| 52 | + |
| 53 | +- The rez project implements a package management solution that is agnostic |
| 54 | + to build system, shell, platform, architecture, operating system, or |
| 55 | + packaged toolset. rez can be used to package python, javascript, C++, or |
| 56 | + even binaries. As long as it is possible to express the way your package |
| 57 | + modifies the environment to expose itself to be consumed, rez can package it. |
| 58 | + |
| 59 | +- rez is implemented in python, and consists primarily of simply its own |
| 60 | + source, a handful of vendored python packages, and is installed to a system |
| 61 | + in the form of a virtualenv-powered executable, tied to a python interpreter. |
| 62 | + |
| 63 | +- rez exposes a robust CLI which can be used to do common operations like build |
| 64 | + or release packages, to resolve and drop into a shell for a given environment, |
| 65 | + or to freeze context files that can be used to bake and reuse resolves. |
| 66 | + |
| 67 | +- rez exposes an API that can be used, in and out of isolation, to perform many |
| 68 | + of the same tasks, as well as more granular operations, so that groups can |
| 69 | + also leverage many of the low-level constructs that make the higher-level CLI |
| 70 | + usages possible. An important disclaimer is that the rez API has not yet been |
| 71 | + robustly reviewed and modified to express what the boundaries of the public vs |
| 72 | + private API are, meaning that some internals may currently be exposed that rez |
| 73 | + may in the future be moved, hidden, or removed. |
| 74 | + |
| 75 | +- rez reads and writes to/from stdout, as well as to/from json-like rxt files. |
| 76 | + rez also writes temporary shell context files like .sh or .bat scripts on a |
| 77 | + shell-by-shell basis, as a shell entrypoint into the chosen environment. |
| 78 | + |
| 79 | +- rez exposes a rich plugin system which can be used and configured in order to |
| 80 | + augment and expand its use-cases or integrations per the users preferences. |
| 81 | + |
| 82 | +- rez will engage in network calls only if configured to do so. Typically, this |
| 83 | + would be the case with the built-in `memcached` functionality, or to publish |
| 84 | + `amqp` messages on package release. |
| 85 | + |
| 86 | +- The only login credentials that rez currently expects to come into contact |
| 87 | + with are those needed for the context tracking feature, where the amqp userid |
| 88 | + and password are encoded in a dictionary to be used when making the amqp |
| 89 | + connection. |
| 90 | + |
| 91 | +- rez does not handle, or expect to handle, any other sort of login credentials |
| 92 | + to any network, file system, or verson-control system currently. rez expects |
| 93 | + that these details are handled independently and outside of rez. |
| 94 | + |
| 95 | +- rez packages and plugins can, by definition and by design, result in the |
| 96 | + execution of arbitrary code. It is critical that users of rez maintain their |
| 97 | + own strict control over their own package repositories, configs, and not trust |
| 98 | + arbitrary packages or plugins given to them by unknown sources. rez takes no |
| 99 | + responsibility for malicious effects caused by that execution of code. |
| 100 | + |
| 101 | +### Software Dependencies |
| 102 | + |
| 103 | +rez depends on python and virtualenv, in order to be installed. |
| 104 | + |
| 105 | +At runtime, without any user-provided plugins, rez depends on the following |
| 106 | +table of vendored packages, their versions, and details related to any |
| 107 | +modifications made: |
| 108 | + |
| 109 | +[Vendored Packages](https://github.com/AcademySoftwareFoundation/rez/blob/main/src/rez/vendor/README.md) |
| 110 | + |
| 111 | +### Potential Vulnerabilities |
| 112 | + |
| 113 | +It is expected that maliciously crafted packages, or rxt files, could cause any |
| 114 | +type of issue that would ordinarily be causable as the result of a json file load, |
| 115 | +or an arbitrary code execution. Do not use or consume packages or context files |
| 116 | +provided from untrusted sources without undue validation, care, or sandboxing. |
| 117 | + |
| 118 | +#### Development Cycle and Distribution |
| 119 | + |
| 120 | +rez is downloadable and buildable as (mostly) python source via the GitHub |
| 121 | +releases page. Only members of the project's Technical Steering Committee have |
| 122 | +write permissions on the source code repository. All critical software changes |
| 123 | +are reviewed by at least one TSC member. |
| 124 | + |
| 125 | +rez is also distributed as a [PyPI](https://pypi.org/project/rez/) package, |
| 126 | +however this distribution is not yet usable as a so-called "production install", |
| 127 | +for which details can be found in the |
| 128 | +[docs](https://rez.readthedocs.io/en/stable/installation.html#installation-via-pip). |
| 129 | +This may change in the future. |
0 commit comments