|
| 1 | +# Security Policy |
| 2 | + |
| 3 | +For end-users: see also the [Notes on securing NUT](docs/security.txt) chapter |
| 4 | +in NUT documentation. Pay attention to file system permissions, not abusing |
| 5 | +the ability to run daemons as a specified user account (especially `root`), |
| 6 | +and try to ensure you set up (and then require) SSL protection of networked |
| 7 | +communications. |
| 8 | + |
| 9 | +Please do not shoot yourselves in the feet with simple mistakes! |
| 10 | + |
| 11 | +## Supported Versions |
| 12 | + |
| 13 | +The upstream Network UPS Tools (NUT) project deals with on-going development |
| 14 | +of the code base. The numbered releases are snapshots of the `master` branch |
| 15 | +with a special ritual to coordinate the release across several repositories, |
| 16 | +finalize documentation, update version data, and assign a `git tag`. |
| 17 | + |
| 18 | +* At this time there are no "sustaining" branches to track older releases |
| 19 | + nor to backport any urgent fixes into them. This may change in the future. |
| 20 | + |
| 21 | +The upstream project does not currently promote any binary artifacts intended |
| 22 | +for end-user consumption on most platforms. |
| 23 | + |
| 24 | +* We do release source `dist` tarballs which can be used for builds without |
| 25 | + git and autotools generation. The ones published for releases are signed. |
| 26 | + They are typically used by packagers or their CI systems, and by end-users |
| 27 | + who build their own software, but for whatever reason chose to not track |
| 28 | + the newest upstream code (from git). |
| 29 | +* Some NUT CI jobs do produce packages, primarily to cover the platforms where |
| 30 | + it happens and to make sure we track all deliverable files correctly -- so |
| 31 | + installation of those and possible conflicts with the rest of the system |
| 32 | + are up to the users who would risk to use them. |
| 33 | +* There is a special case with NUT for Windows builds, where an archive of |
| 34 | + binaries built and pre-installed by AppVeyor CI is published and can be |
| 35 | + unpacked in any location chosen by end-users to evaluate the progress of |
| 36 | + N4W feature development. There are currently no (MSI) packages produced. |
| 37 | + |
| 38 | +End-user distribution packages are the responsibility of the corresponding |
| 39 | +Operating System, third-party packaging projects, or ultimate virtual or |
| 40 | +physical appliance images which ship them. They typically involve older |
| 41 | +upstream release snapshots (sometimes still a decade old), augmented with |
| 42 | +packager-specific patches (whether to integrate with the requirements of the |
| 43 | +target operating environment, or to backport some fixes from newer releases). |
| 44 | + |
| 45 | +To address issues in such packages, including requests to backport fixes |
| 46 | +from the upstream development, their maintainers and distributors should |
| 47 | +be the primary point of contact. |
| 48 | + |
| 49 | +## Reporting a Vulnerability |
| 50 | + |
| 51 | +We welcome any reports which can help make the NUT ecosystem better and safer! |
| 52 | + |
| 53 | +If you think you have found a security vulnerability, please *DO NOT* disclose |
| 54 | +it publicly until we have had a chance to fix it, and coordinate updates with |
| 55 | +whichever downstream projects we can reach. More specifically, please do not |
| 56 | +report security vulnerabilities using GitHub issues or the mailing list! |
| 57 | + |
| 58 | +To responsibly report a suspected or proven vulnerability with the NUT code |
| 59 | +base, please use https://github.com/networkupstools/nut/security/advisories/new |
| 60 | +to post a new report with the problem description, reproduction details, |
| 61 | +estimated impact for end-users (ease of exploitation, danger to their |
| 62 | +systems, NUT versions involved if possible). Suggestions about the root |
| 63 | +cause and remedies are also welcome. |
| 64 | + |
| 65 | +Please disclose if AI was involved in the discovery process or preparation |
| 66 | +of the report, we prefer to keep track of how much the new technologies help, |
| 67 | +and how much of the finished work is done/revised by a human. |
| 68 | + |
| 69 | +It may be possible that we receive several reports on the same subject |
| 70 | +before a solution and advisory are published, we will try our best to |
| 71 | +figure out how to co-credit all reporters when time comes. |
| 72 | + |
| 73 | +The project is maintained by enthusiasts without a commercial interest |
| 74 | +in their spare time, so there is no bounty program (beside a heartfelt |
| 75 | +thanks, and kudos in eventual attribution when the security advisory gets |
| 76 | +published), nor any guaranteed speed of response, other than a best effort |
| 77 | +to react as soon as possible. |
0 commit comments