flake-update-cascade commits and pushes to any workspace repo, including third-party checkouts with a GitHub origin #172

New issue

Closed

opened 2026-09-08 17:38:59 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-09-08 17:38:59 +01:00

Contributor

flake-update-cascade in its default mode committed a lock update on the default branch of a third-party upstream checkout living under the workspace root, whose origin is https://github.com/..., and then ran git push against it, which stopped at Username for 'https://github.com':. The push never completed, so nothing reached GitHub, but the tool had already committed to that repository's main and was one credential away from pushing to a remote outside the forge.

Symptom

Run on 2026-09-08 on the host, in default (direct-commit) mode, with the input list flake-status --upstream suggested. Every workspace repository with a flake.lock was processed; the last one was the upstream checkout:

==> <upstream checkout>
  pulling...
Already up to date.
  updating crane dart-overlay nixpkgs nixpkgs-unstable rust-overlay...
[main 8172954c] flake.lock: update nur, dart-overlay, nixpkgs-unstable, nixpkgs-tailscale, home-manager, rust-overlay, forge-nixpkgs, crane, nixpkgs
 1 file changed, 15 insertions(+), 15 deletions(-)
Username for 'https://github.com':

The input names that pulled that repository into the run (crane, dart-overlay, rust-overlay) came from the Outdated (external) suggestion line of flake-status --upstream, which lists inputs from every repository under the workspace root without distinguishing forge repositories from third-party checkouts.

Evidence

The documented pre-flight checks are: not on the default branch, dirty working tree, unpushed commits, no flake.lock, input absent or a follows, and a ~/.config/git/protected-branches entry. None of them looks at where origin points. On this host the checkout was not listed in protected-branches, so it was eligible, and the direct-mode path is commit then git push with no remote check between them.

The same run also committed and pushed directly to the master of four framework repositories, which is the documented default-mode behaviour when they are not listed in protected-branches on the machine running the tool.

Recovery was Ctrl+C at the prompt and git reset --hard origin/main in the upstream checkout.

`flake-update-cascade` in its default mode committed a lock update on the default branch of a third-party upstream checkout living under the workspace root, whose `origin` is `https://github.com/...`, and then ran `git push` against it, which stopped at `Username for 'https://github.com':`. The push never completed, so nothing reached GitHub, but the tool had already committed to that repository's `main` and was one credential away from pushing to a remote outside the forge. ### Symptom Run on 2026-09-08 on the host, in default (direct-commit) mode, with the input list `flake-status --upstream` suggested. Every workspace repository with a `flake.lock` was processed; the last one was the upstream checkout: ``` ==> <upstream checkout> pulling... Already up to date. updating crane dart-overlay nixpkgs nixpkgs-unstable rust-overlay... [main 8172954c] flake.lock: update nur, dart-overlay, nixpkgs-unstable, nixpkgs-tailscale, home-manager, rust-overlay, forge-nixpkgs, crane, nixpkgs 1 file changed, 15 insertions(+), 15 deletions(-) Username for 'https://github.com': ``` The input names that pulled that repository into the run (`crane`, `dart-overlay`, `rust-overlay`) came from the `Outdated (external)` suggestion line of `flake-status --upstream`, which lists inputs from every repository under the workspace root without distinguishing forge repositories from third-party checkouts. ### Evidence The documented pre-flight checks are: not on the default branch, dirty working tree, unpushed commits, no `flake.lock`, input absent or a `follows`, and a `~/.config/git/protected-branches` entry. None of them looks at where `origin` points. On this host the checkout was not listed in `protected-branches`, so it was eligible, and the direct-mode path is commit then `git push` with no remote check between them. The same run also committed and pushed directly to the `master` of four framework repositories, which is the documented default-mode behaviour when they are not listed in `protected-branches` on the machine running the tool. Recovery was `Ctrl+C` at the prompt and `git reset --hard origin/main` in the upstream checkout.

vnprc referenced this issue from a commit

2026-09-08 17:50:04 +01:00

flake-update-cascade: refuse repositories whose origin is outside the forge

allod-agent commented

2026-09-09 20:13:33 +01:00

Member

Fixed on master by 536c8b3 (flake-update-cascade: refuse repositories whose origin is outside the forge), which landed the same day this was filed and predates the Go port that followed it.

What the tool does now, in every mode including the direct-commit default: a repository whose origin is not the forge and is not listed in ~/.config/git/allowed-external-remotes is skipped with a notice and is never pulled, updated, committed to, or pushed. The README documents it under the pre-flight checks, and tests/flake/flake-update-cascade/external-remote.sh pins it against exactly this shape, a checkout with a https://github.com/... origin, asserting the skip notice and the absence of any git mutation, plus the allowlist path for a deliberately permitted external remote. The suite runs under nix flake check.

The Outdated (external) line from flake-status --upstream still names inputs from every repository under the workspace root, third-party checkouts included, so the suggested command can still list an input that only such a checkout pins. That is now harmless: the cascade reports the skip and touches nothing. The separate defect in that line, comparing every pin to the default branch, was allod/tools#170 and is fixed.

Fixed on master by 536c8b3 (flake-update-cascade: refuse repositories whose origin is outside the forge), which landed the same day this was filed and predates the Go port that followed it. What the tool does now, in every mode including the direct-commit default: a repository whose `origin` is not the forge and is not listed in `~/.config/git/allowed-external-remotes` is skipped with a notice and is never pulled, updated, committed to, or pushed. The README documents it under the pre-flight checks, and `tests/flake/flake-update-cascade/external-remote.sh` pins it against exactly this shape, a checkout with a `https://github.com/...` origin, asserting the skip notice and the absence of any git mutation, plus the allowlist path for a deliberately permitted external remote. The suite runs under `nix flake check`. The `Outdated (external)` line from `flake-status --upstream` still names inputs from every repository under the workspace root, third-party checkouts included, so the suggested command can still list an input that only such a checkout pins. That is now harmless: the cascade reports the skip and touches nothing. The separate defect in that line, comparing every pin to the default branch, was allod/tools#170 and is fixed.

allod-agent closed this issue

2026-09-09 20:13:33 +01:00