In a world, where bors.tech will be our policy enforcement agent (as oposed to a trusted policy decision agent), we are confronted with the problem, that bors needs to adapt its enforcement not only to changing metadata of the PR itself, but also to changing metadata of it’s head commit in ways that are not subject to race conditions. Currently any policy decision implemented on the Github comment interface via
bors delegate= is sticky and does not automatically go away if subsequent malicious commits are pushed to the PR.
While there is a blocking label scheme in bors that could be combined with a Github action that marks any new commit as untrusted (and thereby blocked from merging), this does not seem to afford us adapting a
bors delegate= implemented decision including revoking delegation. Fortunately, bors has a very vibrant RFC process, so we should consider to submit a RFC once the use case is completely fleshed out on our side.
Using their RFC process as a community might enable us to improve bors in ways where it is put in a genuine position to consult and enforce policy decisions made by a trusted policy agent all by it’s own over the corresponding interfaces. Such tighter coupling with a policy agent is also a very interesting use case for the broader bors community, and I would wish for our community to earn the credits.
- Bors community could benefit from such a diverse mega project such as ours.
- nix* community could co-evolve with the broader bors community on the subject of matter.
- The capability to adapt enforcement based on commit metadata seems to be a prerequisite of its own right to fix holes in our (emerging) trust model that’s currently not possible to achieve through an off-the-shelf bors implementation.