chore: resolve merge with master — keep OIDC PyPI workflows#87
chore: resolve merge with master — keep OIDC PyPI workflows#87
Conversation
This keeps Python and frontend package metadata aligned for the new development cycle on develop/v2.0.7. Made-with: Cursor
- Add test_bench_rule_catalog and rules_reference YAML; SPARQL smoke table in cookbook - MCP RAG: empty upstream body handling, SearchApiCapabilitiesRequest with extra ignore - Bootstrap tests: timeout, stderr for invalid --mode - E2e/fake BACnet: dedupe Plots helpers, task refs + stop(), monitor RPC guards, CRLF .cmd + .gitattributes - Misc: fix_dpkg paths, 4_hot_reload JSON error detail, docs nits Made-with: Cursor
… cruft Made-with: Cursor
…esting_layers + session trail Made-with: Cursor
Made-with: Cursor
Made-with: Cursor
Made-with: Cursor
…ill refs Made-with: Cursor
Add references/legacy_automated_testing.md with full path map from bbartling/open-fdd-automated-testing into open-fdd, deprecation README snippet, and roadmap for lab vs AI modeling vs live operator. SKILL.md: explain AgentSkills shape, bundled vs repo skill, and link legacy doc; expand AI modeling and live HVAC sections. Point root README, HANDOFF_PROTOCOL, openclaw_context_bootstrap, long run paste block, skill_installation, and issues_log at the canonical openclaw tree. Made-with: Cursor
Add references/session_status_summary.md with mandatory output shape, human paste prompt, and agent checklists (issues_log sections, PIDs, log paths, edge cases). Wire SKILL, HANDOFF_PROTOCOL, long_run_lab_pass, api_throttle, issues_log rules, README, and openclaw_context_bootstrap. Made-with: Cursor
Add howto/engine_only_iot.md comparing bootstrap --mode engine (Docker) vs library RuleRunner for external collection/modeling. Link from modular architecture, howto index, and openfdd-engine README. Made-with: Cursor
- Add publish-open-fdd.yml (tag open-fdd-v*, secret PYPI_OPENFDD_TOKEN) - Rewrite openfdd_engine_pypi.md: both packages, order, local dry run - Align README, technical_reference, _config, standalone_csv_pandas with 2.x PyPI = engine + extras; edge stack from repo Made-with: Cursor
- Bump open-fdd to 2.0.8 in root pyproject.toml - Bump frontend package.json + package-lock.json to 2.0.8 - Bump openfdd-engine to 0.1.1, require open-fdd>=2.0.8 - Handoff/long_run: generic branch placeholders; issues_log release note Made-with: Cursor
- Use Python 3.14 in publish-open-fdd and publish-openfdd-engine workflows - Explain 403 is token/project permissions, not runner Python version - Note per-project API tokens for both secrets Made-with: Cursor
Replace twine + empty TWINE_PASSWORD with pypa/gh-action-pypi-publish and id-token: write. Configure each PyPI project with a GitHub publisher for the matching workflow file. Document setup and token fallback in openfdd_engine_pypi.md. Made-with: Cursor
📝 WalkthroughWalkthroughCI/CD workflows are updated to use PyPI Trusted Publishing with OIDC instead of token-based authentication, Python runtime upgraded from 3.12 to 3.14, and documentation updated to reflect the new authentication mechanism and troubleshooting guidance. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 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)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/publish-open-fdd.yml:
- Around line 36-38: Replace the mutable ref
pypa/gh-action-pypi-publish@release/v1 with an immutable full commit SHA to
harden the workflow: locate the uses entry referencing
"pypa/gh-action-pypi-publish@release/v1" and change it to
"pypa/gh-action-pypi-publish@<full-commit-sha>" (use the repository commit SHA
you validated), keep the existing with: packages-dir: dist/ intact, and commit
the updated workflow so the action is pinned to that specific immutable commit.
In @.github/workflows/publish-openfdd-engine.yml:
- Around line 35-37: Replace the mutable tag in the GitHub Actions step that
uses "pypa/gh-action-pypi-publish@release/v1" by pinning to a full commit SHA
(e.g., @<full-commit-sha>) and add an inline comment indicating the readable
version (for example: # release/v1) to retain clarity; update the "uses:
pypa/gh-action-pypi-publish@release/v1" line to reference the full SHA so the
action is immutable and follows the security best practice described in the
review.
In `@docs/howto/openfdd_engine_pypi.md`:
- Around line 50-55: The snippet uses packages-dir: dist/ which is correct for
open-fdd but wrong for the openfdd-engine workflow; update the docs to clarify
the fallback path for the openfdd-engine workflow by adding or replacing the
example to show packages-dir: packages/openfdd-engine/dist/ (or state both
options and instruct readers to use the engine-specific path when publishing
openfdd-engine), and mention the exact YAML key packages-dir so readers know
which value to change.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 343978c4-b43d-4593-92c6-ee21fb0c8af0
📒 Files selected for processing (3)
.github/workflows/publish-open-fdd.yml.github/workflows/publish-openfdd-engine.ymldocs/howto/openfdd_engine_pypi.md
| uses: pypa/gh-action-pypi-publish@release/v1 | ||
| with: | ||
| packages-dir: dist/ |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Current workflow references:"
rg -n 'gh-action-pypi-publish@' .github/workflows
echo
echo "Resolve current commit behind release/v1:"
gh api repos/pypa/gh-action-pypi-publish/commits/release/v1 --jq '.sha'Repository: bbartling/open-fdd
Length of output: 490
🏁 Script executed:
# Verify the exact content of the file at the specified lines
cat -n .github/workflows/publish-open-fdd.yml | sed -n '30,45p'Repository: bbartling/open-fdd
Length of output: 519
🌐 Web query:
GitHub Actions pinning to commit SHA security best practices
💡 Result:
Pinning GitHub Actions to a full-length commit SHA is the recommended security best practice to ensure immutability and prevent supply chain attacks where malicious code could be injected via tag overwrites. Key best practices: - Always pin to full-length commit SHAs (40 characters), not short SHAs or tags like 'v1'. Example: - uses: actions/checkout@692973e # v4.1.7 Verify the SHA is from the official repository, not a fork. - Prioritize high-risk third-party actions (those handling secrets or sensitive operations). - Use GitHub policies to enforce SHA pinning at repository/organization level. - Periodically update pins using Dependabot or Renovate (they recognize version comments like # v4.1.7). - Audit action source code and prefer verified creators from GitHub Marketplace. - Tools like Hyland/github-actions-ensure-sha-pinned-actions can automate conversion of tags to SHAs. - Combine with other hardening: minimize GITHUB_TOKEN permissions, use OIDC, restrict permissions. This mitigates risks like tag force-pushing malicious code, as SHAs are immutable (requiring SHA-1 collision attacks, which are infeasible). Note: SHA-pinned actions won't get Dependabot vulnerability alerts (only for semver tags), so monitor manually or via other tools.
Citations:
- 1: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 2: https://www.codewrecks.com/post/github/github-sha-pinning/
- 3: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 4: https://docs.github.com/en/actions/reference/security/secure-use
- 5: https://www.nearform.com/insights/why-you-should-pin-your-github-actions-by-commit-hash
- 6: https://github.com/Hyland/github-actions-ensure-sha-pinned-actions
- 7: https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-githubs-security-features-to-secure-your-use-of-github-actions
- 8: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions
🏁 Script executed:
# Check how other actions are pinned in this workflow file
cat -n .github/workflows/publish-open-fdd.yml | head -40Repository: bbartling/open-fdd
Length of output: 1270
🏁 Script executed:
# Check both workflow files that reference gh-action-pypi-publish
echo "=== publish-open-fdd.yml ===" && grep -A 2 -B 2 'gh-action-pypi-publish' .github/workflows/publish-open-fdd.yml
echo
echo "=== publish-openfdd-engine.yml ===" && grep -A 2 -B 2 'gh-action-pypi-publish' .github/workflows/publish-openfdd-engine.ymlRepository: bbartling/open-fdd
Length of output: 528
Pin gh-action-pypi-publish to an immutable commit SHA.
Line 36 uses @release/v1, a mutable ref that can be exploited for supply chain attacks if the tag is force-pushed. Pinning to a full-length commit SHA hardens the release pipeline against upstream tag overwrites.
🔒 Suggested change
- uses: pypa/gh-action-pypi-publish@release/v1
+ uses: pypa/gh-action-pypi-publish@<FULL_LENGTH_COMMIT_SHA>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish-open-fdd.yml around lines 36 - 38, Replace the
mutable ref pypa/gh-action-pypi-publish@release/v1 with an immutable full commit
SHA to harden the workflow: locate the uses entry referencing
"pypa/gh-action-pypi-publish@release/v1" and change it to
"pypa/gh-action-pypi-publish@<full-commit-sha>" (use the repository commit SHA
you validated), keep the existing with: packages-dir: dist/ intact, and commit
the updated workflow so the action is pinned to that specific immutable commit.
| uses: pypa/gh-action-pypi-publish@release/v1 | ||
| with: | ||
| packages-dir: packages/openfdd-engine/dist/ |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check if the file exists and read its contents
cat -n .github/workflows/publish-openfdd-engine.ymlRepository: bbartling/open-fdd
Length of output: 1177
🌐 Web query:
GitHub Actions @release/v1vs@v4 mutable pinning commit SHA best practices
💡 Result:
GitHub Actions best practices recommend pinning actions to full commit SHAs for maximum security against supply chain attacks, as tags like @v4 or @release/v1 are mutable and can be retargeted to malicious commits. @v4 refers to the latest minor/patch in the v4 major version (e.g., actions/checkout@v4 points to the current v4.x.x tag), while @release/v1 likely refers to a custom or action-specific tag like 'release/v1' in some release management actions (e.g., similar to ncipollo/release-action's v1 tag management), which is also mutable. SHA pinning example: uses: actions/checkout@08c6903 # v5.0.0 Add the version comment for readability and Dependabot/Renovate updates. Official GitHub docs emphasize SHA pinning for third-party actions, with policies to enforce it organization-wide. Major version tags (@v4) balance usability and security if you trust the creator, but SHA is preferred. Use tools like pinata, Renovate's pinGitHubActionDigestsToSemver, or Dependabot for automation. @release/v1 vs @v4: Both mutable tags; no specific distinction found, but treat as equivalent risk level—pin to SHA regardless.
Citations:
- 1: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability
- 2: fix: pin GitHub Actions to immutable SHA hashes to prevent supply chain attacks github/awesome-copilot#1088
- 3: https://carlosbecker.com/posts/pinning-github-actions/
- 4: https://dev.to/ciberconscientes/github-actions-why-you-should-pin-your-actions-to-a-specific-version-1513
- 5: https://medium.com/@adan.alvarez/github-actions-and-the-pinning-problem-what-100-security-projects-reveal-54a3a9dcc902
- 6: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 7: security issue: Third-party action not pinned to commit ID ncipollo/release-action#450
- 8: https://docs.github.com/en/actions/how-tos/create-and-publish-actions/manage-custom-actions
- 9: https://docs.github.com/en/actions/reference/security/secure-use
- 10: https://github.com/actions/toolkit/blob/master/docs/action-versioning.md
- 11: https://stackoverflow.com/questions/70192880/how-to-know-what-version-of-a-github-action-to-use
- 12: https://github.com/ncipollo/release-action/releases
🏁 Script executed:
# Check for other workflow files
find .github/workflows -name "*.yml" -o -name "*.yaml" | head -20Repository: bbartling/open-fdd
Length of output: 170
🏁 Script executed:
# Check the other workflow files for action pinning patterns
echo "=== ci.yml ===" && head -40 .github/workflows/ci.yml && echo -e "\n=== publish-open-fdd.yml ===" && head -40 .github/workflows/publish-open-fdd.ymlRepository: bbartling/open-fdd
Length of output: 1992
Pin the publish action to a full commit SHA.
On line 35, @release/v1 is a mutable tag and poses a supply chain security risk. Pin pypa/gh-action-pypi-publish to a full commit SHA with a version comment for readability, following GitHub Actions security best practices.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish-openfdd-engine.yml around lines 35 - 37, Replace
the mutable tag in the GitHub Actions step that uses
"pypa/gh-action-pypi-publish@release/v1" by pinning to a full commit SHA (e.g.,
@<full-commit-sha>) and add an inline comment indicating the readable version
(for example: # release/v1) to retain clarity; update the "uses:
pypa/gh-action-pypi-publish@release/v1" line to reference the full SHA so the
action is immutable and follows the security best practice described in the
review.
| ```yaml | ||
| uses: pypa/gh-action-pypi-publish@release/v1 | ||
| with: | ||
| packages-dir: dist/ | ||
| password: ${{ secrets.PYPI_OPENFDD_TOKEN }} | ||
| ``` |
There was a problem hiding this comment.
Clarify fallback snippet for openfdd-engine path.
The example on Lines 50-55 uses packages-dir: dist/, which is correct for open-fdd but not for openfdd-engine (that workflow uses packages/openfdd-engine/dist/). A copy/paste here can cause failed uploads.
📝 Suggested doc tweak
uses: pypa/gh-action-pypi-publish@release/v1
with:
packages-dir: dist/
password: ${{ secrets.PYPI_OPENFDD_TOKEN }}
+
+# For openfdd-engine workflow, use:
+# packages-dir: packages/openfdd-engine/dist/
+# password: ${{ secrets.PYPI_OPENFDD_ENGINE_TOKEN }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/howto/openfdd_engine_pypi.md` around lines 50 - 55, The snippet uses
packages-dir: dist/ which is correct for open-fdd but wrong for the
openfdd-engine workflow; update the docs to clarify the fallback path for the
openfdd-engine workflow by adding or replacing the example to show packages-dir:
packages/openfdd-engine/dist/ (or state both options and instruct readers to use
the engine-specific path when publishing openfdd-engine), and mention the exact
YAML key packages-dir so readers know which value to change.
Made-with: Cursor # Conflicts: # docs/howto/openfdd_engine_pypi.md
Summary by CodeRabbit
Chores
Documentation