Nix ran for many years with very little to no structure. This worked fine as long as the community has some cohesion around it being a FOSS project. But political divisiveness happened around 2021 and crept into the community. You're still seeing the fallout of https://github.com/NixOS/rfcs/pull/98
In The Nixpkgs core team has disbandedNixOS
rfcs
Markdown2018–2026
NixOS / rfcs
rfcs
The Nix community RFCs
39Distinct people
64Mentions
2Explicit recommenders
659GitHub stars
What to know before exploring
What it is
The Nix community RFCs
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
Nix packages are blindly and automatically signed by a single private key last I reviewed it. Bribe or compromise one person and the entire model fails. There is good reason to…
lrvick used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- nixos/nix · linked in 3 of the same discussions
- nixos/nixpkgs · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year64 dated mentions
Observed mentions: 2018-11-03 05:49:00 UTC to 2026-08-08 05:15:45 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 11 | 2 | 9 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 16 | 0 | 16 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 0 | 4 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
NoteDue to the decreased activity in the RFC repository, and as also discussed in the previous meeting notes, we will transition the RFC process to a new on-demand work flow. More info here.
Nix RFCs (Request For Comments)
Many changes, including bug fixes and documentation improvements can be
implemented and reviewed via the normal GitHub pull request workflow.
Some changes though are "substantial", and we ask that these be put through a
bit of a design process and produce a consensus among the Nix community.
When this process is followed
This process is followed when one intends to make "substantial" changes to the
Nix ecosystem. What constitutes a "substantial" change is evolving based on
community norms, but may include the following.
Any semantic or syntactic change to the language that is not a bug fix
Removing language features
Big restructuring of Nixpkgs
Expansions to the scope of Nixpkgs (new arch, major subprojects, ...)
Introduction of new interfaces or functions
Certain changes do not require an RFC:
Adding, updating and removing packages in Nixpkgs
Fixing security updates and bugs that don't break interfaces
Pull requests that contain any of the aforementioned 'substantial' changes may
be closed if there is no RFC connected to the proposed changes.
Terminology
RFC Steering Committee
A team of people defined by RFC 36
and stays consistent until the team members are changed via a follow-up RFC.
This committee is responsible for forming an RFC Shepherd team from the
available nominations on each RFC. This team also names the leader of the
Shepherd team. This has to happen within 1 week after the PR has been opened.
Until then the Steering Committee is responsible for guiding the discussion. In
case of the Shepherding Team not doing its work the Steering Committee shall
encourage them or step in and assign new Shepherds. They also are in charge of
merging accepted and rejected RFCs. Generally by these expectations they should
find time to meet once a week for about an hour.
They have no special responsibility with regard to the content of an RFC, they
can weigh in on them, the same as any other community member, but are only in
charge of:
selecting the Shepherds unanimously
supervising that the Shepherds are carrying out their work
committing the final RFC
Shepherd Team
A team of 3-4 community members defined unanimously by the RFC Steering
Committee, responsible for accepting or rejecting a specific RFC. This team is
created per RFC from community members nominated in the discussion on that RFC.
This team should be people who are very familiar with the main components
touched by the RFC. The author cannot be part of the Shepherd Team. In addition,
at most half of the Shepherd Team can be part of the RFC Steering Committee.
The responsibility of the team is to guide the discussion as long as it is
constructive, new points are brought up and the RFC is iterated on and from time
to time summarise the current state of discussion. If this is the case no longer,
then the Shepherd Team shall step in with a motion for FCP.
Shepherd Leader
The person in charge of the RFC process for a specific RFC, and responsible for
ensuring the process is followed in a timely fashion. The Shepherd Leader has no
special responsibility with regard to moving an undecided Shepherd Team to a
certain decision.
Final Comment Period (FCP)
A period of ten calendar days, which will be called by the Shepherd Team after
the RFC has received ample discussion and enough of the tradeoffs have been
discussed. The Shepherd Team will propose to either accept or reject the RFC
after the FCP.
Process from Creation to Merge
In short, to get a major change included in Nix or Nixpkgs, one must
first get the RFC merged into the RFC repository as a markdown file under the
rfcs directory. At that point the RFC is accepted and may be implemented
with the goal of eventual inclusion into Nix or Nixpkgs.
graph TD
Start((Start)) --> Draft
Draft -->|Ready for Review| Discuss
style Draft fill:#008,color:#FFF
Discuss[Discuss and Refine]
Discuss ---> |On Hold| Draft
Discuss --> |Can't Find Shepherds| NoShepherds
Discuss --> |Motion for FCP| FCP
NoShepherds[Closed - Lack of Interest]:::closed
NoShepherds --> |Renewed Interest| Discuss
FCP[Final Comment Phase]
FCP --> |FCP Canceled| Discuss
FCP --> |Accept| Merged
FCP --> |Reject| Rejected
Merged
style Merged fill:#080,color:#FFF
Rejected[Closed - Rejected]:::closed
Withdrawn[Closed - Withdrawn]:::closed
Discuss & Draft --->|Author Withdraws| Withdrawn
classDef closed fill:#800,color:#FFF
Loading
Have a cool idea!
Fill in the RFC. Put care into the details: RFCs that do not present
convincing motivation, demonstrate understanding of the impact of the design,
or are disingenuous about the drawbacks or alternatives tend to be
poorly-received. Consider using Semantic Line Breaks
in order to get better diffs on later amendments.
Consider publishing your RFC as pre-RFC in the forum
to gather initial feedback and iron out the remaining typos.
In case your RFC is a technical proposal, you might want to prepare a
prototype of your idea to firstly make yourself aware of potential pitfalls
and also help reviewers understand the RFC. Code may be able to explain some
issues in short.
Submit a pull request. As a pull request the RFC will receive design feedback
from the larger community, and the author should be prepared to revise it in
response.
For the nomination process for potential members of the RFC Shepherd Team,
that is specific to each RFC, anyone interested can either nominate another
person or themselves to be a potential member of the RFC Shepherd Team. This
can already be done when submitting the PR.
The RFC Steering Committee assigns a subset of the nominees to the RFC
Shepherd Team and designates a leader for it. This has to be done
unanim
Read the full README on GitHubWhat Hacker News says
64 sourcesOne suggestion for improving the cache's posture: Give each dedicated builder machine a TPM. On each builder, generate a TPM-backed signing key. Only use those TPM-backed keys for signing packages that end up in the cache. That way we'd ensure that signed packages _must_ have been built on the dedicated build machines (due to the TPM) rather than potentially uploaded from a compromised developer machine using a compromised signing key.
It seems the current situation is there is a single signing key that has been in use since 2015 which implies that key is not tied to specific hardware and therefore could be leaked/exfiltrated/copied: https://github.com/NixOS/rfcs/pull/149/files#diff-ac4cc42774...
In I can haz smoller NixOS ISOs?Is this related to the Contracts RFC[1] and associated implementation[2] or is it its own freestanding work unrelated to upstream efforts?
1. https://github.com/NixOS/rfcs/pull/189
2. https://github.com/NixOS/nixpkgs/pull/485453
In Contracts in NixI’m working on introducing this kind of protocol in NixOS. I called it contracts. https://github.com/NixOS/rfcs/pull/189
The idea is a contract is defined saying which options exist and what they mean. For backups, you’d get the Unix user doing the backup, what folders to backup and what patterns to exclude. But also what script can be run to create a backup and restore from a backup.
Then you’d get a contract consumer, the application to be backup, which declares what folders to backup either which users.
On the other side you have a contract provider, like Restic or Borgbackup which understand this contract and know thanks to it how to backup the application.
As the user, your role is just to plug-in a contract provider with a consumer. To choose which application backs up which application.
This can be applied to LDAP, SSO, secrets and
Read the rest
more!
My RFC was much earlier in 2018 https://github.com/NixOS/rfcs/pull/34
Lack of supply chain integrity controls as a means to reduce contribution friction to maximize the number of packages contributed is a perfectly valid strategy for a workstation distribution targeted at hobby developers.
Volunteers can do what they want, so that RFC convinced me stagex needed to exist for high security use cases, as Nix was explicitly not interested in those.
This is all fine. The reason I speak in a tone of frustration whenever Nix comes up is because as a security auditor I regularly see Nix used to protect billions of dollars in value or human lives. Sysadmins uneducated on supply chain integrity just assume Nix does security basics and has some sort of web of trust solution like even OG distros like Debian, but that is just not the case.
Nix maintai
Read the rest
ners did not ask to be responsible for human lives and billions in value, but they are, and people will target them over it. I am afraid this is going to get people hurt.
https://github.com/jlopp/physical-bitcoin-attacks
Nix choosing low supply chain security to maximize the total number of packages endangers themselves and others every time someone ignorantly deploys nix for high value applications.
If nix chooses to maintain their status quo of no commit signing, no review signing, no developer key pinning, and no independent reproducible build signing, they need to LOUDLY warn people seeking to build high risk systems about these choices.
Even those basic supply chain controls which we use in stagex, are nowhere near enough, but they are the bare minimum for any distro seeking to be used in production.
Hey! First, a disclaimer: I do not speak for anyone officially, but I am a very regular contributor to nixpkgs and have been involved in trying to increase nixpkgs' security through adopting the Full-Source Bootstrap that Guix and Stagex use. I also assume that the RFC you're talking about is RFC 0100, "Sign Commits"(ref: https://github.com/NixOS/rfcs/pull/100)
As mentioned in the RFC discussion, the major blocker with this is the lack of an ability for contributors to sign from mobile devices. Currently, building tooling for mobile devices is way out-of-scope for nixpkgs, and would be a large time sink for very little gain over what we have now. Further, while I sign my commits because I believe it is a good way to slightly increase the provenance of my commits, there is nothing preventing me from pushing an unsigned commit, or a commit
Read the rest
with an untrusted key, and that's, in my opinion, fine. While for a project like Stagex(which as a casual cybersecurity enthusiast and researcher, I thoroughly appreciate the security work you all do), this layer of security is important, as it's clearly part of the security posture of the project, nixpkgs takes a different view to trustworthiness. While I disagree with your conclusion that having this sort of security measure would "make volunteers run screaming", I would be interested in seeing statistics on the usage of these mechanisms in nixpkgs already. Nixpkgs is also definitely not focused on being a hobby distro, considering it's in use at many major companies around the world(just look at NixCon 2025's sponsor list).
To be clear, this isn't to say that all security measures are worthless. Enabling more usage of security features is a good thing, and it's something I know folks are looking into(but I'm not going to speak for them), so this may change in the future. However, I do agree with the consensus that for nixpkgs, enabling commit signing would be very bad overall for the ecosystem, despite the advantages of them. Also, I didn't see anything in your PR about "independent signed reproducible builds", but for a project the size of nixpkgs, this would also be a massive infrastructure undertaking for a 3rd-party, though NixOS is very close to being fully reproducible(https://reproducible.nixos.org/) at the moment, we're not there yet though.
In conclusion, while I agree that signing commits would a good improvement, the downsides for nixpkgs are significant enough that I don't believe it would be a good move. It's something to definitely continue thinking about as nixpkgs and nix continue to refine and work on their security practices, though. I would also love some more information about how Stagex does two-party hardware signing, as that sounds like something interesting as well. Thank you so much!
Edit: Also, want to be very clear: I am not saying you're entirely wrong, or trying to disparage the very interesting and productive work that Stagex is doing. However, there were some (what I felt were)misconceptions I wanted to clean up.
Yeah, nah.
Watch how an open discussion here:
https://github.com/nixos/rfcs/pull/98
... devolves into a massive outcry because a bunch of folks not behaving in good faith didn't like "we don't support fascism or bigotry".
It reached the level of
* Vile sock puppet attacks on a trans individual, who merely kept saying "Fascism, no thanks in this community"
* "Denounce the Marxists!" As a rallying cry becomes a talking point
If you reflect on the behaviours seen there and ask why is this so heated for proposing consequences for bad behaviour; you may come to the realisation that the advocates of bad behaviour... don't want to be accountable.
This post is translated, perhaps some of the nuance is lost. But it hand waves away dhh's behaviour as "controversial figures in the community"
If that's genuinely what is believed, I'd like a replaceme
Read the rest
nt on this Overton window, thanks! It has been fractured.
The article does not consider the consequences or implications of malicious acts, and the harm on others adequately.
A clear CoC or similar outlines expected norms, and does not have to be copypasta/is infact better if it is derived from a consensus. It's a statement of what the people with power will hold themselves to, and if that turns out to be a lie - a performative document that is not actually used - newcomers can view the behaviour they observe against that standard; and leave or demand justice if they are wronged.
By not publishing an ethical or moral standard you abide by, even if it's a text file with "get bent" in it; you invite people to interact with you with expectations. If you are part of the 1-4% of the population who are sociopaths, you are advocating to hurt people without consequence. If they are part of the 1-4% you are permitting behaviour without recourse.
Could you imagine a post advocating for "don't fix security holes because 92-98% of people don't know about exploiting them?"
Would that be acceptable?
Why would you not state a policy?
Explanation of the NixOS Steering Committee and NixOS Moderation Team (https://old.reddit.com/r/NixOS/comments/1nrsu9c/nixos_modera...):
> The Nix Steering Committee (SC) (https://nixos.org/community/teams/steering-committee/) is the elected community leadership body. It was established as part of the Nix governance constitution (https://github.com/NixOS/org/blob/main/doc/constitution.md) last year, after which the first elections were held, where 450 contributors voted for the current members. This years election (https://discourse.nixos.org/t/the-election-committee-announc...) is currently in progress. The SC generally is responsible over project direction and community matters, including management of teams. While most responsibilities are delegated, the SC has the authority to step in when necessary.
> The moderation team (https://nix
Read the rest
os.org/community/teams/moderation/) was established before the SC or constitution existed. The initial moderators were appointed from RFC 102 (https://github.com/NixOS/rfcs/blob/master/rfcs/0102-moderati...), with the mandate to self-select successors. Over the years the team has changed members a lot, none of the initial members are part of it anymore, and the last larger rotation happened last year. The responsibilities include moderation according to the Code of Conduct (CoC) (https://github.com/NixOS/.github/blob/master/CODE\_OF\_CONDU...) of the official community spaces, which is mostly the Discourse and a bunch of Matrix channels. Earlier this year the now-existing SC took on the responsibility of approving new mod team members and CoC changes (https://discourse.nixos.org/t/code-of-conduct-and-moderation...).
How this article discusses reproducibility in NixOS and declines to even mention the intensional model or efforts to implement it are surprising to me, since it appears they have done a lot of research into the matter.
If you don’t know, the intensional model is an alternative way to structure the NixOS store so that components are content-addressable (store hash is based on the targets) as opposed to being addressed based on the build instructions and dependencies. IIUC, the entire purpose of the intensional model is to make Nix stores shareable so that you could just depend on Cachix and such without the worry of a supply-chain attack. This approach was an entire chapter in the Nix thesis paper (chapter 6) and has been worked on recently (see https://github.com/NixOS/rfcs/pull/62 and https://github.com/NixOS/rfcs/pull/17 for current pro
Read the rest
gress).
Austin I think some of these distinctions are not necessary for the theory.
In https://github.com/NixOS/rfcs/blob/master/rfcs/0092-plan-dyn... there is only an action graph but it is dynamic. Dynamic craft would depend on an entire directory, and thus need to be rebuilt a lot. But when individual files are projected out, there is a new opportunity for early cut-off.
In Zb: An Early-Stage Build SystemInteresting! Thanks, hadn't seen that yet. (For anyone else curious, the RFC is here: https://github.com/NixOS/rfcs/blob/master/rfcs/0092-plan-dyn...)
In Zb: An Early-Stage Build SystemBoth this fork (Lix) and the other one (Aux - https://news.ycombinator.com/item?id=40200343) appeared in the context of the recent Nix drama, related submissions on which are presented below:
Open letter to the NixOS foundation (50 comments) https://news.ycombinator.com/item?id=40107370
The dire state of NixOS's moderation culture (87 comments) https://news.ycombinator.com/item?id=40166912
---
Additionally, these r/NixOS submissions may be of interest:
Jon Ringer: "In case I'm unable to return, wish you all the best" (348 comments) https://old.reddit.com/r/NixOS/comments/1cd5fod/in_case_im_u...
Transparency about jonringer's suspension (153 comments) https://old.reddit.com/r/NixOS/comments/1ceeg8h/transparency...
Thoughts on Jon Ringer's temporary suspension (71 comments) https://old.reddit.com/r/NixOS/comments/1ceiz36/thoughts_on_...
Mod
Read the rest
eration no-go zones (55 comments; ongoing) https://old.reddit.com/r/NixOS/comments/1cfv8vo/moderation_n...
---
Finally, the RFC to improve the situation:
https://github.com/NixOS/rfcs/pull/175
I'm afraid the letter spread some misinformation: The meson RFC has in fact not been approved: https://github.com/NixOS/rfcs/pull/132
For a discussion on this, see https://github.com/KFearsoff/nix-drama-explained/issues/1
In Lix is a modern, delicious implementation of the Nix package managerRelated submissions:
Open letter to the NixOS foundation (50 comments) https://news.ycombinator.com/item?id=40107370
The dire state of NixOS's moderation culture (87 comments) https://news.ycombinator.com/item?id=40166912
---
Additionally, these r/NixOS submissions may be of interest:
Jon Ringer: "In case I'm unable to return, wish you all the best" (348 comments) https://old.reddit.com/r/NixOS/comments/1cd5fod/in_case_im_u...
Transparency about jonringer’s suspension (153 comments) https://old.reddit.com/r/NixOS/comments/1ceeg8h/transparency...
Thoughts on Jon Ringer's temporary suspension (71 comments) https://old.reddit.com/r/NixOS/comments/1ceiz36/thoughts_on_...
Moderation no-go zones (55 comments; ongoing) https://old.reddit.com/r/NixOS/comments/1cfv8vo/moderation_n...
---
Finally, the RFC to improve the situation:
https://github.co
Read the rest
Showing the 15 most recent of 64 sources. Enable JavaScript to search and browse every indexed mention.