Update publish-docker.yml

[svengo]

Summary by CodeRabbit

• New Features

  • Consolidated Docker image attestation steps for improved efficiency.
  • Updated attestation to support multiple image names in a single entry.

• Bug Fixes

  • Adjusted input indentation for the subject-name to accommodate multi-line format.

[coderabbitai]

Walkthrough

The pull request modifies the GitHub Actions workflow for Docker image publication. The key change involves consolidating Docker image attestation steps to simultaneously attest images on Docker Hub and GitHub Container Registry (ghcr.io). The workflow now uses a multi-line subject-name input that allows specifying both image registry destinations in a single configuration, reducing redundancy while maintaining the core image build and push functionality.

Changes

File	Change Summary
.github/workflows/publish-docker.yml	- Updated attestation step name from "Attest DockerHub" to "Attest Docker images" - Modified subject-name input to support multiple image registries (Docker Hub and ghcr.io)

Poem

🐰 A Docker workflow tale unfolds,
With registries both new and old,
One step to attest them all with grace,
Efficiency dancing at rapid pace!
Hop, hop, workflow magic takes flight! 🚢

---

📜 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 b5ae4d4 and 67e583e.

📒 Files selected for processing (1)

• .github/workflows/publish-docker.yml (1 hunks)

🔇 Additional comments (1)

.github/workflows/publish-docker.yml (1)

79-84: LGTM! Clean consolidation of attestation steps.

The changes effectively combine Docker Hub and GHCR attestations into a single step while maintaining proper functionality. The use of YAML's multi-line syntax is appropriate for handling multiple registry targets.

Let's verify the attestation configuration:

✅ Verification successful

Consider upgrading to the latest attestation action version (v2.1.0)

The workflow is using actions/attest-build-provenance@v2 while the latest version is v2.1.0. The attestation configuration looks correct with:

• Proper permissions set for attestations and package publishing
• No redundant attestation steps in other workflow files
• Correct multi-registry configuration

Consider updating to the specific version tag @v2.1.0 for better version control and to leverage the latest features.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the workflow's attestation configuration

# Check if the workflow uses the latest version of the attestation action
gh api repos/actions/attest-build-provenance/releases/latest --jq .tag_name

# Verify permissions are correctly set
rg -A 5 "permissions:" .github/workflows/publish-docker.yml

# Check for any other attestation steps that might be redundant
rg "actions/attest-build-provenance" .github/workflows/

Length of output: 436

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 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. (Beta)
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @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.

[svengo]

@coderabbitai write a documentation for using the attestation feature

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@svengo

Here's the documentation for using the attestation feature with docker-tor:

---

Using the Attestation Feature in docker-tor

The attestation feature in docker-tor enhances security by allowing users to verify the integrity and authenticity of the Docker images before running them. This ensures that the images have not been tampered with and are exactly as the maintainer intended.

Prerequisites

• Docker installed on your system.
• Access to the public attestation key provided by the image maintainer.
• The notary client installed (if using Docker Content Trust).

Steps to Use the Attestation Feature

1. Enable Docker Content Trust (Optional)

Docker Content Trust provides the ability to use digital signatures for data sent to and received from remote Docker registries:

export DOCKER_CONTENT_TRUST=1

2. Obtain the Public Attestation Key

Get the public key used to sign the Docker images:

wget https://example.com/attestation_pubkey.pem -O attestation_pubkey.pem

Replace https://example.com/attestation_pubkey.pem with the actual URL where the public key is hosted.

3. Pull the Docker Image with Verification

Pull the docker-tor image while verifying its integrity:

docker pull svengo/docker-tor:latest

If Docker Content Trust is enabled, the client will automatically verify the image's signature.

4. Manually Verify the Image Signature (If Needed)

If you need to manually verify the image signature:

notary -d ~/.docker/trust verify svengo/docker-tor latest

5. Run the Verified Docker Image

After verification, run the Docker image as usual:

docker run -d --name tor svengo/docker-tor:latest

Additional Tips

• Automate Verification in CI/CD Pipelines: Incorporate attestation verification into your deployment pipelines to ensure all deployed images are verified.
• Stay Updated: Regularly check for updates to the public attestation key and rotate keys as recommended by the maintainer.
• Consult the Maintainer's Documentation: For advanced usage and troubleshooting, refer to the official documentation or contact the image maintainer.

Troubleshooting

• Verification Failed: If the attestation fails, do not run the image. Ensure you have the correct public key and that you're pulling the image from a trusted source.
• Outdated Keys: Public keys may expire or be rotated. Always use the latest key provided by the maintainer.

---

Let me know if you have any questions or need further assistance!