LCORE-1108: Updated Konflux dependencies #1090
Conversation
WalkthroughThe pull request updates multiple dependency versions across the project and applies formatting adjustments to Tekton CI YAML files. Dependency versions are bumped for packages including pdm-backend, poetry-core, cachetools, litellm, llama-stack-api, protobuf, psutil, rich, tqdm, wcwidth, and pyjwt with corresponding hash file updates. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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: 1
🤖 Fix all issues with AI agents
In `@requirements.hashes.source.txt`:
- Around line 20-22: The requirements file pins a non-existent package version
"cachetools==7.0.0" which will break installs; update the entry for cachetools
(the line containing "cachetools==7.0.0") to a valid 6.x release such as
"cachetools==6.2.6", replace the accompanying --hash values with the correct
SHA256 hashes for that exact wheel/sdist (or remove hashes temporarily if you
cannot regenerate them), and scan the rest of requirements.hashes.source.txt to
ensure all other package versions are real on PyPI and their hashes match the
chosen artifacts.
| cachetools==7.0.0 \ | ||
| --hash=sha256:a9abf18ff3b86c7d05b27ead412e235e16ae045925e531fae38d5fada5ed5b08 \ | ||
| --hash=sha256:d52fef60e6e964a1969cfb61ccf6242a801b432790fe520d78720d757c81cbd2 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
git ls-files | head -20Repository: lightspeed-core/lightspeed-stack
Length of output: 782
🏁 Script executed:
find . -maxdepth 2 -name "requirements*.txt" -o -name "pyproject.toml" -o -name "setup.py" | head -20Repository: lightspeed-core/lightspeed-stack
Length of output: 239
🏁 Script executed:
wc -l requirements.hashes.source.txt 2>/dev/null || echo "File not found, searching for it..."
fd -n "requirements.*" . --type fRepository: lightspeed-core/lightspeed-stack
Length of output: 358
🏁 Script executed:
# Read the specific lines mentioned in the review comment from requirements.hashes.source.txt
sed -n '20,22p; 196,198p; 202,204p; 483,493p; 494,515p; 561,563p; 702,704p; 717,719p; 766,768p' requirements.hashes.source.txtRepository: lightspeed-core/lightspeed-stack
Length of output: 4043
🏁 Script executed:
# Also check the beginning to see the file structure
head -30 requirements.hashes.source.txtRepository: lightspeed-core/lightspeed-stack
Length of output: 1919
🏁 Script executed:
# Read pyproject.toml to check dependencies as per the learning
cat pyproject.tomlRepository: lightspeed-core/lightspeed-stack
Length of output: 6008
🏁 Script executed:
#!/bin/bash
# Verify package versions on PyPI
packages=(
"cachetools==7.0.0"
"litellm==1.81.6"
"llama-stack-api==0.4.4"
"protobuf==6.33.5"
"psutil==7.2.2"
"rich==14.3.2"
"tqdm==4.67.2"
"wcwidth==0.5.3"
"pyjwt==2.11.0"
)
echo "=== Verifying PyPI versions ==="
for pkg in "${packages[@]}"; do
name="${pkg%==*}"
version="${pkg#*==}"
echo "Checking $name $version..."
# Use curl to check PyPI JSON API
response=$(curl -s "https://pypi.org/pypi/$name/$version/json" 2>/dev/null)
if echo "$response" | grep -q "\"version\": \"$version\"" 2>/dev/null; then
echo "✓ FOUND: $name $version"
else
# Try alternative check
if echo "$response" | grep -q "\"name\": \"$name\"" 2>/dev/null; then
echo "✓ FOUND: $name $version"
else
echo "✗ NOT FOUND: $name $version"
fi
fi
doneRepository: lightspeed-core/lightspeed-stack
Length of output: 600
🌐 Web query:
security vulnerabilities cachetools 7.0.0 CVE
💡 Result:
- There is no “cachetools 7.0.0” release for the PyPI package
cachetools(the project’s current releases are in the 6.x line; PyPI shows recent 6.2.x releases, e.g., 6.2.6). [1] - No CVEs / direct vulnerabilities are currently associated with
cachetoolsin major vulnerability trackers (e.g., Safety DB and Snyk both report no known security issues forcachetools). [2] [3]
If you meant CacheToolsUtils (a different PyPI project that does have a 7.0 series), say so and I’ll check CVEs/advisories for that package/version specifically. [4]
Sources: [1] [2] [3] [4]
🌐 Web query:
security vulnerabilities litellm 1.81.6 CVE
💡 Result:
No public CVE records I found list LiteLLM 1.81.6 as affected. The published LiteLLM CVEs (so far) are scoped to older versions (either specific versions or “before” / “up to” ranges) that are well below 1.81.6, e.g.:
- CVE-2024-5225 (SQL injection): affected up to (including) 1.40.2. [1]
- CVE-2024-2952 (SSTI): affected up to (excluding) 1.34.42. [2]
- CVE-2024-4888 (arbitrary file deletion): affected up to (excluding) 1.35.19. [3]
- CVE-2024-9606 (API key leakage in logs): affects LiteLLM before 1.44.12. [4]
- CVE-2025-0628 (improper authorization / privilege escalation): affects all versions before 1.61.15 (fixed in 1.61.15). [5]
- CVE-2025-11203 (health endpoint API_KEY disclosure): vendor advisory indicates it’s fixed in 1.63.14. [6]
- Additional CVEs tied to specific older versions: 1.27.14 (CVE-2024-4890), 1.34.34 (CVE-2024-5710), 1.38.10 (CVE-2024-6587), 1.52.1 (CVE-2025-0330). [7]
If you want, paste your deployment mode (Python library vs proxy server) and enabled endpoints, and I can map which of the above are relevant attack-surface-wise even if your version is newer.
Sources: [1] [2] [3] [4] [5] [6] [7]
🌐 Web query:
security vulnerabilities protobuf 6.33.5 CVE
💡 Result:
protobuf 6.33.5 (PyPI) is primarily relevant because it fixes the most recent protobuf Python CVE:
- CVE-2026-0994 (DoS via recursion depth bypass in
google.protobuf.json_format.ParseDict()with nestedAny)
Affects protobuf ≤ 6.33.4; upgrading to 6.33.5 removes exposure. The CVE description is in NVD. [1][2][3]
Other notable recent protobuf-python CVE (already fixed well before 6.33.5):
- CVE-2025-4565 (DoS via unbounded recursion in the pure-Python backend when parsing crafted protobuf data)
Patched in 6.31.1 (and also 4.25.8 / 5.29.5), so 6.33.5 is not affected. [4]
As of the sources above, there are no additional CVEs specifically reported as affecting protobuf 6.33.5 (it appears as a “fixed/upgrade-to” version for the active recursion-related issue). [2][3]
Sources
[1] NVD – CVE-2026-0994: https://nvd.nist.gov/vuln/detail/CVE-2026-0994
[2] Snyk (protobuf PyPI vuln page showing fix version): https://security.snyk.io/package/pip/protobuf/5.29.0
[3] Resolved Security (affected ≤6.33.4): https://www.resolvedsecurity.com/vulnerability-catalog/CVE-2026-0994
[4] GitHub Security Advisory (GHSA-8qvm-5x2c-j2w7 / CVE-2025-4565): GHSA-8qvm-5x2c-j2w7
🌐 Web query:
security vulnerabilities psutil 7.2.2 CVE
💡 Result:
As of Feb 2, 2026, there are no publicly listed CVEs known to affect psutil 7.2.2.
psutil7.2.2 was uploaded to PyPI on Jan 28, 2026. [1]- Snyk reports “NO KNOWN SECURITY ISSUES” for the latest versions and notes that while
psutilhas historical vulnerabilities, they do not affect 7.2.2. [2] - The main widely referenced CVE for psutil is CVE-2019-18874 (double free due to refcount mishandling), which affects psutil through 5.6.5—so it does not apply to 7.2.2. [3]
Sources: [1] PyPI release files for psutil 7.2.2, [2] Snyk psutil package page, [3] NVD entry for CVE-2019-18874.
🌐 Web query:
security vulnerabilities pyjwt 2.11.0 CVE
💡 Result:
As of February 2, 2026, I can’t find any CVE that lists PyJWT 2.11.0 as an affected version. The public CVEs associated with PyJWT in recent years are tied to earlier versions:
- CVE-2024-53861 – Issuer (
iss) validation partial-match bug; affected: 2.10.0 only, fixed: 2.10.1. PyJWT 2.11.0 is not affected. [1] - CVE-2022-29217 – Algorithm confusion / risky algorithm usage when apps accept “all default algorithms”; patch recommended: upgrade to 2.4.0 and explicitly restrict allowed algorithms when decoding. PyJWT 2.11.0 is not affected (it is far newer than the fixed version guidance). [2]
- CVE-2025-45768 – Reported as “weak encryption” in 2.10.1, but the record is explicitly disputed (supplier notes the key length is chosen by the application). It is not clearly established as a library vulnerability affecting later versions, and NVD’s affected configuration shown is 2.10.1. PyJWT 2.11.0 is not listed as affected. [3][4]
Bottom line: No CVE I found currently implicates PyJWT 2.11.0; the main actionable items are “don’t use 2.10.0” (due to CVE-2024-53861) and ensure your application explicitly restricts accepted algorithms when decoding tokens (the core risk described in CVE-2022-29217). [1][2]
Sources: NVD CVE entries and distro trackers. [1][2][3][4]
🏁 Script executed:
# Check if there's a typo and what the actual latest cachetools version is
curl -s "https://pypi.org/pypi/cachetools/json" | grep -o '"version": "[^"]*"' | head -5Repository: lightspeed-core/lightspeed-stack
Length of output: 58
🌐 Web query:
cachetools latest version PyPI 2026
💡 Result:
The latest cachetools release on PyPI is 6.2.6, uploaded January 27, 2026. [1]
Critical: cachetools==7.0.0 does not exist on PyPI.
The version specified in the requirements file is invalid. The latest cachetools release is 6.2.6 (released January 27, 2026). Version 7.0.0 does not exist in any release on PyPI. This will cause installation failures.
Update the cachetools entry to use a valid version from the 6.x series (e.g., 6.2.6 or 6.2.0). Review all dependencies in the file to ensure they reference actual released versions on PyPI.
The other dependency versions checked (litellm 1.81.6, protobuf 6.33.5, psutil 7.2.2, pyjwt 2.11.0, and others) show no known security advisories.
🤖 Prompt for AI Agents
In `@requirements.hashes.source.txt` around lines 20 - 22, The requirements file
pins a non-existent package version "cachetools==7.0.0" which will break
installs; update the entry for cachetools (the line containing
"cachetools==7.0.0") to a valid 6.x release such as "cachetools==6.2.6", replace
the accompanying --hash values with the correct SHA256 hashes for that exact
wheel/sdist (or remove hashes temporarily if you cannot regenerate them), and
scan the rest of requirements.hashes.source.txt to ensure all other package
versions are real on PyPI and their hashes match the chosen artifacts.
1 participant
Description
LCORE-1108: Updated Konflux dependencies
Type of change
Tools used to create PR
Related Tickets & Documents
Summary by CodeRabbit