Repository navigation
Update zen-internals to v0.1.74 - #760
Conversation
| monkeypatch.setattr("platform.system", lambda: "Linux") | ||
| monkeypatch.setattr("platform.machine", lambda: "x86_64") | ||
| monkeypatch.setattr("sysconfig.get_config_var", lambda name: "x86_64-pc-linux-gnu") | ||
| monkeypatch.setattr("platform.libc_ver", lambda: ("", "")) |
There was a problem hiding this comment.
This is never called in code or?
There was a problem hiding this comment.
On purpose. The code used to use them and picked the wrong build.
| ) | ||
| return None | ||
| error = e | ||
| # A musl Python built without HOST_GNU_TYPE picks the glibc build, which musl |
There was a problem hiding this comment.
Do we have CI tests using alpine linux? If not, let's add?
There was a problem hiding this comment.
Right, adding now
| musl_path = os.path.join( | ||
| os.path.dirname(binary_path), | ||
| os.path.basename(binary_path).replace("-gnu.so", "-musl.so"), | ||
| ) |
There was a problem hiding this comment.
Building musl_path from the directory and basename needlessly decomposes and reassembles binary_path before replacing the suffix.
Show fix
| musl_path = os.path.join( | |
| os.path.dirname(binary_path), | |
| os.path.basename(binary_path).replace("-gnu.so", "-musl.so"), | |
| ) | |
| musl_path = binary_path.replace("-gnu.so", "-musl.so") |
Details
✨ AI Reasoning
The retry path is derived from binary_path. Splitting it into directory and basename and joining those parts again adds an unnecessary step without changing the resulting path.
Reply on this comment to give feedback or ignore the issue.
More info
There was a problem hiding this comment.
This would bring back an earlier bug: replace changes every -gnu.so in the path, including folder names, so a library in a folder like app-gnu.so/ would never get the musl retry. test_load_falls_back_to_the_musl_build_when_the_glibc_build_fails covers this and fails with the suggested line.
There was a problem hiding this comment.
⛔ You don't have permission to ignore issues.
| run: | | ||
| docker run --rm -v "$(pwd):/app" -w /app python:${{ matrix.python-version }}-alpine sh -eo pipefail -c " | ||
| apk add --no-cache build-base curl | ||
| curl -fsSL https://github.com/AikidoSec/safe-chain/releases/latest/download/install-safe-chain.sh | sh -s -- --ci | ||
| export PATH=\"\$HOME/.safe-chain/shims:\$HOME/.safe-chain/bin:\$PATH\" | ||
| pip install --root-user-action=ignore . pytest | ||
| python -m pytest aikido_zen/helpers/zen_internals_test.py | ||
| " |
There was a problem hiding this comment.
Binary, code or archive is pulled from a remote source without integrity verification - medium severity
A GitHub Actions Workflow was built using an artifact from a remote source without any integrity verification. If the remote artifact were silently replaced with a malicious version (for example, through a supply chain attack), the integrity and confidentiality of the environment in which the container is deployed could be compromised.
Show fix
Remediation: Validate the artifact against a trusted SHA-512 checksum in the CI/CD pipeline using sha512sum in check mode. Store the expected checksum in a file (e.g., artifact.sha512), then verify it with: sha512sum -c artifact.sha512. Enable strict error handling (for example, set -e in shell scripts) so the pipeline fails if verification fails or outputs errors.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info
There was a problem hiding this comment.
This is the same safe-chain install line used in the other 8 workflows here and in firewall-node, and none of them pin a version.
3da11cb to
4b71dd6
Compare
Update zen-internals to v0.1.74 and load the right build per platform