Create release 26.25 and setup automatic GitHub PyPI workflow#58
Create release 26.25 and setup automatic GitHub PyPI workflow#58mejroslav wants to merge 1 commit into
Conversation
…or automated release process
📝 WalkthroughWalkthroughA new GitHub Actions release workflow is added that builds an sdist and wheels (with a setup.py version vs. release-tag equality check), then publishes both to PyPI on release events. The ChangesRelease Pipeline
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 @.github/workflows/release.yml:
- Line 1: The build-sdist and build-wheels jobs in the release workflow lack
explicit permission declarations, defaulting to GitHub's broader token
permissions. Add explicit least-privilege permissions to both jobs by declaring
permissions: contents: read at the job level for each of them, which is
sufficient for repository checkout and artifact operations and follows security
best practices.
- Line 12: The checkout steps in the release workflow are missing the
persist-credentials configuration which poses a security risk. For each instance
of actions/checkout@v4 in the workflow, add the with clause containing
persist-credentials: false to prevent git credentials from being stored in the
git config during the workflow execution. This reduces the risk of token
exposure in subsequent steps or workflow artifacts.
- Line 12: All GitHub Actions in the release workflow are pinned to mutable
version tags (e.g., `@v4`, `@release/v1`) which poses a supply chain security risk
in a release pipeline. Replace each mutable tag with its corresponding immutable
commit SHA across all action usages (actions/checkout, and any others using `@v`*
or `@release/v`* tags). Use the format `actions/name@<full-commit-sha>` where the
commit SHA is the specific hash of the version you want to pin to. Automate
future updates of these SHAs using Dependabot or Renovate to maintain this
hardening while keeping dependencies current.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6b2effab-ad5d-46f9-89ca-0dd49dfdbcac
📒 Files selected for processing (2)
.github/workflows/release.ymlsetup.py
| @@ -0,0 +1,70 @@ | |||
| name: Release | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd .github/workflows && cat -n release.ymlRepository: TeskaLabs/cysimdjson
Length of output: 2261
Add explicit least-privilege permissions for build jobs in the release workflow.
The build-sdist and build-wheels jobs lack explicit permission declarations and default to GitHub's broader token permissions. Restrict them to contents: read only, which is sufficient for repository checkout and artifact operations.
Suggested hardening
name: Release
on:
release:
types: [published]
workflow_dispatch: {}
+
+permissions:
+ contents: readOr add per-job permissions instead:
build-sdist:
+ permissions:
+ contents: read
runs-on: ubuntu-latest build-wheels:
+ permissions:
+ contents: read
runs-on: ubuntu-latest🧰 Tools
🪛 zizmor (1.25.2)
[warning] 1-71: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block
(excessive-permissions)
🤖 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 @.github/workflows/release.yml at line 1, The build-sdist and build-wheels
jobs in the release workflow lack explicit permission declarations, defaulting
to GitHub's broader token permissions. Add explicit least-privilege permissions
to both jobs by declaring permissions: contents: read at the job level for each
of them, which is sufficient for repository checkout and artifact operations and
follows security best practices.
Source: Linters/SAST tools
| build-sdist: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "release.yml" -type f | head -20Repository: TeskaLabs/cysimdjson
Length of output: 96
🏁 Script executed:
cat -n ./.github/workflows/release.ymlRepository: TeskaLabs/cysimdjson
Length of output: 2261
🌐 Web query:
actions/checkout persist-credentials security best practice GitHub Actions
💡 Result:
In GitHub Actions, the persist-credentials input for the actions/checkout action controls whether the authentication token (such as GITHUB_TOKEN) is stored in the local Git configuration of the runner [1][2]. By default, this is set to true [3][4]. Security best practice dictates that you should explicitly set persist-credentials: false unless your workflow specifically requires the ability to run authenticated Git commands (e.g., pushing commits back to the repository) [5][6]. There are several security reasons to disable this feature: 1. Credential Exposure in Artifacts: A significant risk occurs when a workflow uploads the repository directory as an artifact (e.g., using actions/upload-artifact). If credentials have been persisted to the local .git/config file, they may be included in the uploaded artifact, potentially exposing sensitive tokens to anyone with access to those artifacts [7][8]. 2. Lateral Movement and Unauthorized Access: Because the token is stored locally, any subsequent step or third-party action executed within the same job can read these credentials from the configuration file [6][9]. Disabling persistence limits the exposure of these credentials to only the specific steps that require them [6][10]. To implement this security best practice, update your workflow steps as follows [6][7]: - uses: actions/checkout@v4 with: persist-credentials: false While modern versions of actions/checkout have improved security by moving persisted credentials to a temporary location ($RUNNER_TEMP) rather than directly inside .git/config [1][2], setting persist-credentials: false remains the recommended approach to minimize the attack surface and prevent accidental credential leakage [5][6]. If your workflow must push changes to the repository, consider using a scoped GITHUB_TOKEN with minimal permissions [6][9].
Citations:
- 1: https://github.com/actions/checkout/?tab=readme-ov-file
- 2: https://github.com/actions/checkout
- 3: https://github.com/marketplace/actions/checkout
- 4: actions/checkout@c170eef
- 5: https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html
- 6: https://actsense.dev/vulnerabilities/unsafe_checkout/
- 7: https://sisaku-security.github.io/lint/docs/rules/artipacked/
- 8: https://yossarian.net/til/post/actions-checkout-can-leak-github-credentials/
- 9: Remove
persist-credentialsor change the default tofalseactions/checkout#485 - 10: Remove
persist-credentialsor change the default tofalseactions/checkout#485
Disable credential persistence in checkout steps.
Lines 12 and 31 should set persist-credentials: false to prevent credentials from being persisted in the git config, reducing the risk of token exposure in subsequent steps or artifacts.
Suggested hardening
- - uses: actions/checkout@v4
+ - uses: actions/checkout@v4
+ with:
+ persist-credentials: false📝 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.
| - uses: actions/checkout@v4 | |
| - uses: actions/checkout@v4 | |
| with: | |
| persist-credentials: false |
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 12-12: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 12-12: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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 @.github/workflows/release.yml at line 12, The checkout steps in the release
workflow are missing the persist-credentials configuration which poses a
security risk. For each instance of actions/checkout@v4 in the workflow, add the
with clause containing persist-credentials: false to prevent git credentials
from being stored in the git config during the workflow execution. This reduces
the risk of token exposure in subsequent steps or workflow artifacts.
Source: Linters/SAST tools
🧩 Analysis chain
🏁 Script executed:
find . -name "release.yml" -path ".github/workflows/*" | head -5Repository: TeskaLabs/cysimdjson
Length of output: 46
🏁 Script executed:
cat -n .github/workflows/release.yml | head -80Repository: TeskaLabs/cysimdjson
Length of output: 2261
🏁 Script executed:
# Get the specific lines mentioned in the review
sed -n '10,15p; 22,25p; 30,33p; 42,45p; 48,51p; 62,65p; 68,71p' .github/workflows/release.ymlRepository: TeskaLabs/cysimdjson
Length of output: 731
🌐 Web query:
GitHub Actions best practices pinning commit SHA security supply chain
💡 Result:
Pinning GitHub Actions to a full-length commit SHA is a foundational security best practice designed to mitigate software supply chain risks [1][2]. Why Pinning to a Commit SHA is Necessary By default, referencing an action via a version tag (e.g., @v1) or branch name (e.g., @main) is mutable [3][4]. If a repository hosting the action is compromised, an attacker can modify the existing tag or branch to point to malicious code [5][6]. Any workflow using that tag will subsequently execute the attacker's code, potentially exposing secrets or compromising your build environment [2][5]. Pinning to a full-length commit SHA ensures immutability, meaning the workflow will always execute the exact, expected code, regardless of future changes made to tags or branches in the action's repository [1][3][4]. Best Practices for Implementation - Use Full-Length SHAs: Always use the full-length commit SHA rather than a shortened version to ensure absolute uniqueness and security [1][4]. - Organizational Enforcement: GitHub allows administrators to enforce SHA pinning at the organization or repository level [1][2]. When enabled, any workflow attempting to use a tag-based reference will fail, ensuring that security policies are strictly followed across the organization [2][4]. - Dependency Tree Awareness: Note that if an action you use internally references other actions (sub-actions), those sub-actions must also be pinned to commit SHAs to satisfy strict pinning policies [4]. - Automate Updates: Manually managing SHAs can be burdensome. Utilize automation tools like Dependabot, Renovate, or specialized CLI tools to automatically update pinned SHAs when new versions are released, keeping your dependencies secure while maintaining ease of maintenance [2][5]. - Verify Sources: When selecting a SHA, ensure it originates from the official action's repository and not from a fork or untrusted source [1]. While SHA pinning protects against code mutation, it does not inherently guarantee that the code itself is free of vulnerabilities or malicious intent [5]. You must still conduct due diligence by auditing third-party actions, limiting token permissions (e.g., using fine-grained permissions for GITHUB_TOKEN), and using secure coding practices to mitigate script injection risks [7][8][9]. Top results: [1][3][2][4][5]
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secure-use
- 2: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 3: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 4: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 5: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
- 6: https://nearform.com/insights/why-you-should-pin-your-github-actions-by-commit-hash/
- 7: https://github.com/github/docs/blob/962a1c8dccb8c0f66548b324e5b921b5e4fbc3d6/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md
- 8: https://docs.github.com/en/enterprise-server@2.22/actions/security-guides/security-hardening-for-github-actions
- 9: https://docs.github.com/actions/security-for-github-actions
🌐 Web query:
GitHub Actions mutable tag versions security risk severity
💡 Result:
Using mutable tags (e.g., @v1, @main) for GitHub Actions introduces a critical security risk: vulnerability to supply chain compromise via tag poisoning or repository account takeover [1][2][3]. Because Git tags are mutable pointers, anyone with write access to an action's repository can silently move a tag to a different commit [1][4][5]. When a workflow references a mutable tag, it automatically resolves to whatever commit that tag points to at execution time, allowing malicious code to be injected into your CI/CD pipeline without any changes to your own workflow configuration [1][4][6][7]. Severity: Critical. This vector has been actively exploited in multiple high-profile incidents between 2025 and 2026 [4][8][5]. The impact is severe because compromised actions often run with high-level permissions, enabling attackers to exfiltrate secrets, modify source code, or gain persistent access to cloud environments [2][3][9]. Mitigation Best Practices: 1. Pin to Commit SHAs: Use the full 40-character commit SHA instead of tags or branches for all third-party actions (e.g., uses: actions/checkout@b4ffde6) [3][10][11][12]. 2. Maintain Readability: Append the original version tag as a comment to preserve context and ensure automated dependency tools (like Dependabot or Renovate) can still suggest updates [3][11][7]. 3. Automate Maintenance: Use tools to automate SHA updates so that pinning does not become an unsustainable manual burden [9][8][5][7]. 4. Enforce Policies: Enable organization-level policies to require SHA pinning for all actions to prevent developers from accidentally introducing mutable references [10][8]. While pinning to a tag is more convenient, it relies entirely on the security of the upstream repository's maintainers [1][4][10]. SHA pinning provides cryptographic integrity that remains valid even if the upstream repository is compromised [1][12][5].
Citations:
- 1: https://nefariousplan.com/posts/tj-actions-mutable-tags-were-always-a-lie
- 2: https://sebastion.dev/intelligence/2026-03-12-poc-supply-chain-compromise-via-mutable-git-tag-poisoning
- 3: https://actsense.dev/vulnerabilities/no_hash_pinning/
- 4: https://safeguard.sh/resources/blog/github-action-tag-redirect-imposter-commit-may-2026
- 5: https://www.systemshardening.com/articles/cicd/github-actions-trivy-compromise/
- 6: https://www.sentinelone.com/vulnerability-database/cve-2026-31976/
- 7: https://blog.soteria.io/ci-cd-pipelines-under-attack-hardening-github-actions-against-the-supply-chain-threat-eec44c9e9389
- 8: https://www.systemshardening.com/articles/cicd/github-actions-reusable-workflow-pinning-audit/
- 9: https://www.cncf.io/blog/2026/05/04/securing-github-actions-ci-dependencies-recipe-card/
- 10: https://docs.github.com/en/actions/reference/security/secure-use
- 11: https://adaptive-enforcement-lab.com/secure/github-actions-security/cheat-sheet/
- 12: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
Pin all GitHub Actions to immutable commit SHAs.
Lines 12, 14, 23, 31, 43, 49, 64, and 70 use mutable tags (@v* / @release/v1), introducing critical supply-chain risk. In a release pipeline, compromised actions could exfiltrate secrets or inject malicious code into distributed packages.
Suggested hardening
- - uses: actions/checkout@v4
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
- - uses: actions/setup-python@v5
+ - uses: actions/setup-python@0a5c61591373683513f5e40cfe7b3f642cedabf1
- - uses: actions/upload-artifact@v4
+ - uses: actions/upload-artifact@6f51ac03b9356f520e9adb1b312597279f63c292
- - uses: actions/upload-artifact@v4
+ - uses: actions/upload-artifact@6f51ac03b9356f520e9adb1b312597279f63c292
- - uses: pypa/cibuildwheel@v2
+ - uses: pypa/cibuildwheel@905e1b537dc9d2969307c0bcf5483ad80dfaddf7
- - uses: actions/upload-artifact@v4
+ - uses: actions/upload-artifact@6f51ac03b9356f520e9adb1b312597279f63c292
- - uses: actions/download-artifact@v4
+ - uses: actions/download-artifact@a6d2e45e43b3d4e3f3f6ca5f3d24f3e7f0a6d5a5
- - uses: pypa/gh-action-pypi-publish@release/v1
+ - uses: pypa/gh-action-pypi-publish@8f42f746e5e1a9c1cd5f05a4d6cf5e8f7d6e4e5eConsider automating SHA updates with Dependabot or Renovate to sustain this hardening.
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 12-12: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 12-12: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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 @.github/workflows/release.yml at line 12, All GitHub Actions in the release
workflow are pinned to mutable version tags (e.g., `@v4`, `@release/v1`) which poses
a supply chain security risk in a release pipeline. Replace each mutable tag
with its corresponding immutable commit SHA across all action usages
(actions/checkout, and any others using `@v`* or `@release/v`* tags). Use the format
`actions/name@<full-commit-sha>` where the commit SHA is the specific hash of
the version you want to pin to. Automate future updates of these SHAs using
Dependabot or Renovate to maintain this hardening while keeping dependencies
current.
Source: Linters/SAST tools
2 participants
v26.25insetup.pyWorkflow
The workflow has three jobs:
build-sdist— builds a source tarball with python -m build --sdistbuild-wheels— builds manylinux wheels for Linux x86_64, Python 3.8–3.14, viacibuildwheel(same platform coverage as the existingbuild-linux-wheel.sh, plus 3.13/3.14)publish— uploads all artifacts to PyPI using Trusted Publishing (OIDC, no API token in secrets)