vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

swarm-controller: push-whitelist the daemon's own account for the config-repo seed commit

Browse source
This commit is contained in:
damocles 2026-08-24 22:16:59 +02:00
commit d65edc5ac0
1 changed files with 29 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

32
swarm-controller/src/forge.rs
View file

@ -76,6 +76,19 @@ const CONFIG_ORG: &str = "agent-configs";
const KNOWLEDGE_ORG: &str = "internal";
const KNOWLEDGE_REPO: &str = "knowledge";
/// This daemon's own forge account — same constant as
/// `swarm-controller.nix`'s `swarmControllerForgeUser` (`hive-forge/default.nix`).
/// Needed in the branch-protection push whitelist (see
/// [`Client::apply_operator_branch_protection`]): being a site admin does
/// not exempt a caller from a protected branch's push check on the
/// content-edit API path (`repo_change_files`, what [`Client::seed_agent_config`]
/// uses) the way it does for a real `git push` — confirmed live against a
/// re-test where the account was already promoted to admin and the seed
/// commit still failed `ErrUserCannotCommit`. Whitelisting the account by
/// name is the same shape a git-push-based seed gets for free from the
/// admin bypass, without adding a `git` shell-out to this daemon.
const SWARM_CONTROLLER_FORGE_USER: &str = "swarm-controller";
/// The env vars `swarm-controller.nix`'s `forgeEnv` sets. Named here
/// once so [`Client::from_env`] and the nix module can't drift silently
/// — a rename on one side without the other fails loudly (env var
@ -205,6 +218,19 @@ impl Client {
/// only treats it as success if the rule is actually present — a
/// fail-open merge gate is a security bug, not a shrug.
///
/// Also push-whitelists [`SWARM_CONTROLLER_FORGE_USER`] alone —
/// [`Client::seed_agent_config`]'s initial commit is a direct push to
/// this same protected `main`, and being a site admin does not
/// exempt the content-edit API path from a protected branch's push
/// check the way a real `git push` is exempted (confirmed live: an
/// already-admin-promoted account still hit `ErrUserCannotCommit`
/// here). `hive-c0re`'s equivalent seed avoids the whole question by
/// seeding through an actual `git push`, which the admin bypass does
/// cover — this daemon has no `git` shell-out, so an explicit
/// whitelist entry is the narrower fix. The agent (a write
/// collaborator, not on this whitelist) still cannot push directly,
/// so this doesn't loosen the "can't merge your own PR" guarantee.
///
/// Assumes [`OPERATORS_TEAM`] already exists in [`CONFIG_ORG`]
/// (provisioned by `hive-c0re::forge::repos::ensure_operators_team`
/// on its own startup sweep, not re-provisioned here) — if it
@ -223,8 +249,8 @@ impl Client {
dismiss_stale_approvals: None,
enable_approvals_whitelist: Some(true),
enable_merge_whitelist: Some(true),
enable_push: None,
enable_push_whitelist: None,
enable_push: Some(true),
enable_push_whitelist: Some(true),
enable_status_check: None,
ignore_stale_approvals: None,
merge_whitelist_teams: Some(vec![OPERATORS_TEAM.to_owned()]),
@ -232,7 +258,7 @@ impl Client {
protected_file_patterns: None,
push_whitelist_deploy_keys: None,
push_whitelist_teams: None,
push_whitelist_usernames: None,
push_whitelist_usernames: Some(vec![SWARM_CONTROLLER_FORGE_USER.to_owned()]),
require_signed_commits: None,
required_approvals: Some(1),
rule_name: None,