Home • Explore • Blog • Models • CI
☰



nixpkgs
19th chunk of `pkgs/README.md`
211d7a26cf615bbf8cc9a5cb962852f2d3b1a05c7ff9f6420000000100000ed3
- [ ] build time only dependencies are declared in `nativeBuildInputs`
- [ ] source is fetched from an official or trusted location
- [ ] source is fetched using the appropriate function
- [ ] the motives for any special packaging choices are documented
- [ ] the list of `phases` is not overridden
- [ ] when a phase (like `installPhase`) is overridden it starts with `runHook preInstall` and ends with `runHook postInstall`.
- [ ] patches have a comment describing either the upstream URL or a reason why the patch wasn't upstreamed
- [ ] patches that are remotely available are fetched rather than vendored

##### Possible improvements

##### Comments
```

## Security

### Submitting security fixes

Security fixes are submitted in the same way as other changes and thus the same guidelines apply.

- If a new version fixing the vulnerability has been released, update the package;
- If the security fix comes in the form of a patch and a CVE is available, then add the patch to the Nixpkgs tree, and apply it to the package.
  The name of the patch should be the CVE identifier, so e.g. `CVE-2019-13636.patch`; If a patch is fetched the name needs to be set as well, e.g.:

  ```nix
  (fetchpatch {
    name = "CVE-2019-11068.patch";
    url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
    hash = "sha256-SEKe/8HcW0UBHCfPTTOnpRlzmV2nQPPeL6HOMxBZd14=";
  })
  ```

If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch.

Critical security fixes may by-pass the staging branches and be delivered directly to release branches such as `master` and `release-*`.

### Vulnerability Roundup

#### Issues

Vulnerable packages in Nixpkgs are managed using issues.
Currently opened ones can be found using the following:

[github.com/NixOS/nixpkgs/issues?q=is:issue+is:open+"Vulnerability+roundup"](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+%22Vulnerability+roundup%22)

Each issue corresponds to a vulnerable version of a package; as a consequence:

- One issue can contain several CVEs;
- One CVE can be shared across several issues;
- A single package can be concerned by several issues.


A "Vulnerability roundup" issue usually respects the following format:

```txt
<link to relevant package search on search.nix.gsc.io>, <link to relevant files in Nixpkgs on GitHub>

<list of related CVEs, their CVSS score, and the impacted NixOS version>

<list of the scanned Nixpkgs versions>

<list of relevant contributors>
```

Note that there can be an extra comment containing links to previously reported (and still open) issues for the same package.


#### Triaging and Fixing

**Note**: An issue can be a "false positive" (i.e. automatically opened, but without the package it refers to being actually vulnerable).
If you find such a "false positive", comment on the issue an explanation of why it falls into this category, linking as much information as the necessary to help maintainers double check.

If you are investigating a "true positive":

- Find the earliest patched version or a code patch in the CVE details;
- Is the issue already patched (version up-to-date or patch applied manually) in Nixpkgs's `master` branch?
  - **No**:
    - [Submit a security fix][security-fixes];
    - Once the fix is merged into `master`, [submit the change to the vulnerable release branch(es)](../CONTRIBUTING.md#how-to-backport-pull-requests);
  - **Yes**: [Backport the change to the vulnerable release branch(es)](../CONTRIBUTING.md#how-to-backport-pull-requests).
- When the patch has made it into all the relevant branches (`master`, and the vulnerable releases), close the relevant issue(s).
Title: Nixpkgs Security: Submitting Fixes and Managing Vulnerabilities
Summary
This text concludes a package review checklist and then details the security policies for Nixpkgs. It outlines the process for submitting security fixes, which involves either updating to a new patched package version or applying a specifically named patch (e.g., `CVE-YYYY-ID.patch`) when a CVE is available. It specifies that fixes should ideally be merged into the `master` branch first and then cherry-picked to stable release branches, though critical fixes may bypass staging. The document then describes the "Vulnerability Roundup" system, which uses GitHub issues to track vulnerable packages. It explains the typical format of these issues and provides a guide for triaging and fixing vulnerabilities: identifying false positives, submitting new fixes if needed, backporting existing fixes to vulnerable branches, and closing issues once all relevant branches are patched.