Update action macos#78
Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughUpdates macOS CI and build tooling: moves runner to macos-14, sets ARCH=arm64 in workflow steps, shifts macOS scripts to venv and Homebrew-based installs, bumps macOS deployment target to 11.0, adjusts libusb/libsecp256k1 handling, and alters DMG naming and packaging steps. Changes
Sequence Diagram(s)sequenceDiagram
actor GH as "GitHub Actions"
participant Runner as "macos-14 runner"
participant Install as "install-osx.sh"
participant Script as "script-osx.sh"
participant Artifacts as "dist / DMG"
GH->>Runner: start build_release job (env ARCH=arm64)
Runner->>Install: run installer (Homebrew, libusb build, libsecp256k1)
Install-->>Runner: provide dylibs and deps
Runner->>Script: run build script (venv, pip install, build)
Script-->>Artifacts: produce DMG and dist artifacts
Artifacts-->>GH: upload artifacts
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/build_release.yml (1)
102-117: Upload path no longer matches DMG output name.
Line 117 still expects-macosx.dmg, butscript-osx.shnow writesdist/Firo-Electrum-$DASH_ELECTRUM_VERSION(no-macosx.dmg). This will result in a missing artifact.🛠️ Proposed fix (align to new output name)
- dist/Firo-Electrum-${{ steps.set_vars.outputs.pkg_ver }}-macosx.dmg + dist/Firo-Electrum-${{ steps.set_vars.outputs.pkg_ver }}
🤖 Fix all issues with AI agents
In @.github/workflows/build_release.yml:
- Around line 107-109: The echo of DASH_ELECTRUM_VERSION is vulnerable to
word-splitting; change the unquoted echo $DASH_ELECTRUM_VERSION to use quotes
(echo "$DASH_ELECTRUM_VERSION") so the output is preserved as a single token and
ShellCheck SC2086 is satisfied—keep the existing echo "ARCH=$ARCH" as-is.
In `@contrib/dash/actions/install-osx.sh`:
- Around line 13-16: The script currently untars the downloaded libusb archive
before verifying its checksum; change the order in the install flow so
verification happens immediately after download and before extraction: after
writing ${LIBUSB_FILE}.sha256 and running curl -O -L
${LIBUSB_URI}/v${LIBUSB_VER}/${LIBUSB_FILE}, run the checksum verification
(shasum -a256 -s -c ${LIBUSB_FILE}.sha256) and only if it succeeds proceed to
extract (tar -xjf ${LIBUSB_FILE}); update the sequence around the commands
referencing LIBUSB_FILE, LIBUSB_URI, LIBUSB_VER and the shasum check so
extraction is performed after a successful checksum validation.
- Around line 24-25: The current install step runs "brew install libsecp256k1"
then copies the poured dylib, which can produce bottles targeting newer macOS
and break macOS 11.0; change the installation to force a source build by setting
HOMEBREW_BUILD_FROM_SOURCE=1 when invoking the secp256k1 install (or replace the
Homebrew step with an explicit source build that sets
MACOSX_DEPLOYMENT_TARGET=11.0 and a controlled --prefix), and remove reliance on
copying the poured dylib via the "cp /opt/homebrew/lib/libsecp256k1*.dylib . ||
true" fallback so the artifacts are built with the correct deployment target.
In `@contrib/dash/actions/script-osx.sh`:
- Line 22: Update the PATH export in contrib/dash/actions/script-osx.sh so arm64
Homebrew's gettext binaries are found: modify the export PATH line (the PATH
export symbol) to include /opt/homebrew/opt/gettext/bin in addition to the
existing /usr/local/opt/gettext/bin (and keep /opt/homebrew/bin) so msgfmt and
other gettext tools are available on Apple Silicon when running
./contrib/make_locale.
♻️ Duplicate comments (1)
contrib/dash/actions/script-osx.sh (1)
36-38: Keep DMG output name aligned with workflow upload.
This output path drops-macosx.dmg; ensure the workflow upload path stays in sync.
| # For troubleshooting | ||
| echo $DASH_ELECTRUM_VERSION | ||
| echo "ARCH=$ARCH" |
There was a problem hiding this comment.
Quote the version echo to avoid word-splitting.
Shellcheck SC2086 applies here.
🔧 Proposed fix
- echo $DASH_ELECTRUM_VERSION
+ echo "$DASH_ELECTRUM_VERSION"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # For troubleshooting | |
| echo $DASH_ELECTRUM_VERSION | |
| echo "ARCH=$ARCH" | |
| # For troubleshooting | |
| echo "$DASH_ELECTRUM_VERSION" | |
| echo "ARCH=$ARCH" |
🤖 Prompt for AI Agents
In @.github/workflows/build_release.yml around lines 107 - 109, The echo of
DASH_ELECTRUM_VERSION is vulnerable to word-splitting; change the unquoted echo
$DASH_ELECTRUM_VERSION to use quotes (echo "$DASH_ELECTRUM_VERSION") so the
output is preserved as a single token and ShellCheck SC2086 is satisfied—keep
the existing echo "ARCH=$ARCH" as-is.
| echo "${LIBUSB_SHA} ${LIBUSB_FILE}" > ${LIBUSB_FILE}.sha256 | ||
| curl -O -L ${LIBUSB_URI}/v${LIBUSB_VER}/${LIBUSB_FILE} | ||
| tar -xzvf ${LIBUSB_FILE} | ||
| tar -xjf ${LIBUSB_FILE} | ||
| shasum -a256 -s -c ${LIBUSB_FILE}.sha256 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
git ls-files | grep -E "install-osx|dash" | head -20Repository: firoorg/electrum-firo
Length of output: 805
🏁 Script executed:
cat -n contrib/dash/actions/install-osx.sh | head -30Repository: firoorg/electrum-firo
Length of output: 1238
Verify libusb checksum before extracting.
The current code extracts the archive (line 15) before verifying its SHA-256 checksum (line 16), exposing the system to potential extraction of malicious or corrupted files. Reorder to verify the checksum immediately after download, before extraction.
Proposed fix
curl -O -L ${LIBUSB_URI}/v${LIBUSB_VER}/${LIBUSB_FILE}
+shasum -a256 -s -c ${LIBUSB_FILE}.sha256
-tar -xjf ${LIBUSB_FILE}
-shasum -a256 -s -c ${LIBUSB_FILE}.sha256
+tar -xjf ${LIBUSB_FILE}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| echo "${LIBUSB_SHA} ${LIBUSB_FILE}" > ${LIBUSB_FILE}.sha256 | |
| curl -O -L ${LIBUSB_URI}/v${LIBUSB_VER}/${LIBUSB_FILE} | |
| tar -xzvf ${LIBUSB_FILE} | |
| tar -xjf ${LIBUSB_FILE} | |
| shasum -a256 -s -c ${LIBUSB_FILE}.sha256 | |
| echo "${LIBUSB_SHA} ${LIBUSB_FILE}" > ${LIBUSB_FILE}.sha256 | |
| curl -O -L ${LIBUSB_URI}/v${LIBUSB_VER}/${LIBUSB_FILE} | |
| shasum -a256 -s -c ${LIBUSB_FILE}.sha256 | |
| tar -xjf ${LIBUSB_FILE} |
🤖 Prompt for AI Agents
In `@contrib/dash/actions/install-osx.sh` around lines 13 - 16, The script
currently untars the downloaded libusb archive before verifying its checksum;
change the order in the install flow so verification happens immediately after
download and before extraction: after writing ${LIBUSB_FILE}.sha256 and running
curl -O -L ${LIBUSB_URI}/v${LIBUSB_VER}/${LIBUSB_FILE}, run the checksum
verification (shasum -a256 -s -c ${LIBUSB_FILE}.sha256) and only if it succeeds
proceed to extract (tar -xjf ${LIBUSB_FILE}); update the sequence around the
commands referencing LIBUSB_FILE, LIBUSB_URI, LIBUSB_VER and the shasum check so
extraction is performed after a successful checksum validation.
| brew install libsecp256k1 | ||
| cp /opt/homebrew/lib/libsecp256k1*.dylib . || true |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find contrib/dash -type f -name "*.sh" | head -20Repository: firoorg/electrum-firo
Length of output: 699
🏁 Script executed:
cat -n contrib/dash/actions/install-osx.sh | head -40Repository: firoorg/electrum-firo
Length of output: 1359
🏁 Script executed:
# Check what macOS versions are targeted in the repository
find . -type f \( -name "*.yml" -o -name "*.yaml" -o -name "*.md" \) | xargs rg "macos|osx" -i -l | head -20Repository: firoorg/electrum-firo
Length of output: 223
🏁 Script executed:
# Check if there are workflow files that might specify macOS versions
cat .github/workflows/build_release.yml | grep -i "macos\|osx" -A 2 -B 2Repository: firoorg/electrum-firo
Length of output: 991
🏁 Script executed:
# Look for any documentation about supported macOS versions
rg "macos.*1[01]|deploy.*target" -i docs/ README.mdRepository: firoorg/electrum-firo
Length of output: 114
🏁 Script executed:
# Check other install scripts for consistency
rg "brew install.*secp|libsecp256k1" -i contrib/Repository: firoorg/electrum-firo
Length of output: 2094
🏁 Script executed:
# Check the Homebrew formula for secp256k1 to understand its current status
web_search "Homebrew secp256k1 formula macOS bottle compatibility"Repository: firoorg/electrum-firo
Length of output: 115
🏁 Script executed:
# Look for any recent issues or discussions about macOS version compatibility in this repo
git log --oneline --all --grep="secp256k1\|macos\|deployment" -i | head -20Repository: firoorg/electrum-firo
Length of output: 1084
🏁 Script executed:
# Check if there's any documentation about the build process
find . -type f -name "*.md" | xargs rg "secp256k1|macos.*11|deployment.*target" -i -B 2 -A 2 | head -40Repository: firoorg/electrum-firo
Length of output: 47
🌐 Web query:
Homebrew secp256k1 formula macOS bottle compilation requirements
💡 Result:
On macOS, Homebrew will pour a prebuilt bottle for secp256k1 when one exists for your macOS/CPU (it currently provides bottles for multiple recent macOS releases on Apple Silicon and Intel). [1]
If Homebrew must compile secp256k1 from source (e.g., no bottle for your macOS version/arch, you pass --build-from-source, or you’re on an unsupported configuration), the formula’s build-time dependencies are: autoconf, automake, and libtool. Homebrew will install these automatically as needed. [1]
Separately, on macOS you generally need Apple’s Xcode Command Line Tools (CLT) available for building software (and some bottles may explicitly require CLT to be installed). [2] Homebrew also documents that bottles are built for the default Homebrew prefix/cellar, and relocation behavior depends on bottle metadata. [3]
How to check what you’ll get on your machine
brew info secp256k1(shows whether a bottle is available for your macOS and whether it will pour or build). [1]
Sources: [1] [2] [3]
🌐 Web query:
HOMEBREW_BUILD_FROM_SOURCE MACOSX_DEPLOYMENT_TARGET environment variables
💡 Result:
HOMEBREW_BUILD_FROM_SOURCE
- Setting
HOMEBREW_BUILD_FROM_SOURCE=1tells Homebrew to build from source instead of using bottles (prebuilt binaries). In Linuxbrew’s docs, it’s explicitly described as a way to “build all formulas from source”. [1]
Practical use:
export HOMEBREW_BUILD_FROM_SOURCE=1
brew install <formula>MACOSX_DEPLOYMENT_TARGET
MACOSX_DEPLOYMENT_TARGETis a standard Apple toolchain env var that sets the minimum macOS version your built binaries should run on.- For CMake specifically, if
MACOSX_DEPLOYMENT_TARGETis set, CMake uses it as the default forCMAKE_OSX_DEPLOYMENT_TARGET. [2][3]
Practical use (when building something yourself, or when a build system honors it):
export MACOSX_DEPLOYMENT_TARGET=12.0
brew install --build-from-source <formula>Important Homebrew interaction (why it sometimes “does nothing”)
- Homebrew’s build environment filters user environment variables to prevent “environment contamination”; variables intended to reliably reach formula builds generally need to follow Homebrew’s filtering rules (notably,
HOMEBREW_-prefixed vars are allowed through). [4] - Because
MACOSX_DEPLOYMENT_TARGETis notHOMEBREW_-prefixed, it may be removed/overridden depending on how the formula is built and which Homebrew environment is used, so results vary by formula. [4]
If you tell me the formula (and your macOS version + Intel/Apple Silicon), I can point out the most reliable knob for that specific build (e.g., a formula option/patch, env :std in a tap, or a CMake -DCMAKE_OSX_DEPLOYMENT_TARGET=...).
Sources: [1] [2] [3] [4]
🏁 Script executed:
# Check if there are any existing issues or PRs related to secp256k1 macOS compatibility
git log --all --oneline -S "secp256k1" | head -20Repository: firoorg/electrum-firo
Length of output: 151
🏁 Script executed:
# Search for any formula options or environment configuration
rg "secp256k1.*option|secp256k1.*flag" -iRepository: firoorg/electrum-firo
Length of output: 1293
🏁 Script executed:
# Check if there are any GitHub issues or recent commits addressing macOS compatibility
rg "bottle|compatibility|macos.*version|deployment" contrib/dash/actions/install-osx.sh -i -B 3 -A 3Repository: firoorg/electrum-firo
Length of output: 556
secp256k1 Homebrew bottles may be incompatible with macOS 11.0 deployment target.
When running on macos-14 (as in the GitHub Actions workflow), Homebrew may pour a prebuilt bottle built with a higher minimum macOS version than the intended 11.0 target. The copied dylib could then fail at runtime on macOS 11.0.
Use HOMEBREW_BUILD_FROM_SOURCE=1 to force compilation, though verify the secp256k1 formula respects the deployment target during build. Alternatively, consider building from source manually (as done with libusb and zbar) with explicit --prefix and MACOSX_DEPLOYMENT_TARGET=11.0.
🧰 Build from source option
-brew install secp256k1
+HOMEBREW_BUILD_FROM_SOURCE=1 brew install secp256k1📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| brew install libsecp256k1 | |
| cp /opt/homebrew/lib/libsecp256k1*.dylib . || true | |
| HOMEBREW_BUILD_FROM_SOURCE=1 brew install libsecp256k1 | |
| cp /opt/homebrew/lib/libsecp256k1*.dylib . || true |
🤖 Prompt for AI Agents
In `@contrib/dash/actions/install-osx.sh` around lines 24 - 25, The current
install step runs "brew install libsecp256k1" then copies the poured dylib,
which can produce bottles targeting newer macOS and break macOS 11.0; change the
installation to force a source build by setting HOMEBREW_BUILD_FROM_SOURCE=1
when invoking the secp256k1 install (or replace the Homebrew step with an
explicit source build that sets MACOSX_DEPLOYMENT_TARGET=11.0 and a controlled
--prefix), and remove reliance on copying the poured dylib via the "cp
/opt/homebrew/lib/libsecp256k1*.dylib . || true" fallback so the artifacts are
built with the correct deployment target.
| -r contrib/deterministic-build/requirements-build-mac.txt | ||
|
|
||
| export PATH="/usr/local/opt/gettext/bin:$PATH" | ||
| export PATH="/opt/homebrew/bin:/usr/local/opt/gettext/bin:$PATH" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the file to understand the context
cat -n contrib/dash/actions/script-osx.sh | head -30Repository: firoorg/electrum-firo
Length of output: 1285
🏁 Script executed:
# Let's also check if there are any other references to this PATH or gettext in the repo
rg "gettext" --type sh -B 2 -A 2Repository: firoorg/electrum-firo
Length of output: 1409
Add arm64 gettext bin to PATH.
On macOS with arm64 (Apple Silicon), Homebrew installs packages under /opt/homebrew, but the current PATH only includes the Intel Homebrew prefix /usr/local/opt/gettext/bin. For keg-only packages like gettext, binaries are located at /opt/homebrew/opt/gettext/bin on arm64, which is not in the current PATH. This causes msgfmt and other gettext utilities to be unavailable when running ./contrib/make_locale on arm64 Macs.
🛠️ Proposed fix
-export PATH="/opt/homebrew/bin:/usr/local/opt/gettext/bin:$PATH"
+export PATH="/opt/homebrew/bin:/opt/homebrew/opt/gettext/bin:/usr/local/opt/gettext/bin:$PATH"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export PATH="/opt/homebrew/bin:/usr/local/opt/gettext/bin:$PATH" | |
| export PATH="/opt/homebrew/bin:/opt/homebrew/opt/gettext/bin:/usr/local/opt/gettext/bin:$PATH" |
🤖 Prompt for AI Agents
In `@contrib/dash/actions/script-osx.sh` at line 22, Update the PATH export in
contrib/dash/actions/script-osx.sh so arm64 Homebrew's gettext binaries are
found: modify the export PATH line (the PATH export symbol) to include
/opt/homebrew/opt/gettext/bin in addition to the existing
/usr/local/opt/gettext/bin (and keep /opt/homebrew/bin) so msgfmt and other
gettext tools are available on Apple Silicon when running ./contrib/make_locale.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@contrib/deterministic-build/requirements.txt`:
- Line 1: Replace the vulnerable pinned dependency "aiohttp==3.7.4.post0" in the
requirements entry with a secure version specifier (e.g., "aiohttp>=3.13.3") to
remediate the listed CVEs; update the requirements line for the symbol
aiohttp==3.7.4.post0, run dependency installation and unit/integration tests,
and regenerate any lockfile or dependency manifests your repo uses to ensure the
updated aiohttp version is propagated.
- Line 7: Update the pinned build dependencies in
contrib/deterministic-build/requirements.txt to fixed, non-vulnerable versions:
replace certifi==2020.12.5 with certifi>=2023.7.22 and also update idna to
>=3.7, pip to >=23.3, protobuf to >=3.18.3, setuptools to >=78.1.1, and wheel to
>=0.38.1 (modify the package lines for idna, pip, protobuf, setuptools, wheel
accordingly); after changing the requirements, regenerate any lockfiles or build
artifacts your deterministic build uses and run the project's CI/tests to ensure
compatibility.
| Pygments==2.11.2 \ | ||
| --hash=sha256:4e426f72023d88d03b2fa258de560726ce890ff3b630f88c21cbb8b2503b8c6a\ | ||
| --hash=sha256:44238f1b60a76d78fc8ca0528ee429702aae011c265fe6a8dd8b63049ae41c65 | ||
| aiohttp==3.7.4.post0 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n contrib/deterministic-build/requirements.txt | head -10Repository: firoorg/electrum-firo
Length of output: 310
🌐 Web query:
aiohttp 3.7.4.post0 security vulnerabilities CVE
💡 Result:
aiohttp 3.7.4.post0 is affected by these CVE-listed issues (per NVD), and you should upgrade to at least the fixed version shown:
- CVE-2023-47641 (HTTP request smuggling / inconsistent CL+TE parsing) — fixed in 3.8.0 (so 3.7.4.post0 is vulnerable) [1]
- CVE-2023-49082 (request smuggling / CRLF injection via attacker-controlled HTTP method) — fixed in 3.9.0 (vulnerable) [2]
- CVE-2024-23829 (request smuggling-related parser issues + possible unhandled exception/resource consumption) — fixed in 3.9.2 (vulnerable) [3]
- CVE-2024-27306 (XSS on static directory index pages) — fixed in 3.9.4 (vulnerable) [4]
- CVE-2024-30251 (DoS: crafted multipart/form-data POST can infinite-loop server) — fixed in 3.9.4 (vulnerable) [5]
- CVE-2025-53643 (request smuggling in pure-Python HTTP parser: no trailer parsing; applies when C extensions aren’t used /
AIOHTTP_NO_EXTENSIONSenabled) — fixed in 3.12.14 (vulnerable in that configuration) [6] - CVE-2025-69227 (DoS infinite loop when Python optimizations
-O/PYTHONOPTIMIZE=1bypass asserts and app usesRequest.post()) — fixed in 3.13.3 (vulnerable in that configuration) [7] - CVE-2025-69229 (DoS: excessive blocking CPU when reading many chunks; especially if an endpoint uses
request.read()) — fixed in 3.13.3 (vulnerable) [8]
Notably, CVE-2021-21330 (open redirect) was fixed in 3.7.4, so 3.7.4.post0 is not affected by that one [9].
Practical recommendation: upgrade to the newest aiohttp available; at minimum, upgrading past 3.13.3 addresses all CVEs above (and 3.12.14+ is important if you might run without C extensions). [6] [7] [8]
Sources: NVD entries for CVE-2023-47641 [1], CVE-2023-49082 [2], CVE-2024-23829 [3], CVE-2024-27306 [4], CVE-2024-30251 [5], CVE-2025-53643 [6], CVE-2025-69227 [7], CVE-2025-69229 [8], CVE-2021-21330 [9].
🌐 Web query:
aiohttp latest stable version security
💡 Result:
- Latest stable aiohttp (pip): 3.13.3, released January 3, 2026. [1]
- Security status / recommendation: aiohttp’s 3.13.3 release notes state it “contains fixes for several vulnerabilities” and advises upgrading ASAP. [2]
- Examples of issues fixed by upgrading to 3.13.3:
- CVE-2025-69230 (logging storm / potential DoS via crafted
Cookieheader) affects 3.13.2 and below, fixed in 3.13.3. [3] - CVE-2025-69225 (parser allows non‑ASCII decimals in
Range; potential request-smuggling angle) affects 3.13.2 and below, fixed in 3.13.3. [4]
- CVE-2025-69230 (logging storm / potential DoS via crafted
- Older but important request-smuggling fix: CVE-2025-53643 affects aiohttp < 3.12.14 in the pure-Python parser case (no C extensions /
AIOHTTP_NO_EXTENSIONS), fixed in 3.12.14. [5][6]
Action: pip install -U aiohttp (should install 3.13.3 as of Jan 3, 2026). [1]
Sources: [1] PyPI (aiohttp) • [2] aiohttp changelog 3.13.3 • [3] Debian CVE tracker (CVE-2025-69230) • [4] Debian CVE tracker (CVE-2025-69225) • [5] NVD (CVE-2025-53643) • [6] GitHub Advisory DB (GHSA-9548-qrrj-x5pj / CVE-2025-53643)
Critical security vulnerabilities in aiohttp—upgrade required.
The pinned version aiohttp==3.7.4.post0 is affected by at least 8 CVEs, including HTTP request smuggling (CVE-2023-47641, CVE-2023-49082, CVE-2024-23829), XSS (CVE-2024-27306), denial-of-service attacks (CVE-2024-30251, CVE-2025-69227, CVE-2025-69229), and CRLF injection. These pose significant security risks. Upgrade to aiohttp>=3.13.3 immediately to address all known vulnerabilities.
🧰 Tools
🪛 OSV Scanner (2.3.2)
[HIGH] 1-1: aiohttp 3.7.4.post0: aiohttp.web.Application vulnerable to HTTP request smuggling via llhttp HTTP request parser
(PYSEC-2023-120)
[HIGH] 1-1: aiohttp 3.7.4.post0: undefined
(PYSEC-2023-246)
[HIGH] 1-1: aiohttp 3.7.4.post0: undefined
(PYSEC-2023-247)
[HIGH] 1-1: aiohttp 3.7.4.post0: undefined
(PYSEC-2023-250)
[HIGH] 1-1: aiohttp 3.7.4.post0: undefined
(PYSEC-2023-251)
[HIGH] 1-1: aiohttp 3.7.4.post0: undefined
(PYSEC-2024-24)
[HIGH] 1-1: aiohttp 3.7.4.post0: undefined
(PYSEC-2024-26)
[HIGH] 1-1: aiohttp 3.7.4.post0: aiohttp.web.Application vulnerable to HTTP request smuggling via llhttp HTTP request parser
[HIGH] 1-1: aiohttp 3.7.4.post0: AIOHTTP vulnerable to brute-force leak of internal static file path components
[HIGH] 1-1: aiohttp 3.7.4.post0: aiohttp is vulnerable to directory traversal
[HIGH] 1-1: aiohttp 3.7.4.post0: aiohttp vulnerable to Denial of Service when trying to parse malformed POST requests
[HIGH] 1-1: aiohttp 3.7.4.post0: AIOHTTP's unicode processing of header values could cause parsing discrepancies
[HIGH] 1-1: aiohttp 3.7.4.post0: AIOHTTP vulnerable to denial of service through large payloads
[HIGH] 1-1: aiohttp 3.7.4.post0: AIOHTTP's HTTP Parser auto_decompress feature is vulnerable to zip bomb
[HIGH] 1-1: aiohttp 3.7.4.post0: aiohttp Cross-site Scripting vulnerability on index pages for static file handling
[HIGH] 1-1: aiohttp 3.7.4.post0: aiohttp allows request smuggling due to incorrect parsing of chunk extensions
[HIGH] 1-1: aiohttp 3.7.4.post0: aiohttp's HTTP parser (the python one, not llhttp) still overly lenient about separators
[HIGH] 1-1: aiohttp 3.7.4.post0: AIOHTTP is vulnerable to HTTP Request/Response Smuggling through incorrect parsing of chunked trailer sections
[HIGH] 1-1: aiohttp 3.7.4.post0: AIOHTTP Vulnerable to Cookie Parser Warning Storm
[HIGH] 1-1: aiohttp 3.7.4.post0: AIOHTTP vulnerable to DoS through chunked messages
[HIGH] 1-1: aiohttp 3.7.4.post0: AIOHTTP has problems in HTTP parser (the python one, not llhttp)
[HIGH] 1-1: aiohttp 3.7.4.post0: AIOHTTP vulnerable to DoS when bypassing asserts
[HIGH] 1-1: aiohttp 3.7.4.post0: AIOHTTP has unicode match groups in regexes for ASCII protocol elements
[HIGH] 1-1: aiohttp 3.7.4.post0: aiohttp has vulnerable dependency that is vulnerable to request smuggling
[HIGH] 1-1: aiohttp 3.7.4.post0: aiohttp's ClientSession is vulnerable to CRLF injection via version
[HIGH] 1-1: aiohttp 3.7.4.post0: aiohttp's ClientSession is vulnerable to CRLF injection via method
[HIGH] 1-1: aiohttp 3.7.4.post0: Aiohttp has inconsistent interpretation of Content-Length vs. Transfer-Encoding differing in C and Python fallbacks
[HIGH] 1-1: certifi 2020.12.5: undefined
(PYSEC-2022-42986)
[HIGH] 1-1: certifi 2020.12.5: undefined
(PYSEC-2023-135)
[HIGH] 1-1: certifi 2020.12.5: Certifi removing TrustCor root certificate
[HIGH] 1-1: certifi 2020.12.5: Removal of e-Tugra root certificate
[HIGH] 1-1: idna 3.1: undefined
(PYSEC-2024-60)
[HIGH] 1-1: idna 3.1: Internationalized Domain Names in Applications (IDNA) vulnerable to denial of service from specially crafted inputs to idna.encode
[HIGH] 1-1: pip 21.0.1: undefined
(PYSEC-2021-437)
[HIGH] 1-1: pip 21.0.1: undefined
(PYSEC-2023-228)
[HIGH] 1-1: pip 21.0.1: pip's fallback tar extraction doesn't check symbolic links point to extraction directory
[HIGH] 1-1: pip 21.0.1: Improper Input Validation in pip
[HIGH] 1-1: pip 21.0.1: Command Injection in pip when used with Mercurial
[HIGH] 1-1: protobuf 3.15.6: protobuf affected by a JSON recursion depth bypass
[HIGH] 1-1: protobuf 3.15.6: protobuf-cpp and protobuf-python have potential Denial of Service issue
[HIGH] 1-1: protobuf 3.15.6: protobuf-python has a potential Denial of Service issue
[HIGH] 1-1: setuptools 49.6.0: undefined
(PYSEC-2022-43012)
[HIGH] 1-1: setuptools 49.6.0: undefined
(PYSEC-2025-49)
[HIGH] 1-1: setuptools 49.6.0: setuptools has a path traversal vulnerability in PackageIndex.download that leads to Arbitrary File Write
[HIGH] 1-1: setuptools 49.6.0: setuptools vulnerable to Command Injection via package URL
[HIGH] 1-1: setuptools 49.6.0: pypa/setuptools vulnerable to Regular Expression Denial of Service (ReDoS)
[HIGH] 1-1: wheel 0.36.2: undefined
(PYSEC-2022-43017)
[HIGH] 1-1: wheel 0.36.2: pypa/wheel vulnerable to Regular Expression denial of service (ReDoS)
🤖 Prompt for AI Agents
In `@contrib/deterministic-build/requirements.txt` at line 1, Replace the
vulnerable pinned dependency "aiohttp==3.7.4.post0" in the requirements entry
with a secure version specifier (e.g., "aiohttp>=3.13.3") to remediate the
listed CVEs; update the requirements line for the symbol aiohttp==3.7.4.post0,
run dependency installation and unit/integration tests, and regenerate any
lockfile or dependency manifests your repo uses to ensure the updated aiohttp
version is propagated.
| async-timeout==3.0.1 | ||
| attrs==20.3.0 | ||
| bitstring==3.1.7 | ||
| certifi==2020.12.5 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n contrib/deterministic-build/requirements.txtRepository: firoorg/electrum-firo
Length of output: 726
🌐 Web query:
certifi 2020.12.5 CVE vulnerabilities security
💡 Result:
For certifi==2020.12.5, the main security items to be aware of are CVEs that represent root CA distrust / removal events (not a typical “remote code execution” bug, but “your trust store still includes roots that were later removed due to CA concerns”).
CVEs that affect certifi 2020.12.5
-
CVE-2022-23491 (TrustCor roots still trusted)
Certifi versions prior to 2022.12.07 included TrustCor roots that were later removed from certifi/Mozilla trust stores due to investigation concerns. Since 2020.12.5 < 2022.12.7, it’s affected. [1] -
CVE-2023-37920 (e-Tugra roots still trusted)
Certifi versions prior to 2023.07.22 included e-Tugra roots that were later removed following an investigation prompted by reported security issues. Since 2020.12.5 < 2023.7.22, it’s affected. [2]
CVEs that do not include certifi 2020.12.5 in their affected range (per advisory)
- CVE-2024-39689 (GLOBALTRUST root removal) is listed as affecting certifi >= 2021.5.30 and < 2024.7.4, so 2020.12.5 is not in the stated affected range. [3]
What to do
Upgrade certifi to at least:
- 2022.12.7 (addresses CVE-2022-23491), and ideally
- 2023.7.22 or newer (addresses CVE-2023-37920). [4]
Sources: NVD for CVE-2022-23491 [1], NVD for CVE-2023-37920 [2], GitHub Advisory for CVE-2024-39689 [3], Snyk version guidance for certifi 2020.12.5 [4].
🌐 Web query:
idna 3.1 CVE vulnerabilities DoS
💡 Result:
For the Python idna (kjd/idna) library, the main publicly tracked DoS issue is:
- CVE-2024-3651 — Denial of Service via CPU/resource consumption from quadratic-time behavior in
idna.encode()when given specially crafted input. Reported affecting idna 3.6 and fixed in idna 3.7 (i.e., upgrade to ≥ 3.7). (nvd.nist.gov)
Mitigations
- Upgrade
idnato 3.7+ (preferred). (seal.security) - If you must harden without upgrading: reject/limit overly long domain strings (DNS max 253 chars) before calling
idna.encode(). (seal.security)
Related but separate (often confused with idna the package):
- CVE-2022-45061 — DoS in CPython’s IDNA decoder (stdlib) in versions prior to patched Python releases (3.11.1 / 3.10.9 / 3.9.16 / 3.8.16 / 3.7.16). (cvefeed.io)
If by “idna 3.1” you meant CVSS 3.1 (not the idna package version), CVE-2024-3651 is the relevant idna-package DoS entry. (nvd.nist.gov)
Citations:
- 1: https://nvd.nist.gov/vuln/detail/CVE-2024-3651?utm_source=openai
- 2: https://www.seal.security/cve/python-cve-2024-3651-60a1b?utm_source=openai
- 3: https://www.seal.security/cve/python-cve-2024-3651-60a1b?utm_source=openai
- 4: https://cvefeed.io/vuln/detail/CVE-2022-45061?utm_source=openai
- 5: https://nvd.nist.gov/vuln/detail/CVE-2024-3651?utm_source=openai
🌐 Web query:
pip 21.0.1 CVE vulnerabilities command injection
💡 Result:
pip 21.0.1 is affected by a command/option-injection–class issue when installing from Mercurial (hg) VCS URLs:
- CVE-2023-5752: When running
pip install hg+..., a crafted Mercurial “revision” can be interpreted as additionalhg cloneoptions (notably--config), letting an attacker influence thehgoperation and potentially what code gets installed. Affected: pip < 23.3 → so pip 21.0.1 is vulnerable. (security.snyk.io)
Fix: upgrade to pip 23.3+ (or later). (security.snyk.io)
Related (often confused with “injection” but not command injection):
- CVE-2021-3572: Incorrect handling of Unicode separators in git references could lead to installing a different revision than intended; fixed in pip 21.1 (so 21.0.1 is affected). (nvd.nist.gov)
Citations:
- 1: https://security.snyk.io/package/pip/pip/21.0.1?utm_source=openai
- 2: https://security.snyk.io/package/pip/pip/21.0.1?utm_source=openai
- 3: https://nvd.nist.gov/vuln/detail/CVE-2021-3572?utm_source=openai
🌐 Web query:
protobuf 3.15.6 CVE vulnerabilities
💡 Result:
protobuf 3.15.6 is affected by at least these CVEs (depends on which protobuf implementation you’re using):
- CVE-2021-22569 (protobuf-java) – DoS via maliciously crafted input causing excessive short‑lived objects/GC pauses. 3.15.6 is vulnerable (affected:
< 3.16.1). Fix: upgrade to 3.16.1+ (or newer fixed lines 3.18.2 / 3.19.2). [1][2] - CVE-2022-1941 (protobuf-cpp; also protobuf-python) – DoS / out‑of‑memory via MessageSet parsing of crafted messages. 3.15.6 (C++) is vulnerable (affected includes versions up to and including 3.16.1). Fix: upgrade to 3.18.3+ (or newer fixed lines 3.19.5 / 3.20.2 / 3.21.6). [3][4]
Sources:
[1] GHSA-wrvw-hg22-4m67
[2] https://www.openwall.com/lists/oss-security/2022/01/12/4
[3] https://nvd.nist.gov/vuln/detail/CVE-2022-1941
[4] GHSA-8gq9-2x98-w8hf
🌐 Web query:
setuptools 49.6.0 CVE vulnerabilities
💡 Result:
setuptools==49.6.0 (Aug 2020-era) is within the affected version ranges of at least these published CVEs:
- CVE-2022-40897 — Regular-expression DoS (ReDoS) in
package_index.py; affects setuptools < 65.5.1. Fix: upgrade to 65.5.1+. [1] - CVE-2024-6345 — Remote code execution in
package_indexdownload functions; affects setuptools ≤ 69.1.1. Fix: upgrade to 70.0+. [2] - CVE-2025-47273 — Path traversal leading to arbitrary file write (potential RCE depending on context) in
PackageIndex; affects setuptools < 78.1.1. Fix: upgrade to 78.1.1+. [3]
Practical guidance: if you must remediate across all three, upgrade to setuptools 78.1.1 or newer. [3]
Sources:
[1] https://nvd.nist.gov/vuln/detail/CVE-2022-40897
[2] https://nvd.nist.gov/vuln/detail/CVE-2024-6345
[3] https://nvd.nist.gov/vuln/detail/CVE-2025-47273
🌐 Web query:
wheel 0.36.2 CVE vulnerabilities ReDoS
💡 Result:
wheel==0.36.2 is vulnerable to a Regular Expression Denial of Service (ReDoS) issue tracked as CVE-2022-40898, because the CVE affects wheel 0.37.1 and earlier (so 0.36.2 is in the affected range). The issue is triggered by attacker-controlled input processed by wheel’s filename-validation regex (typically via the wheel CLI), which can cause excessive CPU usage (DoS). [1] [2] [3]
Fix: upgrade to wheel >= 0.38.1 (0.38.0 is commonly noted as yanked for a non-security reason). [1] [2]
Update all build dependencies — multiple confirmed CVEs with remote code execution and denial of service.
The following packages contain publicly disclosed vulnerabilities:
- certifi 2020.12.5: CVE-2022-23491, CVE-2023-37920 (untrusted root CAs) → upgrade to ≥ 2023.7.22
- idna 3.1: CVE-2024-3651 (DoS via quadratic time complexity) → upgrade to ≥ 3.7
- pip 21.0.1: CVE-2021-3572 (git URL injection), CVE-2023-5752 (hg URL injection) → upgrade to ≥ 23.3
- protobuf 3.15.6: CVE-2021-22569, CVE-2022-1941 (DoS via crafted messages) → upgrade to ≥ 3.18.3
- setuptools 49.6.0: CVE-2022-40897 (ReDoS), CVE-2024-6345 (RCE in package download), CVE-2025-47273 (path traversal RCE) → upgrade to ≥ 78.1.1
- wheel 0.36.2: CVE-2022-40898 (ReDoS in filename validation) → upgrade to ≥ 0.38.1
These packages are from 2020–2021 and are 5+ years outdated. Deterministic builds should be compatible with these newer versions.
🤖 Prompt for AI Agents
In `@contrib/deterministic-build/requirements.txt` at line 7, Update the pinned
build dependencies in contrib/deterministic-build/requirements.txt to fixed,
non-vulnerable versions: replace certifi==2020.12.5 with certifi>=2023.7.22 and
also update idna to >=3.7, pip to >=23.3, protobuf to >=3.18.3, setuptools to
>=78.1.1, and wheel to >=0.38.1 (modify the package lines for idna, pip,
protobuf, setuptools, wheel accordingly); after changing the requirements,
regenerate any lockfiles or build artifacts your deterministic build uses and
run the project's CI/tests to ensure compatibility.
1 participant
No description provided.