[RFC 0172] Mergebot #172

Lassulus · 2024-03-26T18:48:16Z

0x4A6F · 2024-03-26T18:50:46Z

I'd like to nominate for shepard team.

infinisil · 2024-03-26T18:57:50Z

rfcs/0172-mergebot.md

+- **maintainer_update:** Currently, this strategy allows package maintainers to merge updates from r-ryantm, triggered by mention of the bot.
+
+Proposed strategies are:
+
+- **automerge_updates:** Merges PRs from r-ryantm automatically if ofBorg checks pass, triggered by PR creation or mention. We strongly recommend to have at least one passthrough test.
+- **automerge_backport:** Automatically merges backport PRs if ofBorg checks pass, triggered by PR creation or mention.
+- **full_consensus:** Requires approval from all maintainers before merging. The bot will notify which maintainers' approvals are pending, triggered by PR approval.
+- **single_maintainer:** Allows a single maintainer's approval to trigger a merge, facilitated by a mention of the bot.


These need to be specified more clearly. From just these it sounds like only maintainer_update and automerge_updates are limited to @r-ryantm as author, while all the others don't restrict the author.

yes the idea is to not restrict the author for the other strategies.

Oh that is very easy to miss, you have to read between the lines to even notice it. I don't think it should be done like this and would definitely need to be justified. Honestly this RFC should primarily be just about the lifting of that restriction, because it's the only truly controversial part.

ah, okay, I thought that was pretty clear. But yeah, that's the part worth discussing the most.

