Fixed analysis when gather-extra fails in post phase#117
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis PR refactors BugZooka to use a shared inference library ( ChangesInference Library Refactoring and Async Migration
🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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: 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 `@requirements.txt`:
- Around line 46-47: Update the vulnerable dependency line
"cryptography>=44.0.0" in requirements.txt to a safe minimum version (e.g.,
"cryptography>=44.0.1") so resolution cannot pick the affected 44.0.0 release;
after updating the constraint, regenerate any lockfile or dependency freeze (if
present) so CI uses the new minimum.
- Around line 18-19: The requirements entry "py-commons>=0.3.0" is not
resolvable from the public PyPI index and is blocking installs; either replace
that entry with the correct published package name and version (e.g., the actual
package you intended) or add the custom index/extra-index-url that hosts
"py-commons" so pip can find it; also tighten the cryptography bound by changing
"cryptography>=44.0.0" to "cryptography>=44.0.1" so the vulnerable 44.0.0 wheel
is excluded. Ensure you update the requirements.txt entries for "py-commons" and
"cryptography" accordingly.
🪄 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: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: 65780694-3b2c-45dc-b715-8e573dfe0d68
📒 Files selected for processing (9)
CONTRIBUTING.mdREADME.mdbugzooka/analysis/log_analyzer.pybugzooka/analysis/prow_analyzer.pybugzooka/core/config.pybugzooka/core/constants.pybugzooka/integrations/inference_client.pybugzooka/integrations/slack_socket_listener.pyrequirements.txt
| # py-commons | ||
| py-commons>=0.3.0 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate and print requirements.txt with line numbers around the referenced lines.
if [ -f requirements.txt ]; then
echo "== requirements.txt =="
nl -ba requirements.txt | sed -n '1,120p'
else
echo "requirements.txt not found at repo root" >&2
exit 1
fiRepository: redhat-performance/BugZooka
Length of output: 155
🏁 Script executed:
#!/bin/bash
set -euo pipefail
if [ -f requirements.txt ]; then
echo "== requirements.txt =="
cat -n requirements.txt | sed -n '1,120p'
else
echo "requirements.txt not found at repo root" >&2
exit 1
fiRepository: redhat-performance/BugZooka
Length of output: 1275
🌐 Web query:
py-commons 0.3.0 PyPI
💡 Result:
As of June 12, 2026, there is no widely recognized or active package on the Python Package Index (PyPI) named exactly py-commons that corresponds to a version 0.3.0. The search results identify several distinct projects with similar names, none of which appear to have a version 0.3.0 in active circulation: 1. pycommons (without the hyphen): This is an active utility library maintained by Thomas Weise, currently on versions in the 0.8.x range (e.g., 0.8.98) [1][2][3]. 2. py-commons (Vaastav-Technologies): A GitHub repository that provides reusable utilities [4]. Its latest release is listed as v0.0.1dev3 [4]. 3. py-commons (piwheels): An older, separate package for data analysis utilities, with documented versions 0.1.0 and 0.1.2 released in 2016 [5]. If you are looking for a specific library, ensure you have the correct name, as the hyphenated py-commons and the non-hyphenated pycommons refer to different codebases [1][4][5].
Citations:
- 1: https://pypi.org/project/pycommons/
- 2: https://github.com/thomasWeise/pycommons/
- 3: https://pypi.org/project/pycommons/0.8.67/
- 4: https://github.com/Vaastav-Technologies/py-commons
- 5: https://www.piwheels.org/project/py-commons/
🌐 Web query:
cryptography 44.0.0 security advisory
💡 Result:
The cryptography library version 44.0.0 is affected by a security vulnerability related to the OpenSSL version bundled in its distributed wheels [1][2]. Vulnerability Details (CVE-2024-12797 / GHSA-79v4-65xg-pq4g): The wheels for cryptography version 44.0.0 include a statically linked copy of OpenSSL that contains a security vulnerability [1]. This issue affects versions 42.0.0 through 44.0.0 [1]. Remediation: The vulnerability was fixed in version 44.0.1 [1][3]. Users installing cryptography via wheels (e.g., from PyPI) are advised to upgrade to at least version 44.0.1 [1]. If you are building the library from the source distribution (sdist), you are responsible for managing and upgrading your own OpenSSL installation [1]. It is recommended to maintain the library at the latest stable release to ensure security patches and OpenSSL updates are applied [3][4]. As of June 2026, subsequent releases have addressed further vulnerabilities, such as those covered in later CVEs [5][6][7][8].
Citations:
- 1: GHSA-79v4-65xg-pq4g
- 2: https://www.ibm.com/support/pages/security-bulletin-there-vulnerability-cryptography-4400-cp39-abi3-manylinux228x8664whl-used-ibm-maximo-manage-application-ibm-maximo-application-suite-cve-2024-12797
- 3: https://pypi.python.org/project/cryptography/44.0.0/
- 4: https://cryptography.io/en/45.0.4/changelog/
- 5: GHSA-537c-gmf6-5ccf
- 6: GHSA-p423-j2cm-9vmq
- 7: GHSA-r6ph-v2qm-q3c2
- 8: GHSA-m959-cc7f-wv43
Fix broken dependency resolution and tighten cryptography security bounds
requirements.txtline 19 (py-commons>=0.3.0) is not resolvable from the default/public package index (no releasedpy-commons==0.3.0available), blockingpip install -r requirements.txt; use the correct package name/version or configure the intended index.requirements.txtline 47 (cryptography>=44.0.0) allows vulnerablecryptography==44.0.0wheels (GHSA-79v4-65xg-pq4g); raise the lower bound tocryptography>=44.0.1(or newer).
🤖 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 `@requirements.txt` around lines 18 - 19, The requirements entry
"py-commons>=0.3.0" is not resolvable from the public PyPI index and is blocking
installs; either replace that entry with the correct published package name and
version (e.g., the actual package you intended) or add the custom
index/extra-index-url that hosts "py-commons" so pip can find it; also tighten
the cryptography bound by changing "cryptography>=44.0.0" to
"cryptography>=44.0.1" so the vulnerable 44.0.0 wheel is excluded. Ensure you
update the requirements.txt entries for "py-commons" and "cryptography"
accordingly.
Source: Pipeline failures
| # Misc. | ||
| cryptography>=44.0.0 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
ls -la
if [ -f requirements.txt ]; then
echo "---- requirements.txt (tail/head around 40-60) ----"
nl -ba requirements.txt | sed -n '35,60p'
else
echo "requirements.txt not found at repo root"
find . -maxdepth 3 -name requirements.txt -print
fiRepository: redhat-performance/BugZooka
Length of output: 1728
🌐 Web query:
cryptography 44.0.0 security advisory CVE fixed version
💡 Result:
The cryptography library version 44.0.0 is affected by a security vulnerability related to the statically linked copy of OpenSSL included in its binary distributions (wheels) [1][2]. Security Advisory Details: - Vulnerability: Vulnerable OpenSSL included in cryptography wheels [1]. - CVE ID: CVE-2024-12797 [1][3]. - Affected Versions: >= 42.0.0 and <= 44.0.0 [1][2]. - Fixed Version: 44.0.1 or higher [1][2]. This vulnerability specifically impacts users installing pre-compiled wheels from PyPI [1][4]. Users who build the library from source (sdist) are responsible for managing their own OpenSSL version [1][2]. To mitigate this issue, users should upgrade to cryptography version 44.0.1 or later [1][2].
Citations:
- 1: GHSA-79v4-65xg-pq4g
- 2: https://vulert.com/vuln-db/CVE-2024-12797
- 3: https://pypi.org/project/cryptography/44.0.0/
- 4: https://www.versioneye.com/Python/cryptography/43.0.0
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "---- requirements.txt: lines 40-55 ----"
if [ -f requirements.txt ]; then
sed -n '40,55p' requirements.txt
else
echo "requirements.txt not found at repo root"
find . -maxdepth 4 -name requirements.txt -print
fiRepository: redhat-performance/BugZooka
Length of output: 211
🌐 Web query:
GHSA-79v4-65xg-pq4g cryptography fixed version 44.0.1
💡 Result:
GHSA-79v4-65xg-pq4g is a security advisory for the Python cryptography library related to the inclusion of a vulnerable, statically linked version of OpenSSL [1][2]. This vulnerability is tracked as CVE-2024-12797 [1][3]. The issue affects cryptography library versions 42.0.0 through 44.0.0 [1][4]. Version 44.0.1 was released to fix this vulnerability by updating the bundled OpenSSL version [1][2]. Key details: - Impact: The vulnerability involves a missing report of an error condition during TLS/DTLS handshakes when using Raw Public Keys (RPKs), which could allow an attacker to impersonate a server in a Man-in-the-Middle (MitM) attack [3]. - Affected Users: This primarily affects users installing cryptography from pre-built wheels distributed on PyPI, as these contain the statically linked OpenSSL [1][5]. - Mitigation: Users should upgrade to cryptography version 44.0.1 or higher [1][6]. If building from source (sdist), users are responsible for ensuring the linked OpenSSL version is secure [1][2].
Citations:
- 1: GHSA-79v4-65xg-pq4g
- 2: GHSA-79v4-65xg-pq4g
- 3: https://security.snyk.io/vuln/SNYK-PYTHON-CRYPTOGRAPHY-8715586
- 4: https://osv.dev/vulnerability/GHSA-79v4-65xg-pq4g
- 5: https://vulert.com/vuln-db/CVE-2024-12797
- 6: https://advisories.gitlab.com/pypi/cryptography/CVE-2024-12797/
Raise the cryptography minimum to avoid vulnerable 44.0.0
requirements.txt uses cryptography>=44.0.0, which still permits resolving to 44.0.0 affected by GHSA-79v4-65xg-pq4g / CVE-2024-12797; change the constraint to cryptography>=44.0.1 (or newer).
🧰 Tools
🪛 OSV Scanner (2.3.8)
[HIGH] 47-47: cryptography 44.0.0: undefined
(PYSEC-2026-35)
[HIGH] 47-47: cryptography 44.0.0: Vulnerable OpenSSL included in cryptography wheels
[HIGH] 47-47: cryptography 44.0.0: cryptography has incomplete DNS name constraint enforcement on peer names
[HIGH] 47-47: cryptography 44.0.0: cryptography Vulnerable to a Subgroup Attack Due to Missing Subgroup Validation for SECT Curves
🤖 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 `@requirements.txt` around lines 46 - 47, Update the vulnerable dependency line
"cryptography>=44.0.0" in requirements.txt to a safe minimum version (e.g.,
"cryptography>=44.0.1") so resolution cannot pick the affected 44.0.0 release;
after updating the constraint, regenerate any lockfile or dependency freeze (if
present) so CI uses the new minimum.
Source: Linters/SAST tools
|
Closed because it included all changes not relevant to this PR |
1 participant
Description
When
gather-extrafails in the post phase, it doesn't createclusteroperators.json. BugZooka would just return a generic error with no deeper analysis.Now, we first check if orion performance data exists. If not, we get relevant errors from build logs and then trigger LLM analysis of those errors.
Error link: https://prow.ci.openshift.org/view/gs/test-platform-results/logs/periodic-ci-openshift-eng-ocp-qe-perfscale-ci-main-aws-4.22-nightly-x86-payload-control-plane-6nodes/2064660673337495552