movefasta/nixpkgs
1
0
Fork 0
mirror of https://github.com/NixOS/nixpkgs.git synced 2025-06-12 04:35:41 +03:00
Code Issues Projects Releases Packages Wiki Activity

pkgs/README: Document security expectations for new packages

Browse source 
Motivation: Many package additions add unmaintained or otherwise problematic packages.
Many additions for browser forks, questionable encryption libraries or 10+ years unmaintained software exist.
These are frequently closed, but the expectations are not actually visibly documented.
This commit is contained in:
Grimmauld 2025-05-08 12:09:02 +02:00
parent d4b937da3a
commit 6cd1df5e59
No known key found for this signature in database
1 changed files with 21 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

22
pkgs/README.md
View file

@ -30,12 +30,32 @@ Before adding a new package, please consider the following questions:
* Is the package ready for general use? We don't want to include projects that are too immature or are going to be abandoned immediately. In case of doubt, check with upstream.
* Does the project have a clear license statement? Remember that software is unfree by default (all rights reserved), and merely providing access to the source code does not imply its redistribution. In case of doubt, ask upstream.
* How realistic is it that it will be used by other people? It's good that nixpkgs caters to various niches, but if it's a niche of 5 people it's probably too small.
* How realistic is it that it will be used by other people? It's good that nixpkgs caters to various niches, but if it's a niche of 5 people it's probably too small. A good estimate is checking upstream issues and pull requests, or other software repositories. Library packages should have at least one dependent.
* Is the software actively maintained upstream? Especially packages that are security-critical, rely on fast-moving dependencies, or affect data integrity should see regular maintenance.
* Are you willing to maintain the package? You should care enough about the package to be willing to keep it up and running for at least one complete Nixpkgs' release life-cycle.
* In case you are not able to maintain the package you wrote, you can seek someone to fill that role, effectively adopting the package.
If any of these questions' answer is no, then you should probably not add the package.
Special care has to be taken with security-critical software components. Because entries in the Nix store are inert and do nothing by themselves, packages should be considered by their intended use, e.g. when used together with a NixOS module.
* Any package that immediately would need to be tagged with `meta.knownVulnerabilities` is unlikely to be fit for nixpkgs.
* Any package depending on a known-vulnerable library should be considered carefully.
* Packages typically used with untrusted data should have a maintained and responsible upstream. For example:
* Any package which does not follow upstream security policies should be considered vulnerable. In particular, packages that vendor or fork web engines like Blink, Gecko or Webkit need to keep up with the frequent updates of those projects.
* Any security-critical fast-moving package such as Chrome or Firefox (or their forks) must have at least one active committer among the maintainers. This ensures no critical fixes are delayed unnecessarily, endangering unsuspecting users.
* Services which typically work on web traffic are working on untrusted input.
* Data (such as archives or rich documents) commonly shared over untrusted channels (e.g. email) is untrusted.
* Applications in the Unix authentication stack such as PAM/D-Bus modules or SUID binaries should be considered carefully, and should have a maintained and responsible upstream.
* Encryption libraries should have a maintained and responsible upstream.
* Security-critical components that are part of larger packages should be unvendored (=use the nixpkgs package as dependency, instead of vendored and pinned sources).
* A "responsible upstream" includes various aspects, such as:
* channels to disclose security concerns
* being responsive to security concerns, providing fixes or workarounds
* transparent public disclosure of security issues when they are found or fixed
* These aspects are sometimes hard to verify, in which case an upstream that is not known to be irresponsible should be considered as responsible.
* Source-available software should be built from source where possible. Binary blobs risk supply chain attacks and vendored outdated libraries.
This section describes a general framework of understanding and exceptions might apply.
Luckily it's pretty easy to maintain your own package set with Nix, which can then be added to the [Nix User Repository](https://github.com/nix-community/nur) project.