# Nixpkgs core team update 2026-05-11 – automation/AI policy feedback and new members wanted
**URL:** https://discourse.nixos.org/t/nixpkgs-core-team-update-2026-05-11-automation-ai-policy-feedback-and-new-members-wanted/77567
**Category:** Nixpkgs Core Team
**Created:** [May 11, 2026, 10:30pm UTC](https://discourse.nixos.org/t/nixpkgs-core-team-update-2026-05-11-automation-ai-policy-feedback-and-new-members-wanted/77567 "2026-05-11T22:30:42Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@emily](https://discourse.nixos.org/u/emily)
#### Post date: [May 11, 2026, 10:30pm UTC](https://discourse.nixos.org/t/nixpkgs-core-team-update-2026-05-11-automation-ai-policy-feedback-and-new-members-wanted/77567/1 "2026-05-11T22:30:43Z")
It’s been a while! Nixpkgs core team events since our [last update](https://discourse.nixos.org/t/nixpkgs-core-team-update-2026-01-22/74585):
- After discussion with the [community team bootstrap group](https://discourse.nixos.org/t/announcement-of-the-community-team-bootstrap-group/77055) and within the Nixpkgs core team, **we’ve [proposed an initial policy](https://github.com/NixOS/nixpkgs/pull/514587) covering the use of automation for Nixpkgs, including LLM‐based AI tools, for community review**.
- Following on from our previous announcement, we have **delegated a formal [software provenance team](https://nixos.org/community/teams/provenance/)** with authority to make decisions regarding package provenance, SBOMs, software supply chain tracking, and related topics, and an initial mandate to shepherd design and implementation of a coherent vision for this in Nixpkgs. We look forward to seeing their work progress and helping facilitiate it as needed.
- We participated in the security response and audit process for [GHSA-67f2-674w-6g63](https://github.com/NixOS/nixpkgs/security/advisories/GHSA-67f2-674w-6g63), an incident where a committer’s GitHub personal access token with push access to Nixpkgs leaked in a public repository. Thankfully, after a comprehensive audit, we have **comprehensively established that there was no compromise of the Nixpkgs source code as a result** , with further details in the advisory. However, this incident has exposed systemic risks in the security of our GitHub infrastructure; efforts to address thesee are being tracked in [NixOS/org#246](https://github.com/NixOS/org/issues/246).
- We’re sorry about the marketing emails from GitHub many people received after the Enterprise Cloud upgrade. **GitHub manually unsubscribed all members of the NixOS organization from these on our request** in early February, so these should have stopped.
- After our last update, our founding member @wolfgangwalther sadly [left the team](https://github.com/NixOS/org/pull/229).
---
### Author:  [@Scrumplex](https://discourse.nixos.org/u/Scrumplex)
#### Post date: [May 12, 2026, 5:51am UTC](https://discourse.nixos.org/t/nixpkgs-core-team-update-2026-05-11-automation-ai-policy-feedback-and-new-members-wanted/77567/2 "2026-05-12T05:51:46Z")
I will use this to say some stuff about [GHSA-67f2-674w-6g63](https://github.com/NixOS/nixpkgs/security/advisories/GHSA-67f2-674w-6g63) 😃
For anyone wondering which committer caused all of this, it was me!
I take full responsiblity for this token leak, but I thought I could give some
insight into how this happened and, more importantly, what I learned from this.
## How was the token leaked?
This happened back when I was running K3s on my home server. At my workplace we
use Kubernetes and deploy our workloads using FluxCD for
a [GitOps](https://en.wikipedia.org/wiki/DevOps#GitOps)-based approach. I loved
this so much back then that I wanted this at home as well. It didn’t age well
due to the amount of work needed to maintain the deployment manifests (imagine
having to maintain every NixOS module for your homelab services), but that’s
a story for another day.
Due to the declarative nature of GitOps configurations, you will quickly run
into a similar issue when trying to configure secrets for modules on NixOS. In
Kubernetes-Land there are of course many options to choose from. I chose
[Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets) back then, as
it seemed fairly easy to encrypt secrets without having to maintain the
certificate.
This is where things went downhill. See, the easiest way to use Sealed Secrets
is to create a regular Kubernetes Secret manifest and then “seal” it using the
`kubeseal` utility. The tool will take your Secret and generate a SealedSecret
manifest with encrypted contents, that will then be decrypted on the cluster.
This seems like a solid way of doing this, as it’s actually quite similar to
how we do it in NixOS-Land with [agenix](https://github.com/ryantm/agenix) and
[sops-nix](https://github.com/Mic92/sops-nix). But there is one catch:
`kubeseal` never modifies or removes the original Secret manifest. That means
that, unless you have a [.gitignore
entry](https://codeberg.org/Scrumplex/homelab/src/commit/9b8531e1d57a17016536deefcba92945ba0b0396/.gitignore#L1)
that would make Git ignore these files, there is a risk of accidentally
commiting this file to your publicly viewable Git repo.
Well, as you can imagine from this long exposition, I accidentally committed
the source Secret manifest to the repo due to a simple mistake. Instead of
calling it `secret.yaml.orig`, I called it `secret.orig.yaml` which wasn’t
covered by my `.gitignore` file. So it just took one distracted code change to
accidentally commit this file, which seems to have [happened on
2023/07/04](https://codeberg.org/Scrumplex/homelab/commit/a27a23175e264e14cab235bc8131e8d85f8dd2c5).
These are base64-encoded secrets and tokens and therefore effectively
plain-text.
Note that all the secrets mentioned here had been rotated back when this
vulnerability was reported.
## What can I do to prevent this?
Nothing really. Mistakes happen, and we are all merely human. Though humans
aren’t the only ones leaking tokens nowadays!
I learned from this that the best I can do is reduce the impact. First, it’s
always a good idea to set an expiration date for a token. Rotating tokens
should be a very simple operation in any system, and if it isn’t, then that
should be worked on. In my case, I have limited all my GitHub secrets to
a maximum lifetime of 365 days, and much less for ones that are very easy to
rotate and/or rarely used. This not only reduces the impact of an old and
unnoticed leaked secret but also gets rid of unused secrets over time.
Additionally, the primary issue here was the permissive scope. The leaked token
was a classic one issued with the `public_repo` scope. Before this token was
reported, I was not aware that `public_repo` included write access to all repos
my account can write to. As the token was only used for increased API rate
limits, I have replaced it with a fine-grained token that only has read access.
## TL;DR
I leaked a token years ago due to human error. Now all my tokens have an expiry
date of at most a year and much more limited scopes. Don’t use GitHub classic
tokens unless you really have to.
---
### Author:  [@malikwirin](https://discourse.nixos.org/u/malikwirin)
#### Post date: [May 12, 2026, 12:27pm UTC](https://discourse.nixos.org/t/nixpkgs-core-team-update-2026-05-11-automation-ai-policy-feedback-and-new-members-wanted/77567/3 "2026-05-12T12:27:16Z")
> [@emily](#):
>
> The core of the proposed policy is:
>
> > Every contribution to Nixpkgs and related development venues, including code, documentation, and communication on GitHub and Matrix, must have a **responsible person in the loop** who is accountable for that contribution and reviews it before submission, and must **transparently disclose** any non‐trivial use of automation to produce it, including but not limited to LLM‐based AI tools.
Extremly reasonable 👍
---
### Author:  [@Grunty](https://discourse.nixos.org/u/Grunty)
#### Post date: [June 9, 2026, 3:07am UTC](https://discourse.nixos.org/t/nixpkgs-core-team-update-2026-05-11-automation-ai-policy-feedback-and-new-members-wanted/77567/4 "2026-06-09T03:07:42Z")
Blast, bugger, bloody badness,
this AI acceptance brings only sadness.
I think this policy ought to be rethought,
Before the risk of LLMs has been wrought!
For just one consequence I shall select,
of the enormous personal data these companies collect.
But perhaps it has no bearing whether users lose their privacy,
to which, I implore you review the concerns laid at [open slopware](https://codeberg.org/small-hack/open-slopware), with ethical issues taking primacy.
And finally, One common riposte, I shall preempt,
Is that speakers of languages other than English may be from discussions exempt.
But this is misleading… and to the user, damaging to boot,
for many will judge the use of English poor used in a post by a doot.
Thus, since the distinction between a translation app and LLM is clear,
I further ask we skip such a topic used to garner fear.