Skip to content

Create release 26.25 and setup automatic GitHub PyPI workflow #58

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mejroslav wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Create release 26.25 and setup automatic GitHub PyPI workflow #58

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 70 additions & 0 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,70 @@
name: Release

@coderabbitai coderabbitai Bot Jun 15, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cd .github/workflows && cat -n release.yml

Repository: 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: read

Or 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


on:
release:
types: [published]
workflow_dispatch: {}

jobs:
build-sdist:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4

@coderabbitai coderabbitai Bot Jun 15, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

find . -name "release.yml" -type f | head -20

Repository: TeskaLabs/cysimdjson

Length of output: 96

🏁 Script executed:

cat -n ./.github/workflows/release.yml

Repository: 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:

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.

Suggested change
- 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

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

find . -name "release.yml" -path ".github/workflows/*" | head -5

Repository: TeskaLabs/cysimdjson

Length of output: 46

🏁 Script executed:

cat -n .github/workflows/release.yml | head -80

Repository: 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.yml

Repository: 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:

🌐 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:

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@8f42f746e5e1a9c1cd5f05a4d6cf5e8f7d6e4e5e

Consider 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


- uses: actions/setup-python@v5
with:
python-version: "3.12"

- name: Build sdist
run: |
python -m pip install --upgrade pip build
python -m build --sdist

- uses: actions/upload-artifact@v4
with:
name: sdist
path: dist/*.tar.gz

build-wheels:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4

- name: Verify version matches release tag
if: github.event_name == 'release'
run: |
VERSION=$(sed -n "s/^[[:space:]]*version=[\"']\\([^\"']*\\)[\"'].*/\\1/p" setup.py)
TAG="${GITHUB_REF_NAME#v}"
if [ "$VERSION" != "$TAG" ]; then
echo "setup.py version ($VERSION) does not match tag ($TAG)"
exit 1
fi

- uses: pypa/cibuildwheel@v2
env:
CIBW_BUILD: cp38-* cp39-* cp310-* cp311-* cp312-* cp313-* cp314-*
CIBW_SKIP: "*-musllinux_*"
CIBW_ARCHS_LINUX: x86_64

- uses: actions/upload-artifact@v4
with:
name: wheels
path: wheelhouse/*.whl

publish:
if: github.event_name == 'release'
needs: [build-sdist, build-wheels]
runs-on: ubuntu-latest
environment:
name: pypi
url: https://pypi.org/p/cysimdjson
permissions:
id-token: write
steps:
- uses: actions/download-artifact@v4
with:
pattern: "*"
merge-multiple: true
path: dist

- uses: pypa/gh-action-pypi-publish@release/v1
2 changes: 1 addition & 1 deletion setup.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@

setup(
name='cysimdjson',
version="24.12",
version="26.25",
description='High-speed JSON parser',
long_description=long_description,
long_description_content_type='text/markdown',
Expand Down
Loading