aurupdater

qt5-doc

Build times (auto-updated)

Category: arch/maintained/qt5-doc.

2026-09-07: open AUR bug – source download returns a CDN-redirect XML stub outside certain regions

Reported by EndlessEden (2026-08-31, followed up 2026-09-01) and andreas_baumann initially replied “cannot reproduce” (2026-08-31 – downloads fine from here). EndlessEden followed up with a concrete repro: for them (Southern Hemisphere, no local CDN mirror), qt-everywhere-opensource-src-5.15.19.tar.xz downloads as an XML document (file reports “XML 1.0 document, ASCII text”) listing CDN mirror candidates instead of the real tarball – posted the actual XML content as a gist. Package’s own out-of-date flag has been set since 2026-08-31 (still active as of 2026-09-07, FLAG ... since=2026-09-01 per FEEDBACK.txt).

Suggested fix (EndlessEden, 2026-09-01): in prepare(), download the source, check whether it’s actually the .xz tarball or the XML redirect stub, and if XML, parse it for the right regional URL and re-fetch – i.e. don’t trust Qt’s download-page redirect logic to always land on a real file.

2026-09-08: fixed (pkgrel 1 -> 2) – manual fetch + XML-fallback in prepare()

Implemented per EndlessEden’s suggestion, user approved. The XML EndlessEden posted is a MirrorBrain metalink4 document (<metalink xmlns="urn:ietf:params:xml:ns:metalink">) – confirmed its <hash type="sha-256"> matches this package’s already-pinned checksum exactly, i.e. it genuinely describes the right file, just via mirror metadata instead of a real HTTP redirect.

Moved the qt tarball entirely out of source=()/sha256sums=() (kept only the two patch files there) – makepkg validates source=() checksums before prepare() ever runs, so leaving the tarball there would abort on the XML stub before any fallback logic could execute. prepare() now: curls the normal download.qt.io URL itself; if the first 5 bytes are literally <?xml (the stub always starts this way, real .tar.xz starts with the XZ magic bytes), greps the XML for the first <url location="..." priority="N">...</url> entry (MirrorBrain lists mirrors in priority order, nearest first) and refetches from there; verifies the final file against the pinned sha256 by hand (sha256sum -c) since makepkg no longer does it automatically; then bsdtar -xfs it before the existing patch logic. curl needs no new makedepends entry – pacman itself already depends on it (its own DLAGENTS downloader).

Regex gotcha caught in testing: an earlier version of the parser (<url[^>]*>[^<]+</url>, no attribute requirement) matched the wrong tag – the XML’s <publisher><url>https://download.qt.io</url> entry, which has no attributes and appears earlier in the document than the real mirror list. Fixed by requiring both location="..." and priority="..." attributes in the pattern, which only the real mirror <url> entries have.

2026-09-09: hardened the mirror-XML fallback (pkgrel 2 -> 3), not yet rebuilt/republished

User asked for a security-style look at prepare() (“suspicious package… what is happening”). Not malicious – this is the 2026-09-08 fix above – but two real gaps in the mirror-URL handling:

  1. The URL extracted from the MirrorBrain XML (grep+sed) was handed straight to curl with no scheme validation and no -- before it. If that extracted string ever started with - (e.g. the XML content were attacker-influenced), curl would parse it as a flag instead of a URL – classic argument injection, could redirect curl’s own -o output. Fixed: a case "$_url" in https://*) ;; *) return 1;; esac scheme check before the refetch, plus curl ... -- "$_url" to stop option parsing regardless.
  2. test -n "$_url" after the extraction was a no-op guard – nothing checked its exit status (no || return 1, no set -e), so an empty match just fell through to a curl -o file "" that failed on its own with a less clear error. The new case above replaces it and actually return 1s on both an empty and a non-https match.

The pinned $_qt_sha256 check afterward was always the real safety net regardless (a tampered/wrong file still can’t pass it) – these are hardening of the path, not a fix to a live vulnerability.

Verified before publishing, without a full multi-hour doc build: happy-path curl fetch + checksum in isolation (real xz, passed); XML-fallback path against EndlessEden’s actual posted gist content (correctly detected the stub, parsed https://mirror.aarnet.edu.au/pub/qtproject/.../qt-everywhere-opensource-src-5.15.19.tar.xz, refetched, checksum passed); and confirmed bsdtar -tf on the real tarball extracts to exactly qt-everywhere-src-5.15.19 (matching ${_pkgfqn/opensource-/}, what the rest of prepare()/build()/ package() already expect). Its first real build attempt (pkgrel 3, same day) failed anyway – see below – so this was never actually published.

2026-09-09: reverted the whole curl/XML-fallback approach (pkgrel 2 -> 3, content back to 1fd84a1)

User’s call, after looking at the hardened version above: “this looks suspiciously like a curl injection” – and even with the https:// scheme check and -- argument-stop added, having prepare() fetch and shell out based on content parsed from a third-party mirror listing is exactly the kind of pattern that reads as a supply-chain/injection risk on sight, independent of whether this particular instance was actually exploitable. Not worth keeping for a make docs-only convenience fix. Reverted source=()/sha256sums=() /prepare() to exactly commit 1fd84a17162e51079b1d88597518db5bfc0045 44 (updated to 5.15.19, the last commit before the workaround), i.e. back to a plain pinned-URL source=() entry with no custom fetch logic at all – pkgrel kept moving forward to 3 rather than reused as 1, since 2 (the curl-workaround version) was already live. The known tradeoff (per the original 2026-09-07 AUR bug thread) is back too: someone building in a region with no local CDN mirror may get the MirrorBrain XML stub instead of the real tarball – the accepted mitigation is that they download the real tarball themselves and drop it in makepkg’s SRCDEST/source cache before building, a normal AUR pattern for problematic sources, not a PKGBUILD-side fix.

Separately, the very first build attempt of the hardened pkgrel-3 version (launched right after the hardening) failed outright on make docs with a wave of error: 'stddef.h' file not found / unknown type name 'ptrdiff_t' / INT_MAX undeclared errors under qtbase/include/QtGui/... and QtWidgets/... – never got far enough to know if that’s a real regression or just parallel-build (-j8) header-ordering flakiness in this doc build; moot now given the revert, but worth a look if the same errors reappear on an unrelated future rebuild of this package.

2026-09-10: found and removed a duplicate arch/maintained/qt5-examples submodule

While looking at the struct_mutex.h AUR comment above, noticed OVERVIEW.md also listing a separate maintained/qt5-examples directory showing 🟠 CHANGED against this package’s now-current 5.15.19-3. Turned out to be a duplicate submodule of this exact repo – same AUR remote (aur.archlinux.org/qt5-doc(.git), same pkgbase=qt5-doc/pkgname=(qt5-doc qt5-examples)), just checked out under a second .gitmodules entry and frozen 3 commits behind (at 1fd84a1, missing the CDN-workaround/hardening/revert commits above). No memory note, no FEEDBACK.txt history, never separately built/published (couldn’t be – same pkgnames as this directory, would’ve just collided in the repo). User confirmed it was dead cruft and approved removal. Removed via git submodule deinit -f + git rm on maintained/qt5-examples (staged, not committed – left for the user to commit).