Enforce 4-eyes approvals for all pushes (remove admin self-approval bypass)

[andypols]

Right now, the “approve push request” check prevents users from approving their own changes — except when the user is an admin. That means an admin can effectively bypass the 4-eyes principle.

We’d like to enforce 4-eyes approval on all changes pushed through git-proxy, regardless of role, so that no one can approve their own changes.

  if (list[0].username.toLowerCase() === username.toLowerCase() && !list[0].admin) {
    res.status(403).send({
      message: `Cannot approve your own changes`,
    });
    return;
  }

Proposal

Remove the !list[0].admin bypass so self-approval is always forbidden.

Rationale

• Keeps approvals consistent and audit-friendly across all users
• Reduces risk for privileged accounts (admins are higher-impact)
• Matches the typical expectation that “admin” shouldn’t mean “no review required”

I could make this configurable, but that feels like the wrong default (and potentially easy to misconfigure).

Question for maintainers/users

Does anyone actively rely on the admin self-approval bypass today?
If so, what’s the real-world use case that requires it?

[kriswest]

We don't use this bypass and don't object to it being removed.

However, we've also discussed the need for a feature that does allow bypass of the requirement for approvals for particular contributors (/maintainers) on specified projects - where a firm's internal contribution policies permit.

The requirement for reviews can sometimes add friction to contribution, for project maintainers in particular where frequent smaller contributions need to be made. Such contributors would generally be senior engineers in a firm and potentially trusted to contribute and represent their firm without tight supervision - but still require auditable logs of their contributions and/or a feature to facilitate periodic review. Any such bypass would not apply to other contributors from that firm.

That's not the same issue - but clearly related and something we should discuss alongside this issue. I've added #1365 to represent that.