AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 60 Monero

Dockerfiles: fetch dependencies over https instead of git:// / http://

Public commit record

What the developer wrote

Authored by Thomas

81/100 · Strong
Dockerfiles: fetch dependencies over https instead of git:// / http://

The release Dockerfiles cloned Qt (code.qt.io) and libgpg-error/libgcrypt
(git.gnupg.org) over unauthenticated git://, and fetched libiconv
(ftp.gnu.org) over http://. Qt is tag-pinned only, so a MITM on its clone
could substitute source into the build. Switch them all to https, like
every other dependency in these files. The gnupg commit pins and the
libiconv sha256sum are unchanged.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit changes how the Monero GUI's release build containers download some important software libraries. Previously, several libraries were downloaded over unencrypted or unauthenticated connections (git:// and http://), which could allow a network attacker to tamper with the downloaded code before it was compiled into Monero's release binaries. The commit switches those downloads to https, which provides encryption and server authentication. The commit message explicitly notes that the Qt library was only pinned by tag, so a man-in-the-middle attacker could have substituted malicious Qt source code into the build. The other libraries (libgpg-error, libgcrypt, libiconv) had additional integrity checks (commit hash pins or sha256sum), so the practical risk there was lower, but the change still removes an unnecessary weak link.

Recommended action

Verify that the new https URLs resolve to the same upstream repositories and that the build still succeeds. Consider adding commit-hash pinning for Qt clones (as already done for libgpg-error/libgcrypt) and enabling git's transfer.fsckObjects or similar verification. Review other Dockerfiles and build scripts for remaining git:// or http:// dependency fetches. No immediate user action is required, but release builders should ensure they rebuild with this commit included.

Security signals we found

01

Unauthenticated git:// protocol used for source code retrieval

02

Unencrypted http:// used for source tarball retrieval

03

Qt source cloned by tag only, without commit-pin verification before build

04

Build-time dependency integrity improvement

05

Supply-chain / build pipeline hardening

Risk score

Why this scored 60/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 8/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.