What the developer wrote
Authored by Justin Ehrenhofer
Skip fetching unused submodules
What changed, and why it matters
This commit changes three build scripts so they only download two specific submodules ('monero' and 'lwsf') instead of all submodules. The stated reason is reliability: unused submodules for other coins can cause build failures when their hosting servers are unavailable. There is no direct security vulnerability here, but narrowing submodule checkout reduces the attack surface slightly by preventing unused, potentially untrusted third-party code from being fetched during the build.
No immediate security action required. Review whether the 'monero' and 'lwsf' submodules themselves are pinned to trusted, audited commits, and consider documenting the rationale for submodule selection in build documentation.
Security signals we found
Build script change limiting submodule checkout scope
Reduced fetch of third-party dependencies during build
No direct vulnerability or exploit mechanism introduced
Evidence from the diff
The patch modifies build scripts (build-moneroc-local.sh, build-moneroc.sh, repro/build-moneroc-so.sh) to pass explicit paths (‘monero’ and ‘lwsf’) to git submodule update --init --recursive --force. Previously these commands would recursively initialize all submodules of the monero_c repository. The change is framed as a build reliability improvement, not a security fix. It does not alter code execution paths, permissions, or cryptographic operations in the wallet itself.
Changed components
scripts/build-moneroc-local.shscripts/build-moneroc.shscripts/repro/build-moneroc-so.shInspect captured patch +9 / −3
### scripts/build-moneroc-local.sh
@@ -82,7 +82,9 @@ for ARCH in "${ARCHS[@]}"; do
cd "$work"
git fetch --quiet origin "$REF" || true
git checkout --quiet "$REF"
- git submodule update --init --recursive --force
+ # Only the submodules a Monero build uses; the others are for other coins,
+ # and fetching them fails the build whenever one of their hosts is down.
+ git submodule update --init --recursive --force -- monero lwsf
# Deterministic version hash (git am committer date) as in the repro build.
export SOURCE_DATE_EPOCH="$(git log -1 --format=%ct)"
### scripts/build-moneroc.sh
@@ -27,7 +27,9 @@ git config --global user.email 'info@magicgrants.org'
rm -rf /tmp/monero_c
git clone "$SRC" /tmp/monero_c
git -C /tmp/monero_c checkout "$COMMIT"
-git -C /tmp/monero_c submodule update --init --recursive --force
+# Only the submodules a Monero build uses; the others are for other coins,
+# and fetching them fails the build whenever one of their hosts is down.
+git -C /tmp/monero_c submodule update --init --recursive --force -- monero lwsf
cd /tmp/monero_c
# Pin the git-am committer date (baked into Monero's version string) + __DATE__/__TIME__.
### scripts/repro/build-moneroc-so.sh
@@ -68,7 +68,9 @@ docker run --rm \
git clone --quiet https://github.com/magicgrants/monero_c.git "$work"
cd "$work"
git checkout --quiet "$REF"
- git submodule update --init --recursive --force --quiet
+ # Only the submodules a Monero build uses; the others are for other coins,
+ # and fetching them fails the build whenever one of their hosts is down.
+ git submodule update --init --recursive --force --quiet -- monero lwsf
# Pin timestamps BEFORE patching. apply_patches.sh runs `git am`, whose commit
# SHA depends on the committer date; Monero bakes that short-hash into its
# version string (0.18.4.0-<hash>). Fix the date so the hash is deterministic.Why this scored 18/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.