I added now a sentence to the summary to make the goal clearer 4727de4 (#172). Is that good enough? or should be emphasize it more?

philiptaron · 2024-03-26T19:17:36Z

Rendered

Mindavi · 2024-03-26T21:35:59Z

rfcs/0172-mergebot.md

+
+- **Security Risks:** There's a potential for malicious actors to manipulate the merge bot to authorize merges improperly. A mitigation for these pull requests could be running validity checks (e.g file size limits, valid nix files, ..)
+- **Reliability Concerns:** A malfunction in the merge bot could disrupt numerous contributors' workflows.
+- **Code Quality** As no review is done by seasoned commiters, the code quality could drop. We want to face that by holding monthly meetings and review the merged PRs to see if the code quality drops and improving on the bot in that case.


Maybe some public audit log could be useful for this purpose.

maybe we can use the github api to show every invocation of the mergebot. Or maybe we should collect all of them in the mergebot directly and show them on a webpage?

Showing them on a webpage or so could be handy, I think. It makes it easy to quickly review some of the actions taken.

It would be very useful to do that in a way that it does not query the Github API live, but stores the audit log in some way independent of the nixpkgs repo.

In the xz backdoor situation, Github took down the xz repo, which had the effect that people were hindered investigating the compromise.

If the merge bot is abused, it would be great to be able to have those logs even if the Github live API is not available for this (just saving the audit log somewhere else in some reasonably frequent interval would be enough to do that).

Mindavi · 2024-03-26T21:41:03Z

rfcs/0172-mergebot.md

+Proposed strategies are:
+
+- **automerge_updates:** Merges PRs from r-ryantm automatically if ofBorg checks pass, triggered by PR creation or mention. We strongly recommend to have at least one passthrough test.
+- **automerge_backport:** Automatically merges backport PRs if ofBorg checks pass, triggered by PR creation or mention.


I think backports could often use an extra pair of eyes. However, they're also often pretty neglected...

They should still follow the criteria for what is acceptable to backport. I think that requires a person to check.

https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#changes-acceptable-for-releases

for certain packages it seems to be fine? like security relevant leave packages could always auto backport

Mindavi · 2024-03-26T21:45:25Z

rfcs/0172-mergebot.md

+
+![](https://pad.lassul.us/uploads/f24e0ff3-117a-4167-8f60-79ca508b8c1c.png)
+
+The current `nixpkgs` contribution model relies heavily on a group of *committers* (approximately 200 at the time of writing), who possess exclusive rights to merge PRs. This model has remained unchanged since its inception and poses limitations on community contributions and maintainer workload. Implementing granular merge permissions will enable a broader contribution base and lessen the burden on existing committers by empowering package maintainers with more control over their respective packages.


Not sure if it should land in this RFC, but I think a hybrid model is ultimately the most suitable. Larger changes of course sometimes require people that have a good overview, and limiting that by a lot seems likely to cause a power struggle or fiefdoms, I'd expect. It makes sense to me to touch upon that lightly, but maybe it just makes it harder to get this rfc accepted. At least consider writing a bit about (possible) social effects.

this section is not about limiting existing commiters, but empowering maintainers to do more actions directly with the bot. Without commiter assistance required and not giving maintainers global merge access.

nixos-discourse · 2024-03-26T23:40:53Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixpkgs-merge-bot-testing-and-plan/39824/13

DanielSidhion · 2024-03-27T00:38:50Z

rfcs/0172-mergebot.md

+
+Proposed strategies are:
+
+- **automerge_updates:** Merges PRs from r-ryantm automatically if ofBorg checks pass, triggered by PR creation or mention. We strongly recommend to have at least one passthrough test.


Would it make sense to fail the automerge_updates strategy by design if no passthrough tests exist? In which case would automerge + no passthrough test be ok?

I think this is something we can decide by a case by case basis? like if there is no passthrough test defined, why was the strategy enabled for this package?

like if there is no passthrough test defined, why was the strategy enabled for this package?

That's exactly my point - is there any case where this would be ok? If not, then making that strategy fail by design if no passthrough test is defined seems like a good choice to avoid this kind of mistake happening.

Given that this only ever automerges r-ryantm updates, I'm ok with the current design, but I think being stricter here helps avoid mistakes and gives an incentive for package maintainers to make Nixpkgs more automated by contributing passthrough tests (this is a good thing IMO).

I think there are certain packages where a delayed update would be more of a liability than an automerge. Like maybe the package is just some icon theme where there really is no testing needed?

Sometimes the tests of the package itself are exhaustive enough too. So I think it makes sense to not require anything extra per say.

DanielSidhion · 2024-03-27T00:51:12Z

rfcs/0172-mergebot.md

+
+## Drawbacks
+
+- **Security Risks:** There's a potential for malicious actors to manipulate the merge bot to authorize merges improperly. A mitigation for these pull requests could be running validity checks (e.g file size limits, valid nix files, ..)


I think this risk should require more careful consideration of how merges get done from authors other than r-ryantm. My initial proposal is:

Add some kind of "hold" period (at least 24h) where the mergebot keeps the PR in "will merge" state to let other people look at the changes before they get pushed.

Make it easy for people to browse through PRs in this state.

In case potentially malicious changes are detected (or in case any other action is needed to stop the bot from merging), closing a PR, marking it as draft or something similar should make the bot forget about the "will merge" state.

The main concern is "this will make merges take longer!". My view is that the mergebot helps us increase throughput of changes merged, which also has the effect of decreasing latency (they're somewhat connected), and it's ok to have the latency at a minimum of 24h (due to the hold period) because the throughput is still increased and changes are still automatically getting merged.

we can create a label which the bot tags the PR with and then would do a merge after the holding period. But I think that also conflicts with other peoples workflow. Maybe this is something we want to enable on a per package basis? but not sure how to expose the interface to configure something like that without making it complex

Can you elaborate on how this conflicts with existing workflows? From my perspective, this mergebot only creates entirely new workflows (non-committers being able to merge changes), so there's no way this can create a conflict.

If a committer wants to get the change merged straight away without waiting for the holding period, they can just merge themselves without the help of the bot, which is the same as the current workflow.

Ah, I didn't mean existing workflows, but what people told me they would expect by the mergebot. So it wouldn't disrupt current operations but would be a point where opinions will differ :)

Security will almost always be a trade-off with convenience. I think adding this holding period is a good approach to mitigate the risk that the RFC points out, while not being too complicated to implement. The suggestion of file size limits and valid nix files doesn't seem to be as flexible and cover as many cases. I'd like to get more opinions on this, hoping more people end up commenting.

hmm, depending on how the bot is manipulated the attacker could just merge the PR directly? So it would be better to have a review log of all the actions the bot has taken instead of relying on a waiting period which could have no effect in an attack?

Can you elaborate on what attack vector you have in mind, and what bot you're talking about (mergebot or r-ryantm)? I think if there's some case where the mergebot can be manipulated to merge the PR directly when it shouldn't, it should definitely be addressed!

I had the following assumption during all my other comments: r-ryantm's PRs are "safe". There are ways that code upstream can be malicious, but this is a problem outside r-ryantm. r-ryantm itself introducing malicious changes that don't come from upstream is possible, but not something this RFC should worry about.

As for other people introducing malicious changes:

Currently there's no way those changes get merged automatically or if a maintainer approves them, only when a committer merges them.

Since there is an existing process to vet new committers, I see this as the baseline for vetting new changes that get merged into Nixpkgs.

With the new strategies, those changes may be merged by maintainers who aren't committers. This is the issue called out in the RFC.

So we should find a way to vet those changes. My opinion is that the current proposal (checking file sizes and valid nix files) is not enough vetting: very inflexible, doesn't cover as many cases.

A holding period of at least 24h ensures that people can vet those changes in a way roughly similar to how new committers are vetted, thus roughly maintaining the baseline.

So it would be better to have a review log of all the actions the bot has taken

I don't think that is better, but a complementary approach, since one concerns changes before they're merged and the other concerns them after they're merged, and the actual merging is what's the issue here.

instead of relying on a waiting period which could have no effect in an attack

I think most people would agree that delaying a possible attack by at least 24h seems like a pretty good mitigation. Unless you have something to back your claim, I think it is weak.

Having said all of that, the strongest argument that I can see against the holding period is this:
I think in practice it's unlikely that a recently-committed malicious change will be used right away, since it usually takes at least some hours for the change to propagate to a channel that most people will be using. Therefore this would already serve as a "holding period". However...

In case something malicious gets committed, I see two approaches to "fix" it:

Rewrite git history to remove the commit completely: better solution to ensure the malicious change doesn't propagate further and is never stored anywhere in other people's machines. But practically impossible to carry this out.

Revert the commit: less preferable solution, since the malicious changes are still in git history.

Given this, I'd say anything we can do to prevent this from even happening is good.
Not to mention that relying on hydra taking some time to propagate changes to a channel is definitely a very weak mitigation to a potential security issue.

I'm not against the holding period, it just doesn't fix the security issue addressed in this part of the RFC. What you describe is another issue, that of maintainers merging malicious changes with this bot. What the issue describes is, for example, someone faking the PR in a way that the bot thinks it's a r-ryantm PR (with only pkgs/by-name changes) and merging it therefore directly.

If maintainers merge malicious code, a 24h period could help against that, but then someone would have to check those PRs in the 24h period. The impact also shouldn't be that in big in that case. since the strategy has to be explicitly enabled for a package and if we see malicious action, we either would disable that strategy again on that package, remove the malicious actor from maintainers (and probably all of nixpkgs?) or both. Also we probably would enable maintainer strategies only on low impact leaf packages.

I've scraped multiple attempts at a comment on this because none actually described what feels off about holding period.

but then someone would have to check those PRs in the 24h period

I think this is the crux of the issue. If 99% PRs are totally benign and get merged with maintainer approval, that already means people are going to learn to ignore those, because there's nothing to see, really.

In case of malicious maintainer, they'll have to make it look benign, possibly collude with upstream, at which point a curious person actively has to go look in the package changelog within the holding period. Even that is sure enough to fail because of the sheer number of times I've seen commit message with 'fix'.

In short, I do not think a holding period is going to stop a malicious maintainer. It will be de-facto annoyance to the rest of the folks who are just waiting for the period to be over.

What the mergebot is intended to do in this RFC, IMO does not get any help from a holding period, whether 1h or 1w.

Just my 2c

I'm not against the holding period, it just doesn't fix the security issue addressed in this part of the RFC. [...] What the issue describes is, for example, someone faking the PR in a way that the bot thinks it's a r-ryantm PR (with only pkgs/by-name changes) and merging it therefore directly.

Yes, my interpretation of that part of the RFC wasn't the interpretation you intended. I think calling out the issue you describe doesn't make sense. It's essentially saying "there could be a bug in the code". Obviously the code will try to be as robust as possible :)

Regarding the holding period: I still think it has value, but my motivation to argue for it is gone. My last breath: everyone who will benefit from the non-r-ryantm merging strategies already waits a long time in their PRs. I don't have the data (and would love if someone else had), but from anecdotes all over, it already takes over 24h for people's PRs to get merged (which is what I argued before - reducing the >24h wait to ~24h will still make it fast enough and increase throughput). This bot isn't replacing committers, it's increasing merging throughput. Saying that this will be an annoyance given that this won't make any existing PR workflow slower is silly.

FRidh · 2024-03-27T07:08:42Z

Previous proposal on this topic #50.

Lassulus · 2024-03-27T07:29:23Z

Previous proposal on this topic #50.

ah thanks, #128 also seems to be related, I added them to prior art in the RFC text

Mic92 · 2024-03-27T09:24:38Z

I'd like to nominate for shepard team.

Aleksanaa · 2024-03-27T16:46:41Z

There is also a less common situation where automatic merge may be possible: maintainers updating their own information in maintainer-list.nix.

Mindavi · 2024-03-27T18:10:54Z

There is also a less common situation where automatic merge may be possible: maintainers updating their own information in maintainer-list.nix.

I'd say that it's fine to leave that out of scope for now.

7c6f434c · 2024-03-31T16:54:26Z

rfcs/0172-mergebot.md

+
+### Future extensions
+
+For now we propose that new merge strategies or significant changes to current ones go through their own RFCs. The mergebot team is deciding what is deemed significat in that case.


Maybe add that even minor changes of interpretations of the existing strategies should give some amount of notice (repository issues/thread on the dominant discussion platform) before going live?

yeah, probably new releases on the mergebot repository would be a good idea for this?

I mention Discourse because it reduces the need to consciously subscribe to yet another thing elsewhere to get notifications.

Another thing is — I think a tracking issue+heads-up thread when the development is starting is better because you can promise to give ten days for feedback with less slowdown (development and testing and preparations for deployment are not just an instant).

Also if a change is not universally perceived as small, when the discussion is known to have time to happen we get a better chance to avoid high-tension discussions.

7c6f434c · 2024-03-31T17:01:29Z

rfcs/0172-mergebot.md

+
+## Unresolved Questions
+
+*To be completed*


If a rev-dep maintainer thinks that the dep's mergebot policy is too lax — do we recommend having a pin-like copy with a different policy, or tightening the policy for the main package?

I would suggest tightening it for the main package? like all people depending on a package should be fine with the strategy enabled? and duplicating a package seems like overhead

I agree that this is probably the best trade-off, at least in the beginning, but then it needs to be spelled out in the written policy, as it basically says potentially many people have the right to unilaterally deprive a maintainer of a useful tool.

nixos-discourse · 2024-04-02T15:18:10Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/rfcsc-meeting-2024-04-02/42643/1

JulienMalka · 2024-04-03T21:44:24Z

I'd like to self-nominate to be a shepherd.

infinisil · 2024-04-03T22:07:46Z

I'm also nominating myself as a shepherd

Lassulus · 2024-04-03T23:07:15Z

alrighty, I'm not sure about the exact process. But we have @0x4A6F @JulienMalka @Mic92 and @infinisil who nominated as shepherd, @Mic92 told me he would be ok with lead. So I guess the next step is to find a suitable date for our first call. If anybody else also wants to join up, please mention it here :)

infinisil · 2024-04-04T00:24:42Z

While we have enough shepherds, until the RFC steering committee officially announces the shepherds, nominations are still open. But that's not a blocker for setting up a call already :)

Lassulus · 2024-04-04T14:52:22Z

https://meet.dgnum.eu/rfc172-403705 time to find a date :)

Mic92 · 2024-04-05T11:28:05Z

Ok. It looks like the 16:00 UTC, 19.04.2024 is the best date for us for a first meeting.

lheckemann · 2024-04-16T14:42:39Z

rfcs/0172-mergebot.md

+**Shepherd Team:** `[To be nominated and accepted by the RFC Steering Committee]`  
+**Shepherd Leader:** `[To be appointed by the RFC Steering Committee]`  


Suggested change

**Shepherd Team:** `[To be nominated and accepted by the RFC Steering Committee]`

**Shepherd Leader:** `[To be appointed by the RFC Steering Committee]`

**Shepherd Team:** 0x4A6F, Mic92, JulienMalka, infinisil

**Shepherd Leader:** Mic92

Thank you for your nominations!

nixos-discourse · 2024-04-16T14:46:57Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/rfcsc-meeting-2024-04-16/43512/1

Mic92 · 2024-04-23T12:42:10Z

RFC meeting summary on the 23.04.2024

Attendees: @Mic92 @Lassulus @Scriptkiddi @a-kenji @0xA46F @infinisil

Key Topics Discussed:

Trust and Verification for Maintainers:
- The need to trust the upstream author, a Nixpkgs committer, and with the new RFC, maintainers were emphasized.
- We discussed various ways to vet maintainers, including establishing a trusted maintainer group with the authority to merge their own package PRs, similar to existing practices but scaled for efficiency.
Proposal Enhancements:
- The idea of a JSON interface to limit maintainers to specific actions was considered to prevent them from altering the source code of packages.
- Discussions about establishing a category system for changes in a PR were also highlighted, aiming for different vetting requirements based on the type of change, like version bumps.
Automation and Efficiency:
- Several suggestions were made to automate and streamline processes, such as integrating third-party CI results for version bumps automatically and enhancing ofborg for better CI performance.
- The potential for running NixOS tests more easily and enabling VNC sessions for immediate checks on graphical packages was discussed.
Review Processes:
- The concept of a merge queue managed by committers, as opposed to direct pushes by mergebots, was debated.
- We explored implementing multi-stage review processes, where maintainers first ensure PRs resolve the issues, followed by a security review by committers.
Security Concerns and Workflow Enhancements:
- The potential risk of maintainers switching sources under the guise of maintaining a fork was acknowledged as a significant security concern.
- Improvements in labeling and PR checklists were suggested to clarify what aspects of a PR were reviewed and by whom.

Decisions and Actions:

The group agreed to continue discussions on refining the maintainer vetting process and enhancing automation to reduce manual oversight.
The next meeting is scheduled for two weeks from now, maintaining the fortnightly meeting rhythm to further these discussions and solidify plans.

Full meeting notes

# RFC172 meeting notes

2024-04-19 16:00 UTC

Attendees: @Mic92 @Lassulus @Scriptkiddi @a-kenji @0xA46F @infinisil

next meeting friday in 2 weeks, meetings are aimed fortnightly

Current people we need to trust:
- The upstream author
- A Nixpkgs committer
  - Comes from New nixpkgs committers requests nixpkgs#50105
With this RFC, maintainers need to be trusted
- How to make sure that maintainers are vetted
  - How to validate maintainers at all?
  - And how to make sure the committers know about that and enforce it?
What if there's something like a trusted maintainer group that can merge their own packages PRs
- Kind of similar how it works today, just more scalable
Don't allow maintainers to change the source, only the code
What if there's a JSON interface that restricts what can be done, e.g.
```
{
  "builder": "mkDerivation"
}
```
As a user, when I install hello, I trust the upstream author of the hello package
Possible attack: A maintainer could switch the underlying source, arguing that it's the newly maintained fork.
No self merges?
- Sock puppet accounts defeat that, can't be enforced
- Require people to maintain some packages?
  - Can easily be defeated
Trusted maintainers vetting process
Establish some category system for the changes done in a PR, different requirements for each category
- E.g. version bump
More underlying problem to address? Too much overhead, too many committers losing interest, etc.?
How to resolve?
- Single PR that version bumps every packages?
  - Hard to review, changes how packages get reviewed
- Making it more automated to get feedback to version bumps?
  - E.g. automatically get third-party CI results for version bumps
  - Lassulus: Would still want to check it myself
- Make it easier to run more involved tests like NixOS tests. Currently not easily doable, very resource intensive
  - There's new recent container testing stuff, neat!
  - But there's software really hard to test
- Making it easy for people to get into a VNC (remote) session to immediately check out graphical packages
- Improving ofborg, general PR CI story
  - Building all dependent packages in ofborg
  - Improve evaluation speed, especially to figure out which packages changed
General theme: Make automation better
@fritz: Even if we make automation better, most people just make a couple PRs and don't spend much time after that. Even if we make it 50% more efficient, still not enough time.
- @Mic92: What if mergebot doesn't push directly, but pushes to a merge queue branch
- Committers review the queue
- @infinisil: Doesn't seem realistic
- @Mic92: Would be a single page instead of many to review
- @infinisil: I feel like it would be the same work
@Mic92: As a committer I don't want to have to check whether the PR solves the issue, this should be for maintainers to do
- @infinisil: What if we have stages of review
  - Zeroth stage: CI checks
    - Commit history
    - Formatting
    - ...
  - First stage: Review by maintainers to ensure it fixes the issue
  - Second stage: Security review
    - For a committer, only security is checked
- @Mic92: When I get a checkmark from a reviewer, I'm not sure what was reviewed
  - Reviewers should always have to indicate what they did to check the PR
- @kenji: Like PR checklist but the other way around: Have other people say what they did of the checklist
- Something with labels, currently everybody can label
  - Implementation not important, can be implemented for sure

Domen (1)

Committers (200)
- Trusted maintainers with a vetting process similar to committers (1000?)
- Maintainers (20000)
Interesting idea: Reuse Nix files from upstream -> doesn't require trusting anybody else to update Nix files
- nixpkgs.toml defines package.nix to use, which gets called with callPackage
- Lots of ideas

Naxdy · 2024-05-12T19:46:57Z

rfcs/0172-mergebot.md

+- **automerge_updates:** Merges PRs from r-ryantm automatically if ofBorg checks pass, triggered by PR creation or mention. We strongly recommend to have at least one passthrough test.
+- **automerge_backport:** Automatically merges backport PRs if ofBorg checks pass, triggered by PR creation or mention.
+- **full_consensus:** Requires approval from all maintainers before merging. The bot will notify which maintainers' approvals are pending, triggered by PR approval.
+- **single_maintainer:** Allows a single maintainer's approval to trigger a merge, facilitated by a mention of the bot.


Not sure how to feel about this. Wouldn't single_maintainer make it incredibly easy to introduce less-than-desirable code into that maintainer's packages? Currently, committer access is very hard to obtain and requires a good track record that inspires trust (and rightfully so).

Comparatively, to become a maintainer, you have to "just" get a package accepted into nixpkgs. Once that's done, what's to stop anyone from slipping in a bad change unnoticed, due to the huge number of PRs?

well the maintainer has to introduce that code into his own package. So not sure what the attack vector would be here. like the maintainer probably maintains that package alone (otherwise there would be probably a different merge strategy) and probably introduced it to nixpkgs, so slipping in code is possible through other a bit more obfuscated means. In my opinion the attack vector from outdated packages is far bigger than the ones from maintainers backdooring the packages they maintain.

Worst case scenario I could think of from the top off my head is someone submits a package for a new crypto wallet, then once it's adopted by a number of users, "secretly" (in a way that no one notices, anyway) introduces code that exposes private keys or siphons off funds. Something similar has happened before in the snap store, so it's not a very far-fetched scenario.

We discussed the requirements to become a package maintainer as well. They will probably also need to prove some track record. But their scope will be also more limited than full committers, so they can actual less damage than us having to give out commit rights.

Note that we currently have no policy in place to prevent people from adding themselves to maintainer entries, even if they make no other meaningful changes.

Sure. This policies we need is what this RFC is about.

We discussed the requirements to become a package maintainer as well. They will probably also need to prove some track record.

I think such "vetted maintainers" should be in addition to the type of maintainers we have now, not in replacement.

It should stay possible to be a random driveby contributor, as those are also very useful

nixos-discourse · 2024-05-14T15:01:02Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/rfcsc-meeting-2024-05-14/45414/1

nixos-discourse · 2024-05-28T14:56:28Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/rfcsc-meeting-2024-05-28/46113/1

nh2 · 2024-05-31T01:02:20Z

rfcs/0172-mergebot.md

+We propose augmenting package meta fields with a new attribute set that specifies a list of merge strategies.
+The mergebot will execute all listed strategies in parallel and will proceed with the merge upon one successful strategy, contingent on passing ofborg checks as well.
+
+![](https://pad.lassul.us/uploads/965545d8-8575-41a8-9746-6bcc66f8bb0e.png)


I would like for this section/diagram to discuss/handle the situation of the PR contents changing, e.g. if the owner of the PR force-pushes.

Currently the diagram is written under the assumption that the PR contents don't change at all after PR is created.

If there's no way that this can happen, e.g. because all PRs must be made by r-ryantm, then that assumption should at least be stated explicitly (note also that might change in the future, maybe r-ryantm gets a feature to update PRs automatically to the latest upstream version).

But even better would be if there was explicit transitions in the diagram for what happens if the PR contents change.

It should also be discussed somehwere whether it's even technically possible to notice PR content changs in a race-free fashion.

In general, the potential threat should be acknowledged that the merge bot makes a decision on a PR state, and then a malicious PR author force-pushes a malicious change to trick the bot to merge something else.

The current implementation takes the current revision of the PR at the point in time when the merge is triggered.

So for example: someone creates a PR, someones triggers the merge action, then after the merge action is triggered but before the merge is done, the author force pushes to the PR again with some malicious changes. In that case the merge would fail and buildbot would report that (github has this feature, that you can specify a revision in a merge action)

nh2 · 2024-05-31T01:19:12Z

rfcs/0172-mergebot.md

+
+### Limitation to `pkgs/by-name` Directory
+
+To ensure accuracy in processing PRs, only those within the `pkgs/by-name` directory will be considered, due to the challenge of verifying if a PR solely affects the intended files.


Should be stated somewhere:

Does the nix language guarantee that a limitation to a certain file (or subtree) prevents me from overriding packages somewhere else in the evaluated package attribute tree?

Or could a malicious users pull tricks to write magic trickery ala

{ pkgs, lib, ...}: (some Nix builtin that allows injection into the final global attrset here, or some nixpkgs magic attributes that nixpkgs interprets) (mkDerivation # ... )

afaik pkgs/by-name limits exactly that. so there are no side effects on other packages.

nyabinary · 2024-05-31T01:22:21Z

Is a review bot in scope for this as well?

nixos-discourse · 2024-06-10T15:50:10Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/rfcsc-meeting-2024-06-10/46817/1

nixos-discourse · 2024-06-24T15:46:58Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/rfcsc-meeting-2024-06-24/47589/1

[0172] Mergebot

544744f

Lassulus force-pushed the mergebot branch from 1033036 to 544744f Compare March 26, 2024 18:49

Lassulus changed the title ~~[0000] Mergebot~~ [RFC 0172] Mergebot Mar 26, 2024

infinisil reviewed Mar 26, 2024

View reviewed changes

Mindavi reviewed Mar 26, 2024

View reviewed changes

DanielSidhion reviewed Mar 27, 2024

View reviewed changes

Make the scope of this RFC more clear in the summary

4727de4

mention earlier RFCs

74171e8

7c6f434c reviewed Mar 31, 2024

View reviewed changes

MMesch added the status: open for nominations Open for shepherding team nominations label Apr 2, 2024

lheckemann reviewed Apr 16, 2024

View reviewed changes

Naxdy reviewed May 12, 2024

View reviewed changes

GetPsyched added status: in discussion and removed status: open for nominations Open for shepherding team nominations labels May 14, 2024

nh2 reviewed May 31, 2024

View reviewed changes

Mic92 mentioned this pull request Jun 7, 2024

Allow commiters to merge any PR after CI is green NixOS/nixpkgs-merge-bot#95

Open

ShamrockLee mentioned this pull request Jul 3, 2024

argc: 1.14.0 -> 1.17.0 NixOS/nixpkgs#292869

Closed

13 tasks


		![](https://pad.lassul.us/uploads/f24e0ff3-117a-4167-8f60-79ca508b8c1c.png)

		The current `nixpkgs` contribution model relies heavily on a group of committers (approximately 200 at the time of writing), who possess exclusive rights to merge PRs. This model has remained unchanged since its inception and poses limitations on community contributions and maintainer workload. Implementing granular merge permissions will enable a broader contribution base and lessen the burden on existing committers by empowering package maintainers with more control over their respective packages.


		Proposed strategies are:

		- automerge_updates: Merges PRs from r-ryantm automatically if ofBorg checks pass, triggered by PR creation or mention. We strongly recommend to have at least one passthrough test.


		## Drawbacks

		- Security Risks: There's a potential for malicious actors to manipulate the merge bot to authorize merges improperly. A mitigation for these pull requests could be running validity checks (e.g file size limits, valid nix files, ..)


		### Future extensions

		For now we propose that new merge strategies or significant changes to current ones go through their own RFCs. The mergebot team is deciding what is deemed significat in that case.

		Shepherd Team: `[To be nominated and accepted by the RFC Steering Committee]`
		Shepherd Leader: `[To be appointed by the RFC Steering Committee]`


		### Limitation to `pkgs/by-name` Directory

		To ensure accuracy in processing PRs, only those within the `pkgs/by-name` directory will be considered, due to the challenge of verifying if a PR solely affects the intended files.

[RFC 0172] Mergebot #172

Are you sure you want to change the base?

[RFC 0172] Mergebot #172

Conversation

Lassulus commented Mar 26, 2024 • edited by asymmetric Loading

0x4A6F commented Mar 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

philiptaron commented Mar 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Lassulus Mar 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nixos-discourse commented Mar 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

FRidh commented Mar 27, 2024

Lassulus commented Mar 27, 2024

Mic92 commented Mar 27, 2024

Aleksanaa commented Mar 27, 2024 • edited Loading

Mindavi commented Mar 27, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nixos-discourse commented Apr 2, 2024

JulienMalka commented Apr 3, 2024

infinisil commented Apr 3, 2024

Lassulus commented Apr 3, 2024

infinisil commented Apr 4, 2024

Lassulus commented Apr 4, 2024

Mic92 commented Apr 5, 2024

Choose a reason for hiding this comment

nixos-discourse commented Apr 16, 2024

Mic92 commented Apr 23, 2024 • edited Loading

RFC meeting summary on the 23.04.2024

2024-04-19 16:00 UTC

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Naxdy May 12, 2024 • edited Loading

Choose a reason for hiding this comment

Mic92 May 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nixos-discourse commented May 14, 2024

nixos-discourse commented May 28, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nyabinary commented May 31, 2024

nixos-discourse commented Jun 10, 2024

nixos-discourse commented Jun 24, 2024

Lassulus commented Mar 26, 2024 •

edited by asymmetric

Loading

philiptaron commented Mar 26, 2024 •

edited

Loading

Lassulus Mar 27, 2024 •

edited

Loading

Aleksanaa commented Mar 27, 2024 •

edited

Loading

Mic92 commented Apr 23, 2024 •

edited

Loading

Naxdy May 12, 2024 •

edited

Loading

Mic92 May 14, 2024 •

edited

Loading