pkgs/README: Document security expectations for new packages#405187
pkgs/README: Document security expectations for new packages#405187LeSuisse merged 1 commit intoNixOS:masterfrom
Conversation
github-actions
bot
added
the
6.topic: policy discussion
LordGrimmauld
added
the
1.severity: security
github-actions
bot
added
10.rebuild-darwin: 0
pkgs/README.md
Outdated
There was a problem hiding this comment.
| * Web engines like chromium and gecko receive frequent updates. Any package which does not keep up-to-date web engines should be considered vulnerable. | |
| * (Web-)Services working on untrusted input should have a maintained and responsible upstream. | |
| * Packages typically used with untrusted data (e.g. received over the network) should have a maintained upstream responsive to issue. For example: | |
| * Web engines like chromium and gecko receive frequent updates. Any package which does not keep up-to-date web engines should be considered vulnerable. | |
| * (Web-)Services working on untrusted input should have a maintained and responsible upstream. |
There was a problem hiding this comment.
I'll do "untrusted data received over the network should", i see little reason to restrict this to network things. Though in practice most untrusted data is network stuff, not everything is.
There was a problem hiding this comment.
Yeah, I switched to «e.g.» myself a minute later. I do think that any network data needs a justification of trustworthiness, so an «e.g.» is a good thing unless we have a wide-ish category which is just as bad. I mean, rich enough implementations PDF & DOC(X) & XLS(X) & video containers probably are as bad, but there are few examples who even try.
There was a problem hiding this comment.
We already have For example: at the end of the line. Imo it makes more sense to just add a bullet point for archive unpackers (a common source of untrusted input) to have a non-network example and call it a day
There was a problem hiding this comment.
I just think that non-browser network clients are sometimes horrible in their own way.
pkgs/README.md
Outdated
There was a problem hiding this comment.
Any ideas how to word that most of the time we want some kind of known-competent upstream for such things?
There was a problem hiding this comment.
"known-competent" is a difficult consideration. I wrote "responsible" and considered "reasonable due diligence", but getting this concise yet precise is hard. My intention is not to outright ban niche upstream devs. I'd already be happy if upstream has available communication channels to disclose (security) issues and then acts on them.
There was a problem hiding this comment.
I pushed an attempt to specify this a bit more, hope this helps
LordGrimmauld
force-pushed
the
pkg-readme-security
branch
from
651f365 to
e67a670
Compare
LordGrimmauld
force-pushed
the
pkg-readme-security
branch
from
e67a670 to
f936135
Compare
LordGrimmauld
force-pushed
the
pkg-readme-security
branch
from
f936135 to
d587e26
Compare
|
Looks like a worthwile addition, kuddo's! It's not overly prescriptive and trying to be "exact", yet worded usefully as a guiding list to help with due dilegence. (normally I wouldn't comment because it's too nitpicky and rude for marginal benefit, but this is a docs PR, sooo... don't forget to be consistent with punctuation at the end of list items) |
LordGrimmauld
force-pushed
the
pkg-readme-security
branch
from
d587e26 to
9ac177c
Compare
|
What I've noticed recently while doing the package drop work is that (non forge hosted) upstreams regularly have a questionable/flaky history if you browse through the web archive. Maybe that's a useful metric that can be used to decide whether to decide on the "trustworthiness"? Or perhaps this will make the list too long and a reason for people to not read it, for marginal benefit. Just a thought, ignore as desired :) |
|
My intention was very much to define the lowest imaginable level of expectations. Restricting years-old unmaintained browser forks and such, something to point to when closing pull requests. I'd be inclined to agree there is more metrics and considerations for a package to be considered "good". But those considerations are likely too complex/controversial and probably should go through RFC. You also have to remember any hard metric we add needs enforcing. |
wegank
removed
the
12.approvals: 1
|
Huh, ofborg exploded... But i didn't actually write any nix code, i believe i didn't break it. |
|
@ofborg eval |
LordGrimmauld
force-pushed
the
pkg-readme-security
branch
2 times, most recently
from
8b8cb3d to
1bc8273
Compare
|
Alright, i changed some of the things @Pandapip1 pointed out. I didn't agree with all the suggested wording, though most of the concerns brought forward were actually valid. Here is hoping this is starting to shape into something usable. |
LordGrimmauld
force-pushed
the
pkg-readme-security
branch
from
1bc8273 to
53dcd98
Compare
|
There could also be documentation for firefox forks expectation since there is not much documentation on it and the only signs is in the matrix and github as the recent comment: #363992 (review) @mweinelt do you agree? |
There already is, Gecko is explicitly mentioned. |
A documented link would be great if there is a security policy |
|
If you think there is something actually missing from this, then make a proper review. As it stands, i wouldn't even know what you mean by a "documented link ". Gecko is listed explicitly (see https://github.com/NixOS/nixpkgs/blob/53dcd98bdd148780f5c3be1265af071e4996457d/pkgs/README.md?plain=1#L45). If your "documented link" is supposed to point to Gecko upstream guidelines: No. Putting external links that point out of the readme is a bad idea, something i will NOT do. It should be possible to understand all expectations without visiting different websites. Doing the research about upstream (and for forks, upstream of upstream) is the job of a packager. Putting something about Zen in here feels oddly specific, and was your job when you opened that Zen PR. Yes this readme update was opened to specifically shut down questionable browser forks from actively endangering users - that does not mean we should start bloating our docs. There might not even be an upstream document, Gecko upstream is free software - they won't stop forks from being created. It is on the package repositories to enforce standards for whatever is being packaged, not the original project. This is that documentation. Other maintainers might even apply hard time limits, like the 48-72h mentioned in emilys comment. While i would agree those limits would be helpful to judge, this readme update is the first step to improving the (currently messy) situation. I won't put explicit limits in here (yet), as those would likely need even more consideration better suited for an RFC. |
|
How about one more rule? Packages with large attack surfaces (e.g. browsers) require an active committer as a maintainer, so that security updates can be delivered swiftly (usually within 48 hours, but at most 7 days). This is so there is no reliance on review resources we don't have, which would hinder shipping security updates and also to prevent that the package will effectively be maintained through @r-ryantm, that bumps the package in uncertain intervals that cannot be controlled or relied upon. |
I see your point, but not sure i fully agree currently. If i were to add a point like that, I'd be very verbose that is specifically about new packages, as some (non-committer) maintainer stepping up is still preferable to having no listed active maintainer. As such, adoptions should explicitly be fine, even by non-committers. |
|
Strictly speaking, a requirement for having an active committer as a maintainer does not restrict additional non-committer maintainers, and nor even the non-committer maintainers doing most of the work most of the time with the committer maintainer making sure their work gets reviewed and merged quickly. There are some precedents of such for non-velocity-critical packages at least. |
LordGrimmauld
force-pushed
the
pkg-readme-security
branch
from
53dcd98 to
9bc53d5
Compare
LordGrimmauld
force-pushed
the
pkg-readme-security
branch
from
9bc53d5 to
baee6c2
Compare
pkgs/README.md
Outdated
There was a problem hiding this comment.
| * Any security-critical fast-moving package such as Chrome or Firefox (or their forks) should have at least one active committer among the maintainers. This ensures no critical fixes are delayed unnecessarily, endangering unsuspecting users. | |
| * 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. |
"should" does not "ensure" anything.
There was a problem hiding this comment.
Alright alright fine, you win. Hard gatekeep criteria don't quite sit right with me, but if we can shut down all the questionable browsers then by all means... Done.
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.
LordGrimmauld
force-pushed
the
pkg-readme-security
branch
from
baee6c2 to
6cd1df5
Compare
LeSuisse
left a comment
LeSuisse
left a comment
There was a problem hiding this comment.
The pull request has been open for 10 days, has received multiple approvals, and the described set of expectations has not been significantly challenged in the last few days.
I think we can merge at this point. We can still readjust later if needed and/or go the RFC route if a more authoritative document becomes necessary.
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
Librewolf is in a bad shape. Not just in nixpkgs, but upstream as well. In nixpkgs, browsers have been a constant painful argument. I have written up NixOS#405187 to clarify some security requirements for packages. While Librewolf doesn't immediately violate the requirements outlined there, we should strive for better than just the absolute minimum. Personally, I no longer feel confident in my ability to adequately contribute, test, and backport Librewolf updates. The past few months have been stressful IRL, and maintaining a browser in nixpkgs is no longer sustainable for me. In the time I intended to take a break, NixOS#471511 was opened to update to 146.0.1. This was not merged in a timely manner, despite me not being the only committer among LW maintainers. librewolf-bin isn't looking much better. NixOS#464467 is open since Nov 24th, entirely unacceptable for a browser. The single remaining maintainer, @DominicWrege, already proposed dropping the package entirely, LeSuisse marked it vulnerable in the meantime. The situation upstream does not look much better. Checking the [commit history](https://codeberg.org/librewolf/source/commits/branch/main), they are barely keeping up with upstream firefox. The maintainers have repeatedly communicated (on matrix) they were close to burning out. The code changes being done are mostly bumps with patch rebases, removals of patches which no longer apply, and a lot of somewhat trivial changes. Very few substantial changes to librewolf itself are made. I originally switched to Librewolf when firefox expanded their enshitification efforts, at a time where search engine policies were not possible to define with mainline firefox. Mainline started supporting search engine policies since. While enshitification did not slow down, librewolf does not keep up sufficiently to combat that effectively. I appreciate the project for what it does and tries to do. But i no longer believe the project is sustainable. Not in nixpkgs, and probably not upstream either. Well, what now? I am not the last maintainer of librewolf source package. I am hoping someone else will step up, and maybe start actually committing open PRs too. Personally, i will be moving back to mainline firefox, and apply [Phoenix](https://github.com/celenityy/Phoenix). Phoenix has a nice flake, and does not require a browser recompile for the changes it does. Phoenix does many of the things librewolf does, while imposing less of a maintainance burden. I wish the best of luck to all remaining librewolf maintainers.
Librewolf is in a bad shape. Not just in nixpkgs, but upstream as well. In nixpkgs, browsers have been a constant painful argument. I have written up NixOS#405187 to clarify some security requirements for packages. While Librewolf doesn't immediately violate the requirements outlined there, we should strive for better than just the absolute minimum. Personally, I no longer feel confident in my ability to adequately contribute, test, and backport Librewolf updates. The past few months have been stressful IRL, and maintaining a browser in nixpkgs is no longer sustainable for me. In the time I intended to take a break, NixOS#471511 was opened to update to 146.0.1. This was not merged in a timely manner, despite me not being the only committer among LW maintainers. librewolf-bin isn't looking much better. NixOS#464467 is open since Nov 24th, entirely unacceptable for a browser. The single remaining maintainer, @DominicWrege, already proposed dropping the package entirely, LeSuisse marked it vulnerable in the meantime. The situation upstream does not look much better. Checking the [commit history](https://codeberg.org/librewolf/source/commits/branch/main), they are barely keeping up with upstream firefox. The maintainers have repeatedly communicated (on matrix) they were close to burning out. The code changes being done are mostly bumps with patch rebases, removals of patches which no longer apply, and a lot of somewhat trivial changes. Very few substantial changes to librewolf itself are made. I originally switched to Librewolf when firefox expanded their enshitification efforts, at a time where search engine policies were not possible to define with mainline firefox. Mainline started supporting search engine policies since. While enshitification did not slow down, librewolf does not keep up sufficiently to combat that effectively. I appreciate the project for what it does and tries to do. But i no longer believe the project is sustainable. Not in nixpkgs, and probably not upstream either. Well, what now? I am not the last maintainer of librewolf source package. I am hoping someone else will step up, and maybe start actually committing open PRs too. Personally, i will be moving back to mainline firefox, and apply [Phoenix](https://github.com/celenityy/Phoenix). Phoenix has a nice flake, and does not require a browser recompile for the changes it does. Phoenix does many of the things librewolf does, while imposing less of a maintainance burden. I wish the best of luck to all remaining librewolf maintainers. (cherry picked from commit 4525c1a)
12 participants
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.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.