Skip to content

Conversation

@birjj
Copy link

@birjj birjj commented Mar 31, 2025

As exemplified by the recent tj-actions/changed-files compromise, pinning GitHub Action references to a tag is inherently unsafe: if the referenced action is compromised, the attacker can update any tags, including old ones, to point to whatever they want.

For something as crucial as IaC management it'd probably be preferable to use actually pinned versions over pinning to mutable tags. This PR updates the "Specifying version" docs to describe that process instead. Might as well push people towards the safer workflow 🤷

Also includes a fix to the docs so the code example for vLatest actually uses @vLatest, and removes the description MDX header, since it contains text that's immediately replicated in a more-visible warning directly below it.

Feel free to make any changes you feel relevant to make the wording flow better! This PR is mostly to suggest that the pin-to-commit-SHA approach is described in the docs.

Summary by CodeRabbit

Summary by CodeRabbit

  • Documentation
    • Updated versioning guidance for the Digger action.
    • Revised instructions now recommend using a commit SHA for pinning releases, enhancing security and performance.
    • Clarified the usage of the "vLatest" tag to denote the most recent release with pre-built binaries.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Mar 31, 2025

Walkthrough

The documentation for the Digger action has been updated to revise versioning guidance. The warning now emphasizes using a commit SHA instead of a version tag like @vX.Y.Z, and the example has been updated accordingly. Clarifications have also been made regarding the use of the vLatest tag, ensuring that documentation accurately reflects the intended secure versioning practices.

Changes

File Change Summary
docs/ce/howto/versioning.mdx Modified warning and examples to recommend using commit SHA references over the @vX.Y.Z format; clarified the role of the vLatest tag.

Suggested reviewers

  • motatoes

Poem

I’m a rabbit with a hop so bright,
Celebrating docs that now feel just right.
Commit SHA leads the way with flair,
Leaving old tags in gentle air.
🐰 Hoppin’ to secure the code with care!


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 84b5922 and 4d096e0.

📒 Files selected for processing (1)
  • docs/ce/howto/versioning.mdx (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • docs/ce/howto/versioning.mdx

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai plan to trigger planning for file edits and PR creation.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

PR Summary

This PR updates the versioning documentation to advise using 40-character commit SHAs for GitHub Actions, improving security for IaC management.

  • Revised /docs/ce/howto/versioning.mdx to promote pinned commit SHA usage with updated examples and warnings.
  • Enhanced instructions addressing risks of mutable tags.
  • YAML front matter still references the old @vX.Y.Z format, potentially causing confusion.

💡 (1/5) You can manually trigger the bot by mentioning @greptileai in a comment!

1 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings | Greptile

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (4)
docs/ce/howto/versioning.mdx (4)

2-4: Ensure header description consistency with new pinned SHA recommendation

The header (lines 2–4) still recommends using a pinned version of the form @vX.Y.Z, which conflicts with the new advice in the Warning block. For clarity and consistency, consider updating the header description to recommend a commit SHA reference. For example:

-description: "For serious usecases always use a pinned version which is of the form @vX.Y.Z since this will download a compiled binary. In addition to being faster to run, it is also more secure than using a commit from a branch"
+description: "For serious usecases, always use a commit SHA reference to pin the version from one of our releases, since this will download a compiled binary. In addition to being faster, it is also more secure than using a commit from a branch or tag"

14-19: Clear distinction for using the vLatest tag

The "Use vLatest tag" section now includes a code snippet using diggerhq/digger@vLatest. This example is useful for users who prefer performance (with pre-built binaries). However, given the context of security, ensure that it is clear that while vLatest may be acceptable in certain scenarios, for critical tasks a pinned commit SHA is strongly recommended.


32-42: Correct usage for latest commit from a branch with necessary warnings

The guidance under "Use latest commit from a branch" includes a clear warning that using a branch reference (e.g., @yolo-lets-do-it) is risky and should only be done in non-production scenarios. This reinforces the security message. You may consider adding a bit more context on why this practice is discouraged to enhance the user's understanding.


43-48: Example of branch commit usage is clear, but consider reinforcing the risk

The final code snippet clearly demonstrates using a branch reference for the Digger action. Since this practice is inherently riskier, you might add a brief inline comment or refer the reader back to the warning above, ensuring that the security implications are unmistakable.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cfb4dc9 and 84b5922.

📒 Files selected for processing (1)
  • docs/ce/howto/versioning.mdx (2 hunks)
🔇 Additional comments (2)
docs/ce/howto/versioning.mdx (2)

6-8: Great update to emphasize commit SHA for improved security

The updated Warning block now instructs users to use a commit SHA reference (in the format @<40-character-commit-SHA>), which is an excellent approach to prevent issues with mutable tags. This change clearly aligns with security best practices.


21-30: Updated pinned version instructions with commit SHA

The section "Use a pinned version" now clearly instructs users to look up the release in our releases and use the full commit SHA. The updated code snippet using the commit SHA (28a8ecd4ccb31f9196b1cbc9ceb14025059f97dc) accurately demonstrates the new, safer versioning practice.

@motatoes
Copy link
Contributor

motatoes commented Apr 2, 2025

Hi @birjj thanks for this! I totally agree with hardcoding the commit. The issue is that our current check for whether to build or download binary is based on if it starts with the letter "v" to identify release. So we need to figure out a better way of saying download binary vs build from source in the composite action before this can work with pure commit sha ref.

I think We need to figure that out before updating docs, (unless I missed something)

@birjj
Copy link
Author

birjj commented Apr 2, 2025

Ah, yes that would definitely be a problem. I don't have any good ideas for getting a reference to the release from the commit SHA, so that's a blocker. I'll close this for now, since it probably isn't relevant until some workaround is found.

@motatoes
Copy link
Contributor

motatoes commented Apr 2, 2025

Thanks, I've created a backlog issue to look into that so we can address it and then get back to this in the near future :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants