nigig-org

History

nigig-ci 34fecf1924 build: pin every git dependency to a full 40-character SHA (Phase 0.2) The repo has a CI gate requiring full-length revs, added deliberately in `5e71457` with a comment explaining that an abbreviated rev resolves only while no other object shares its prefix -- a property of the repository's current object count, not a guarantee. Git's abbreviation length grows as a repo grows, so a short pin silently becomes ambiguous, and an attacker able to push to the fork can try to manufacture a colliding prefix. That gate has been failing. 42 declarations across 34 crates used abbreviated revs: 41x rev = "ecf5a572" (the current makepad pin) 1x rev = "5efe6e24c" (map/tests/makepad_test_app, left behind by the `ce0eaae` bump) Resolved both against the remote and rewrote them: ecf5a572 -> ecf5a572ab62a1c1598909971f602f99083671cc 5efe6e24c -> 5efe6e24c9f732e9f11b783757f196f4f1c402b2 Verified this changes the LABEL and not the dependency: Cargo.lock holds exactly one makepad commit id and zero references to the old one, so nothing was silently upgraded. The stray makepad_test_app pin did move to the current rev, which is the intent -- it pointed at a stale branch head. Cargo.lock also picks up unrelated churn (brotli et al in, makepad-android-state/jni-sys out). That staleness is PRE-EXISTING, not caused by this change: confirmed by stashing every edit and running `cargo metadata` on a pristine tree, which produces the identical diff. Gate now passes: $ grep -rn 'rev = ' --include=Cargo.toml . \| grep -vE 'rev = "[0-9a-f]{40}"' (no output)	2026-08-16 18:35:39 +00:00
..
src	Initial commit	2026-07-26 19:38:26 +03:00
Cargo.toml	build: pin every git dependency to a full 40-character SHA (Phase 0.2)	2026-08-16 18:35:39 +00:00

nigig-ci 34fecf1924 build: pin every git dependency to a full 40-character SHA (Phase 0.2)

The repo has a CI gate requiring full-length revs, added deliberately in
5e71457 with a comment explaining that an abbreviated rev resolves only
while no other object shares its prefix -- a property of the repository's
current object count, not a guarantee. Git's abbreviation length grows as
a repo grows, so a short pin silently becomes ambiguous, and an attacker
able to push to the fork can try to manufacture a colliding prefix.

That gate has been failing. 42 declarations across 34 crates used
abbreviated revs:

    41x  rev = "ecf5a572"    (the current makepad pin)
     1x  rev = "5efe6e24c"   (map/tests/makepad_test_app, left behind
                              by the ce0eaae bump)

Resolved both against the remote and rewrote them:

    ecf5a572  -> ecf5a572ab62a1c1598909971f602f99083671cc
    5efe6e24c -> 5efe6e24c9f732e9f11b783757f196f4f1c402b2

Verified this changes the LABEL and not the dependency: Cargo.lock holds
exactly one makepad commit id and zero references to the old one, so
nothing was silently upgraded. The stray makepad_test_app pin did move to
the current rev, which is the intent -- it pointed at a stale branch head.

Cargo.lock also picks up unrelated churn (brotli et al in,
makepad-android-state/jni-sys out). That staleness is PRE-EXISTING, not
caused by this change: confirmed by stashing every edit and running
`cargo metadata` on a pristine tree, which produces the identical diff.

Gate now passes:
  $ grep -rn 'rev = ' --include=Cargo.toml . | grep -vE 'rev = "[0-9a-f]{40}"'
  (no output)

2026-08-16 18:35:39 +00:00

src Initial commit 2026-07-26 19:38:26 +03:00

Cargo.toml build: pin every git dependency to a full 40-character SHA (Phase 0.2) 2026-08-16 18:35:39 +00:00