| 19 Feb 2026 |
 emily | RFC39 bot doesn't write to Nixpkgs, no | 17:07:14 |
| emily | I believe you can assign bot accounts as team maintainers, although I'm not 100% on the nuance with GitHub Apps there. | 17:07:47 |
 Mic92 | BMG in case you want to join: https://meet.cccda.de/nix-osin-fra | 17:18:06 |
 toonn | It doesn't? Does it open a PR instead then to update maintainer handles? | 17:21:48 |
| emily | it doesn't update maintainer handles | 17:23:40 |
| emily | at least not that I've ever seen | 17:23:52 |
| emily | (it couldn't do it via direct push anyway since we don't allow those) | 17:24:09 |
| toonn | It claims to though. | 17:24:18 |
| toonn | Or at least RFC 39 says it should : ) | 17:24:28 |
| emily | I don't see that in the text. it just says that handles should be updated in general, not that a bot should do it | 17:26:28 |
| toonn | Looks like it was aspirational "Somewhat half-hearted attempt at checking all the handles and IDs, but it doesn't really work right now." | 17:28:23 |
| toonn | For an action to add members to the organization (since that's a requisite for team membership) or a team it'd need a token from an app with the "members: write" permission. I assume the app would be an empty shell to carry the token with the permission. Then the action can do API requests using the token, parse the maintainers list, get nixpkgs-maintainers membership through the API and | 17:33:20 |
| toonn | invite missing maintainers to the org/team using another API request. | 17:33:27 |
| emily | the app for CI already exists and has write access to Nixpkgs (so there would be no further exposure than we already have) | 17:36:47 |
| toonn | I'm not sure why you insist on the Nixpkgs write access. Repository access is not enough, "members: write" is an organization level permission. | 17:39:39 |
| emily | I am explaining that we already have a GitHub App hooked up to our GitHub Actions CI, and it already has write access to Nixpkgs, so the risk that a bot that can manage teams could lead to privilege escalation into Nixpkgs writes isn't any increase in the surface of the risk the app we already have already provides to our automation | 17:40:53 |
| toonn | Least priviledge would suggest having separate apps with strictly necessary permissions but storing multiple tokens in GitHub secrets means actions can access all of the permissions anyway. | 17:41:23 |
| emily | the reason "members: write" is dangerous is because it's equivalent to Nixpkgs commit access, nothing else you can do with it is remotely as risky | 17:41:52 |
| emily | you can offer different secrets to different workflows, but because of ^ I doubt it'd be that worthwhile. anyway, ideally it just uses team maintainership anyway. my point was only that it's not an increase in effective attack surface | 17:42:42 |
| toonn | The equivalence is useful to point out but I never tried to say it's a problem. | 17:45:04 |
| toonn | I'm not sure team maintainership can be passed along through a token. | 17:45:36 |
 gabyx | Is rfc39 running currently? | 17:55:52 |
| toonn | AFAIK it is, new maintainers still get invites. Often they expire but then they come to the org owners room to ask for a new invite. | 17:58:14 |
 hexa | all the time | 18:14:22 |
| hexa | every 30 minutes | 18:14:35 |
| gabyx | it only updates files in nixpkgs right? the maintainers file | 18:17:12 |
| hexa | no, it just issues team invites | 18:17:29 |
| hexa | https://discourse.nixos.org/t/garbage-collecting-cache-nixos-org/74249/10?u=hexa | 18:42:43 |
| hexa | We did the first garbage collection tonight, check the post for details! | 18:43:03 |
 dramforever | i think it's not just me, but the post is completely inscrutable to me | 19:36:03 |
