Found during a code audit
While auditing the Git source-resolution code I noticed an inconsistency in how pinned SHA1s are looked up from config/sources/git_sources.json. Filing for visibility — unsure whether it is worth fixing.
Context
The pinned-SHA lookup keys on source (the Git URL) + branch. Two code paths read it, and they key on different forms of the URL:
lib/functions/general/git-ref2info.sh (artifact version resolution / config-dump) keys on the canonical source — the same value it writes into the JSON (GIT_SOURCE, e.g. https://github.com/armbian/linux-rockchip.git). Mirror substitution there is applied only to the live ls-remote call, not to the stored or looked-up key.lib/functions/general/git.sh → fetch_from_repo() keys on $url after the GITHUB_SOURCE substitution at git.sh:89 (sed "s|^https://github.com/|${GITHUB_SOURCE}/|").
Effect
- Default (no
GITHUB_MIRROR): GITHUB_SOURCE=https://github.com, so the sed is a no-op. Both paths use the canonical key, they match — no problem.
- With a mirror (
GITHUB_MIRROR=ghproxy|gitclone|...): fetch_from_repo's key becomes mirror-prefixed (e.g. https://<ghproxy>/https://github.com/armbian/linux-rockchip.git) while the JSON stores the canonical https://github.com/.... The lookup misses, so fetch_from_repo silently skips the pin and checks out the live branch HEAD, while git-ref2info still applies the pinned SHA. The two diverge.
Scope / severity
config/sources/git_sources.json is optional and not present in the repo; this only affects setups that maintain a pinned JSON and use a Git mirror. Default builds are unaffected.
Repro (conceptual)
- Set
GITHUB_MIRROR=ghproxy (or any non-github mirror).
- Create
config/sources/git_sources.json with a pin for a https://github.com/... source + branch used by the build.
- Build that board/branch.
fetch_from_repo ignores the pin (checks out live HEAD); config-dump / artifact versioning uses the pin.
Question
Is this worth fixing (e.g. have fetch_from_repo key the lookup on the pre-substitution URL so both paths agree), or is the current behavior acceptable given the JSON is optional and mirrors are uncommon?
Found during a code audit
While auditing the Git source-resolution code I noticed an inconsistency in how pinned SHA1s are looked up from
config/sources/git_sources.json. Filing for visibility — unsure whether it is worth fixing.Context
The pinned-SHA lookup keys on
source(the Git URL) +branch. Two code paths read it, and they key on different forms of the URL:lib/functions/general/git-ref2info.sh(artifact version resolution / config-dump) keys on the canonical source — the same value it writes into the JSON (GIT_SOURCE, e.g.https://github.com/armbian/linux-rockchip.git). Mirror substitution there is applied only to the livels-remotecall, not to the stored or looked-up key.lib/functions/general/git.sh→fetch_from_repo()keys on$urlafter theGITHUB_SOURCEsubstitution at git.sh:89 (sed "s|^https://github.com/|${GITHUB_SOURCE}/|").Effect
GITHUB_MIRROR):GITHUB_SOURCE=https://github.com, so the sed is a no-op. Both paths use the canonical key, they match — no problem.GITHUB_MIRROR=ghproxy|gitclone|...):fetch_from_repo's key becomes mirror-prefixed (e.g.https://<ghproxy>/https://github.com/armbian/linux-rockchip.git) while the JSON stores the canonicalhttps://github.com/.... The lookup misses, sofetch_from_reposilently skips the pin and checks out the live branch HEAD, whilegit-ref2infostill applies the pinned SHA. The two diverge.Scope / severity
config/sources/git_sources.jsonis optional and not present in the repo; this only affects setups that maintain a pinned JSON and use a Git mirror. Default builds are unaffected.Repro (conceptual)
GITHUB_MIRROR=ghproxy(or any non-github mirror).config/sources/git_sources.jsonwith a pin for ahttps://github.com/...source + branch used by the build.fetch_from_repoignores the pin (checks out live HEAD); config-dump / artifact versioning uses the pin.Question
Is this worth fixing (e.g. have
fetch_from_repokey the lookup on the pre-substitution URL so both paths agree), or is the current behavior acceptable given the JSON is optional and mirrors are uncommon?