release: 1.0.0-beta.8 (install hotfix: litellm-compatible Python)#1294
Conversation
…the venv) A fresh distro defaulting python3 to 3.14 aborted the install with 'No matching distribution found for litellm>=1.89.3' (litellm supports only >=3.10,<3.14). The installer now selects a 3.11-3.13 interpreter for the venv (installs python3.13 if absent, clear error pointing to uv otherwise), and requires-python is capped at <3.14. Patch promotion to master so the live installer works. beta.8 (beta.7.1 is not PEP 440 valid).
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
👋 Thanks for the PR! This one targets See CONTRIBUTING.md for the branch model. |
📝 WalkthroughWalkthroughVersion bumped to ChangesBeta 8: LiteLLM-compatible Python runtime selection
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
![gitar-bot[bot]](https://avatars.githubusercontent.com/in/827041?s=60&v=4){kind=small}
| log "creating venv with $PYBIN ($("$PYBIN" --version 2>&1))" | ||
| # Fedora's libtorrent binding is a system package; inherit site-packages so | ||
| # `import libtorrent` resolves against it. | ||
| if command -v pacman >/dev/null 2>&1 || [[ -f /etc/fedora-release ]]; then | ||
| python3 -m venv --system-site-packages .venv | ||
| "$PYBIN" -m venv --system-site-packages .venv | ||
| else | ||
| python3 -m venv .venv | ||
| "$PYBIN" -m venv .venv | ||
| fi |
There was a problem hiding this comment.
⚠️ Edge Case: venv on 3.13 can't see system libtorrent built for 3.14
On Fedora and Arch the libtorrent Python binding is installed as a system package built for the distro's default interpreter (python3 = 3.14 on a fresh 2026 distro), and the venv uses --system-site-packages specifically so import libtorrent resolves against it (see the dnf comment at lines 83-87 and the venv branch at 1055-1058). This hotfix now forces the venv to be built with PYBIN=python3.13 (pick_python prefers <3.14). A 3.13 venv with --system-site-packages inherits the 3.13 site-packages tree, not 3.14's, and a CPython C-extension such as libtorrent built against the 3.14 ABI cannot be imported under 3.13 anyway. The net effect is that the litellm fix likely re-breaks import libtorrent on Fedora/Arch — the very case the system-site-packages branch exists to handle. The comment at lines 1055-1056 ("inherit site-packages so import libtorrent resolves") is no longer accurate when PYBIN differs from the system python. Consider installing/building the libtorrent binding for the selected 3.13 interpreter (e.g. pip/system 3.13 binding), or documenting that torrent ingest is unavailable on these distros until a 3.13-compatible binding is present.
Document the interpreter-mismatch caveat; ideally also ensure a 3.13 libtorrent binding is available.:
# NOTE: --system-site-packages only helps when the venv interpreter matches
# the interpreter the system libtorrent binding was built for. On a distro
# whose default python3 is 3.14, a 3.13 venv will NOT see (or be able to
# load) the 3.14-built binding, so torrent ingest may be unavailable until
# a 3.13-compatible libtorrent binding is installed.
if command -v pacman >/dev/null 2>&1 || [[ -f /etc/fedora-release ]]; then
"$PYBIN" -m venv --system-site-packages .venv
else
"$PYBIN" -m venv .venv
fi
Was this helpful? React with 👍 / 👎
| elif command -v pacman >/dev/null 2>&1; then | ||
| sudo pacman -S --noconfirm python313 >/dev/null 2>&1 || true |
There was a problem hiding this comment.
💡 Bug: pacman fallback installs nonexistent 'python313' package
The auto-install fallback runs sudo pacman -S --noconfirm python313 on Arch. Arch's official repositories ship a single rolling python package (currently 3.14) and do not provide a versioned python313 package (older interpreters live in the AUR). This command will fail; because it is guarded by || true, the subsequent pick_python will still find nothing and the script dies with the manual-install message. The auto-install path is therefore effectively a no-op on Arch — acceptable as a graceful fallback, but the package name is misleading and could be replaced or removed to avoid implying Arch auto-install works.
Drop the bogus python313 pacman install and rely on the die() guidance.:
elif command -v pacman >/dev/null 2>&1; then
# Arch ships only the rolling `python`; no official versioned
# package exists, so we cannot auto-install 3.13 here. Fall through
# to the clear die() message (uv venv --python 3.13 or AUR).
:
fi
Was this helpful? React with 👍 / 👎
|
Note Your trial team has used its Gitar budget, so automatic reviews are paused. Upgrade now to unlock full capacity. Comment "Gitar review" to trigger a review manually. Code Review
|
| Compact |
|
Important
Your trial ends in 5 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more.
Was this helpful? React with 👍 / 👎 | Gitar
… + WSL audit) Strengthen the beta.8 venv-Python selection: provision a standalone 3.13 with uv when no system 3.11-3.13 is present (the fresh WSL/Ubuntu 26.04 case ships only 3.14 and may not package python3.13, so apt cannot help). Drop the bogus 'pacman -S python313' (gitar bug) and --system-site-packages (libtorrent optional now; a 3.13 venv cannot import a 3.14 system binding -- gitar Fedora/Arch edge case). Clean venv; clear error if uv is also unavailable.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/install-server.sh`:
- Around line 1053-1063: The current code at line 1053 only checks if the
`.venv` directory exists but does not validate whether the Python interpreter
inside it is compatible (3.11-3.13). If a prior run left an incompatible `.venv`
with Python 3.14, the condition will skip the entire bootstrap block and
subsequent litellm installations will fail. Add validation logic to check if an
existing `.venv` contains a compatible Python version by extracting and testing
the version of the Python interpreter in the existing `.venv`. If the existing
`.venv` has an incompatible version, remove it before proceeding with the
bootstrap logic that calls pick_system_python or ensure_uv. This ensures that
incompatible virtual environments are replaced with compatible ones on reruns.
- Line 1048: The curl command on line 1048 pipes the remote installation script
directly to sh, creating a security vulnerability. Refactor this to separate the
download, verification, and execution steps: first download the install script
to a temporary file using curl, then verify the integrity of the downloaded file
using checksums or signatures provided by the astral project, and finally
execute the verified script. This prevents arbitrary code execution from
tampering or man-in-the-middle attacks.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: fd532825-ba6a-44cd-b7b1-345d8da81394
⛔ Files ignored due to path filters (2)
desktop/package-lock.jsonis excluded by!**/package-lock.jsonuv.lockis excluded by!**/*.lock
📒 Files selected for processing (5)
CHANGELOG.mddesktop/package.jsonpyproject.tomlscripts/install-server.shtinyagentos/__init__.py
| command -v uv >/dev/null 2>&1 && return 0 | ||
| if [[ -x "$HOME/.local/bin/uv" ]]; then export PATH="$HOME/.local/bin:$PATH"; return 0; fi | ||
| log "installing uv to provision a supported Python" | ||
| curl -LsSf https://astral.sh/uv/install.sh | sh >/dev/null 2>&1 || return 1 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check if the file exists and examine the surrounding context
file="scripts/install-server.sh"
if [ -f "$file" ]; then
echo "=== File exists ==="
wc -l "$file"
echo "=== Lines 1040-1060 ==="
sed -n '1040,1060p' "$file"
else
echo "File not found at $file"
# Try to find it
find . -name "install-server.sh" 2>/dev/null
fiRepository: jaylfc/taOS
Length of output: 871
🌐 Web query:
curl pipe sh security risks arbitrary code execution
💡 Result:
The practice of piping the output of a remote command like curl or wget directly into a shell interpreter (e.g., | sh or | bash) is widely considered a significant security risk and a poor technical practice [1][2][3][4]. The primary dangers include arbitrary code execution and the bypass of critical security and integrity checks [2][4]. The core risks include: Arbitrary Code Execution: The command immediately executes code from a remote source with the privileges of the user running the shell [2][4]. If the command is run with sudo, it grants root-level access to the remote script, which can result in full system compromise [1][5]. Lack of Integrity Verification: This method bypasses the ability to inspect the script, verify a cryptographic signature (such as GPG), or check a checksum (like SHA-256) before execution [1][2]. You have no assurance that the content received matches what the publisher intended [1]. Transport and Supply Chain Attacks: Relying solely on HTTPS is insufficient [2]. Any compromise of the server, CDN, DNS, or network path (man-in-the-middle attack) can lead to the silent delivery of malicious payloads [6][2]. Failure Modes and Partial Execution: Bash does not necessarily wait for the entire script to download before beginning execution [4]. If the connection is severed mid-stream, the shell may execute a partial, truncated, or malformed script, which can lead to unpredictable behavior, such as unintended file deletions [3][7][4]. Detection of Transport Method: A malicious server can detect that a script is being piped into a shell (versus being saved to a file) by observing timing and TCP behavior, allowing it to serve a clean script to users who save the file but a malicious one to those who pipe it [1][8]. Best Practices: The recommended alternative is to separate the download, verification, and execution steps [2][7][5]: 1. Download: Fetch the script to a local file (e.g., curl -sSL https://example.com/install.sh -o install.sh) [2][4][8]. 2. Verify: Inspect the script content manually or use verification tools to check the file against a known-good checksum or GPG signature provided through a separate, trusted channel [2][4][5]. 3. Execute: Only after verifying the integrity of the downloaded file should you run it (e.g., bash./install.sh) [2][5][8]. If you must use automation, consider caching the script, pinning it to a specific versioned URL, or using a proper package manager that natively handles signatures and integrity validation [4][9].
Citations:
- 1: https://security.stackexchange.com/questions/213401/is-curl-something-sudo-bash-a-reasonably-safe-installation-method
- 2: https://docs.cli.vulnetix.com/docs/sast-rules/vnx-bash-002/
- 3: https://www.seancassidy.me/dont-pipe-to-your-shell.html
- 4: https://tferdinand.net/en/why-curl-bash-is-a-dangerous-bad-habit/
- 5: https://unix.stackexchange.com/questions/506468/what-is-the-best-next-step-when-faced-with-curl-url-sh
- 6: https://spin.atomicobject.com/security-spectrum-curl-sh/
- 7: https://lwn.net/Articles/890343/
- 8: https://stackoverflow.com/questions/56881266/how-the-alternatives-are-better-than-using-curl-sudo-sh
- 9: https://www.chef.io/blog/5-ways-to-deal-with-the-install-sh-curl-pipe-bash-problem
Avoid piping a remote script directly to sh.
Line 1048 executes network-fetched content immediately, which is an arbitrary-code-execution risk if that payload is tampered with. This pattern bypasses integrity verification, exposes the installation to supply-chain and man-in-the-middle attacks, and may execute partial content if the connection is interrupted mid-stream.
Separate the download, verification, and execution steps:
Recommended fix
- curl -LsSf https://astral.sh/uv/install.sh | sh >/dev/null 2>&1 || return 1
+ local uv_installer
+ uv_installer="$(mktemp)" || return 1
+ curl --proto '=https' --tlsv1.2 -LsSf --connect-timeout 15 --max-time 120 \
+ -o "$uv_installer" https://astral.sh/uv/install.sh || { rm -f "$uv_installer"; return 1; }
+ # Verify checksum/signature against a pinned trusted value before execution.
+ sh "$uv_installer" >/dev/null 2>&1 || { rm -f "$uv_installer"; return 1; }
+ rm -f "$uv_installer"📝 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.
| curl -LsSf https://astral.sh/uv/install.sh | sh >/dev/null 2>&1 || return 1 | |
| local uv_installer | |
| uv_installer="$(mktemp)" || return 1 | |
| curl --proto '=https' --tlsv1.2 -LsSf --connect-timeout 15 --max-time 120 \ | |
| -o "$uv_installer" https://astral.sh/uv/install.sh || { rm -f "$uv_installer"; return 1; } | |
| # Verify checksum/signature against a pinned trusted value before execution. | |
| sh "$uv_installer" >/dev/null 2>&1 || { rm -f "$uv_installer"; return 1; } | |
| rm -f "$uv_installer" |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@scripts/install-server.sh` at line 1048, The curl command on line 1048 pipes
the remote installation script directly to sh, creating a security
vulnerability. Refactor this to separate the download, verification, and
execution steps: first download the install script to a temporary file using
curl, then verify the integrity of the downloaded file using checksums or
signatures provided by the astral project, and finally execute the verified
script. This prevents arbitrary code execution from tampering or
man-in-the-middle attacks.
| if [[ ! -d .venv ]]; then | ||
| log "creating venv" | ||
| # On distros that ship Python 3.14+ (Arch) or where libtorrent's Python | ||
| # binding is only available as a system package (Fedora — see dnf branch | ||
| # above), we need the venv to inherit system site-packages so `import | ||
| # libtorrent` resolves against the OS-installed binding. PyPI does not | ||
| # publish libtorrent wheels for 3.14 yet. | ||
| if command -v pacman >/dev/null 2>&1 || [[ -f /etc/fedora-release ]]; then | ||
| python3 -m venv --system-site-packages .venv | ||
| PYBIN="$(pick_system_python || true)" | ||
| if [[ -n "$PYBIN" ]]; then | ||
| log "creating venv with $PYBIN ($("$PYBIN" --version 2>&1))" | ||
| "$PYBIN" -m venv .venv | ||
| elif ensure_uv; then | ||
| log "no system Python 3.11-3.13; provisioning 3.13 with uv" | ||
| uv python install 3.13 >/dev/null 2>&1 || true | ||
| uv venv --seed --python 3.13 .venv || die "uv could not create a Python 3.13 venv" | ||
| else | ||
| python3 -m venv .venv | ||
| die "taOS needs Python 3.11-3.13 (litellm has no 3.14 build yet) and uv could not be installed to provision one. Install python3.13 (e.g. 'sudo apt install python3.13 python3.13-venv') and re-run." |
There was a problem hiding this comment.
Revalidate existing .venv interpreter before reusing it.
Line 1053 only bootstraps when .venv is missing. If a prior run left a 3.14 .venv, this hotfix is bypassed and litellm install can keep failing on reruns.
Suggested fix
+if [[ -d .venv ]]; then
+ VENV_PY=".venv/bin/python"
+ vv=0
+ if [[ -x "$VENV_PY" ]]; then
+ vv=$("$VENV_PY" -c 'import sys;print(sys.version_info[0]*100+sys.version_info[1])' 2>/dev/null || echo 0)
+ fi
+ if [[ "$vv" -lt 311 || "$vv" -ge 314 ]]; then
+ log "existing .venv uses unsupported Python; recreating"
+ rm -rf .venv
+ fi
+fi
if [[ ! -d .venv ]]; then📝 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.
| if [[ ! -d .venv ]]; then | |
| log "creating venv" | |
| # On distros that ship Python 3.14+ (Arch) or where libtorrent's Python | |
| # binding is only available as a system package (Fedora — see dnf branch | |
| # above), we need the venv to inherit system site-packages so `import | |
| # libtorrent` resolves against the OS-installed binding. PyPI does not | |
| # publish libtorrent wheels for 3.14 yet. | |
| if command -v pacman >/dev/null 2>&1 || [[ -f /etc/fedora-release ]]; then | |
| python3 -m venv --system-site-packages .venv | |
| PYBIN="$(pick_system_python || true)" | |
| if [[ -n "$PYBIN" ]]; then | |
| log "creating venv with $PYBIN ($("$PYBIN" --version 2>&1))" | |
| "$PYBIN" -m venv .venv | |
| elif ensure_uv; then | |
| log "no system Python 3.11-3.13; provisioning 3.13 with uv" | |
| uv python install 3.13 >/dev/null 2>&1 || true | |
| uv venv --seed --python 3.13 .venv || die "uv could not create a Python 3.13 venv" | |
| else | |
| python3 -m venv .venv | |
| die "taOS needs Python 3.11-3.13 (litellm has no 3.14 build yet) and uv could not be installed to provision one. Install python3.13 (e.g. 'sudo apt install python3.13 python3.13-venv') and re-run." | |
| if [[ -d .venv ]]; then | |
| VENV_PY=".venv/bin/python" | |
| vv=0 | |
| if [[ -x "$VENV_PY" ]]; then | |
| vv=$("$VENV_PY" -c 'import sys;print(sys.version_info[0]*100+sys.version_info[1])' 2>/dev/null || echo 0) | |
| fi | |
| if [[ "$vv" -lt 311 || "$vv" -ge 314 ]]; then | |
| log "existing .venv uses unsupported Python; recreating" | |
| rm -rf .venv | |
| fi | |
| fi | |
| if [[ ! -d .venv ]]; then | |
| PYBIN="$(pick_system_python || true)" | |
| if [[ -n "$PYBIN" ]]; then | |
| log "creating venv with $PYBIN ($("$PYBIN" --version 2>&1))" | |
| "$PYBIN" -m venv .venv | |
| elif ensure_uv; then | |
| log "no system Python 3.11-3.13; provisioning 3.13 with uv" | |
| uv python install 3.13 >/dev/null 2>&1 || true | |
| uv venv --seed --python 3.13 .venv || die "uv could not create a Python 3.13 venv" | |
| else | |
| die "taOS needs Python 3.11-3.13 (litellm has no 3.14 build yet) and uv could not be installed to provision one. Install python3.13 (e.g. 'sudo apt install python3.13 python3.13-venv') and re-run." | |
| fi |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@scripts/install-server.sh` around lines 1053 - 1063, The current code at line
1053 only checks if the `.venv` directory exists but does not validate whether
the Python interpreter inside it is compatible (3.11-3.13). If a prior run left
an incompatible `.venv` with Python 3.14, the condition will skip the entire
bootstrap block and subsequent litellm installations will fail. Add validation
logic to check if an existing `.venv` contains a compatible Python version by
extracting and testing the version of the Python interpreter in the existing
`.venv`. If the existing `.venv` has an incompatible version, remove it before
proceeding with the bootstrap logic that calls pick_system_python or ensure_uv.
This ensures that incompatible virtual environments are replaced with compatible
ones on reruns.
1 participant
Second install hotfix promoted to master (the live installer clones the default branch). Surfaced after beta.7 let the WSL user's install get past libtorrent.
No matching distribution found for litellm>=1.89.3-- litellm 1.89.3 is the latest but caps atrequires_python <3.14, and a fresh 2026 distro defaults python3 to 3.14, so the venv was built on an unsupported interpreter.pick_python), installs python3.13 via the package manager if none is present, clear error pointing touv venv --python 3.13otherwise.requires-pythoncapped at>=3.11,<3.14to match litellm.Once green: merge + tag v1.0.0-beta.8 + GitHub release.
Summary by CodeRabbit
Bug Fixes
Chores