Repository navigation
Reduce retirement threshold for committers #109
Description
Although GHSA-67f2-674w-6g63 turned out to have no direct impact, the incident and the efforts it took to respond to it underline the risk that write access to Nixpkgs poses, and the amount of auditing work it can cause when such credentials are compromised; there’s a cost‐benefit calculation to commit access.
That’s the reasoning that led to the original RFC 55 that was then automated in this repository (although currently disabled due to GitHub API issues). The threshold in that RFC was quite conservative, and “The threshold may need adjustment in the future” was noted as potential future work; after 6½ years and lots of growth in the project, I think it’s worth considering adjustment here.
Potential ideas:
-
Reduce the time period from a year to 6 months – this would also line up with the retention period for the GitHub audit log, which would potentially allow us to switch our retirement automation to that API and avoid the reliability issues with the endpoints we’ve been previously using.
-
Remove the month waiting period – this is more in line with what RFC 55 originally intended, and I would say the month’s delay implemented in the automation here is probably not a net benefit: it causes more notification noise in the repository, it incentivizes do a trivial merge during the notification period to keep access, and pinging people to tell them to explain why they should keep commit access generally seems to make people feel like they need to defend themselves and justify their absence. That’s not ideal, since there’s no character judgement in going inactive.
Only a few retirement PRs have been closed without implementation as a result of responses, and in at least one of those the response came in after the nominal month deadline. I think it’s better to have a clear, legible standard, and to implement it immediately when it’s met. Retired committers can re‐nominate themselves with a PR, and we can be generous in re‐granting the bit when the hiatus hasn’t been very long and there’s renewed activity.
-
Tighten the criteria for counting merges – e.g. we could omit merges that could have been done through the merge bot, or self‐merges.
-
Implement a higher minimum threshold – one merge is the least arbitrary number here, but the cost‐benefit ratio of having committers that do one merge every 6 months is potentially arguable, and it could make sense to increase the requirement. (That said, quantity ≠ quality, and the discontinuity around the threshold might be awkward.)
I have some WIP code locally that should fix the API issues by querying the Git log for merge commits locally, and could potentially finish it off and implement some of these.
cc @NixOS/nixpkgs-core
Activity
piegamesde commentedon Apr 27, 2026
If I remember correctly, there have been a couple of retirement PRs made by the tooling in error due to the GitHub API silently failing. Without some time to react and correct obvious mistakes, what are your plans to mitigate these issues? Retiring someone under their ass in an error would certainly be most unpleasant to them and might alienate contributors
infinisil commentedon Apr 27, 2026
Please keep the fix and these changes independent :)
emilazy commentedon Apr 27, 2026
FWIW I didn’t mean that it’d be an entirely automated flow – I would rather not proliferate API keys with write access to the commiters team :) So it would still have a delay in implementation corresponding to getting around to it, and the errors we’ve had were spotted within hours (along with happening to be recognizable enough names that it would have raised alarm bells for me regardless); I don’t expect we’d need a month’s response period to avoid this. (I think the old automation that was run manually a few times and retired committers in batch is probably worse on this front than the PR‐based flow.)
But yeah, that’s why it would need to be coupled to fixing the API timeout issue from #100 and why my WIP rewrite does more stuff locally and avoids the buggy and slow API endpoints we’ve had issues with.
Of course, if access ever was accidentally removed despite this, it would be promptly reinstated.
It’s a (WIP) rewrite, as mentioned in #100 (comment) (because it needs a Nixpkgs clone and it was much easier to do things with the Nixpkgs CI machinery), so the response period logic wasn’t implemented in the first place (it had already come up internally as something that didn’t seem to be a net positive). Any other changes could be decoupled, though, yeah.
Switching to the audit log API would probably be a simpler change and would fix #100, but would also inherently be coupled to reducing the period to 180 days at most. (It also requires GitHub Enterprise Cloud to use, which might make testing changes less convenient for contributors, though @nixos-test-org offsets that.)
philiptaron commentedon Oct 4, 2026
While the Nixpkgs core team remains uncrewed, we'll leave the year-of-inactivity standard in place.
mweinelt commentedon Oct 4, 2026
The security team is in favour of a 6-month retirement period to align with releases and the current audit log retention. We want to see this change implemented.