Skip to content
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.

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

attest build provenance #945

Merged
merged 1 commit into from
Jul 2, 2024
Merged

attest build provenance #945

merged 1 commit into from
Jul 2, 2024

Conversation

shogo82148
Copy link
Owner

@shogo82148 shogo82148 commented Jul 1, 2024

Summary by CodeRabbit

  • Chores
    • Updated build workflows to include write permissions for contents, id-token, and attestations.
    • Integrated build provenance attestation using actions/attest-build-provenance@v1.

Copy link

coderabbitai bot commented Jul 1, 2024

Walkthrough

The recent adjustments to the GitHub workflow configuration files primarily involve enhancing security and traceability of the builds for various Redis versions and a Valkey build. These changes include adding write permissions for contents, id-token, and attestations, and introducing a new step using actions/attest-build-provenance@v1 to attest build provenance. This ensures that the build process is documented and verifiable.

Changes

Files Change Summary
.github/workflows/build-redis-2.8.yml Added write permissions for contents, id-token, attestations; added step using actions/attest-build-provenance@v1 with subject-path.
.github/workflows/build-redis-3.0.yml, ... , .github/workflows/build-redis-7.0.yml, .github/workflows/build-redis-7.2.yml Introduced write permissions for contents, id-token, and attestations; included a step with actions/attest-build-provenance@v1 and subject-path configuration.
.github/workflows/build-valkey-7.2.yml Added permissions and step using actions/attest-build-provenance@v1 with subject-path: ${{ runner.temp }}/*.tar.zstd.

Poem

Changes come with a token's gleam,
Redis builds, secured upstream.
Permissions write, attest they say,
Provenance clear as light of day.
Secure the path, the rabbit's creed,
In code we trust, the deeds we seed.
🍃🌟


Tip

Early access features: disabled

We are currently testing the following features in early access:

  • OpenAI gpt-4o model for code reviews and chat: OpenAI claims that this model is better at understanding and generating code than the previous models. We seek your feedback over the next few weeks before making it generally available.

Note:

  • You can enable or disable early access features from the CodeRabbit UI or by updating the CodeRabbit configuration file.
  • Please join our Discord Community to provide feedback and report issues.
  • OSS projects are currently opted into early access features by default.
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>.
    • 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 generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @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 as 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 resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration 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

@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

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between c47c2fe and 295029e.

Files selected for processing (10)
  • .github/workflows/build-redis-2.8.yml (2 hunks)
  • .github/workflows/build-redis-3.0.yml (2 hunks)
  • .github/workflows/build-redis-3.2.yml (2 hunks)
  • .github/workflows/build-redis-4.0.yml (2 hunks)
  • .github/workflows/build-redis-5.0.yml (2 hunks)
  • .github/workflows/build-redis-6.0.yml (2 hunks)
  • .github/workflows/build-redis-6.2.yml (2 hunks)
  • .github/workflows/build-redis-7.0.yml (2 hunks)
  • .github/workflows/build-redis-7.2.yml (2 hunks)
  • .github/workflows/build-valkey-7.2.yml (2 hunks)
Additional comments not posted (20)
.github/workflows/build-valkey-7.2.yml (2)

54-56: Review the attestation step configuration.

The step configuration for actions/attest-build-provenance@v1 seems correct, but verify that the subject-path pattern ${{ runner.temp }}/*.tar.zstd correctly matches the intended artifacts.


21-24: Ensure appropriate scope of permissions.

Permissions for contents, id-token, and attestations are set to write. Confirm that these permissions are necessary and minimal for the required operations to enhance security.

Verification successful

Permissions are appropriate and necessary.

The permissions contents: write, id-token: write, and attestations: write in the workflow file are justified based on the operations performed:

  • contents: write is required for the gh release upload command in the upload step.

  • id-token: write and attestations: write are required for actions/attest-build-provenance@v1.

Scripts executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify that the permissions set are necessary for the operations performed.

# Test: Review the GitHub Actions documentation and the specific needs of the steps in the workflow.
echo "Review GitHub Actions permissions documentation and workflow requirements."

Length of output: 158



Script:

#!/bin/bash
# Extract and display the steps in the specified GitHub Actions workflow file for analysis.

# Locate the workflow file
workflow_file=$(fd build-valkey-7.2.yml .github/workflows)

# Display the steps in the workflow file
yq e '.jobs.build.steps' "$workflow_file"

Length of output: 233



Script:

#!/bin/bash
# Extract and display the steps in the specified GitHub Actions workflow file for analysis.

# Locate the workflow file
workflow_file=$(fd build-valkey-7.2.yml .github/workflows)

# Extract and display the steps section
grep -A 50 'steps:' "$workflow_file" | sed '/^[[:space:]]*$/q'

Length of output: 393



Script:

#!/bin/bash
# Extract and display the entire workflow file for any additional steps and check the build script for required permissions.

# Locate the workflow file
workflow_file=$(fd build-valkey-7.2.yml .github/workflows)

# Display the entire workflow file
cat "$workflow_file"

# Locate the build script
build_script=$(fd build-valkey-with-openssl3.sh)

# Display the contents of the build script
cat "$build_script"

Length of output: 4997

.github/workflows/build-redis-7.2.yml (2)

26-29: Confirm the necessity of broad permissions.

Permissions for contents, id-token, and attestations are set to write. Ensure that these permissions are strictly necessary for the tasks performed by the workflow.

Verification successful

Confirm the necessity of broad permissions.

Permissions for contents, id-token, and attestations are set to write. These permissions are necessary for the tasks performed by the workflow:

  • contents: write is required for the gh release upload command.

  • id-token: write is likely needed for authentication purposes.

  • attestations: write is needed for the actions/attest-build-provenance action.

Scripts executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify the necessity of the permissions set in the workflow.

# Test: Review the GitHub Actions permissions documentation and the specific needs of the steps in the workflow.
echo "Review GitHub Actions permissions documentation and workflow requirements."

Length of output: 158



Script:

#!/bin/bash
# Extract and review the steps in the .github/workflows/build-redis-7.2.yml file to understand the necessity of the permissions.

# Print the steps section from the workflow file
awk '/steps:/,0' .github/workflows/build-redis-7.2.yml

Length of output: 1226


59-61: Check the attestation step configuration for Redis.

The attestation step uses actions/attest-build-provenance@v1 with a subject-path of ${{ runner.temp }}/*.tar.zstd. Validate that this path correctly targets the artifacts produced by Redis builds.

Verification successful

The attestation step configuration is correct.

The subject-path in the attestation step uses the pattern ${{ runner.temp }}/*.tar.zstd, which correctly targets the Redis artifacts produced and stored in the temporary directory.

  • The build step moves the Redis binary to ${{ runner.temp }}/redis-$REDIS_VERSION-$REDIS_OS-$REDIS_ARCH.tar.zstd, which matches the subject-path pattern.
Scripts executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify that the subject-path pattern matches the intended artifacts for Redis.

# Test: Check the runner's temporary directory for the presence of `.tar.zstd` files specific to Redis.
echo "List Redis-specific files in ${RUNNER_TEMP} to verify match with '*.tar.zstd'"

Length of output: 142



Script:

#!/bin/bash
# Description: Verify that the subject-path pattern matches the intended artifacts for Redis.

# Test: List the contents of the temporary directory and check for .tar.zstd files
# Assuming a standard temporary directory path for the runner
TEMP_DIR=${RUNNER_TEMP:-/tmp}

# List .tar.zstd files in the temp directory
echo "Listing .tar.zstd files in $TEMP_DIR:"
ls $TEMP_DIR/*.tar.zstd 2>/dev/null

Length of output: 113



Script:

#!/bin/bash
# Description: Extract build steps from the workflow file to understand artifact storage location.

# Search for steps containing artifact storage information in the build-redis-7.2.yml file
workflow_file=$(fd build-redis-7.2.yml)

# Print lines containing 'artifact' or 'store'
grep -i -E 'artifact|store' "$workflow_file"

Length of output: 109



Script:

#!/bin/bash
# Description: Locate the build-redis-7.2.yml file and extract lines containing artifact storage information.

# Locate the build-redis-7.2.yml file
workflow_file=$(fd build-redis-7.2.yml)

# Check if the file was found
if [ -n "$workflow_file" ]; then
  # Print lines containing 'artifact' or 'store'
  grep -i -E 'artifact|store' "$workflow_file"
else
  echo "build-redis-7.2.yml file not found."
fi

Length of output: 139



Script:

#!/bin/bash
# Description: Search for all YAML files in the .github/workflows directory to locate the build-redis-7.2.yml file.

# List all YAML files in the .github/workflows directory
fd .yml .github/workflows

Length of output: 534



Script:

#!/bin/bash
# Description: Extract lines containing artifact storage information from the build-redis-7.2.yml file.

# Define the path to the workflow file
workflow_file=".github/workflows/build-redis-7.2.yml"

# Print lines containing 'artifact' or 'store'
grep -i -E 'artifact|store' "$workflow_file"

Length of output: 121



Script:

#!/bin/bash
# Description: Display the entire content of the build-redis-7.2.yml file for manual inspection.

# Define the path to the workflow file
workflow_file=".github/workflows/build-redis-7.2.yml"

# Display the content of the file
cat "$workflow_file"

Length of output: 1758

.github/workflows/build-redis-3.0.yml (2)

61-63: Ensure correct attestation for older Redis builds.

The attestation step for Redis 3.0 uses the same configuration as newer versions. Verify that the subject-path is correctly configured to capture the artifacts of Redis 3.0.

Verification successful

Ensure correct attestation for older Redis builds.

The attestation step for Redis 3.0 uses the same configuration as newer versions. The subject-path is correctly configured to capture the artifacts of Redis 3.0.

  • The artifacts are named in the format redis-$REDIS_VERSION-$REDIS_OS-$REDIS_ARCH.tar.zstd and stored in the ${RUNNER_TEMP} directory.
  • The subject-path ${{ runner.temp }}/*.tar.zstd correctly matches this pattern.
Scripts executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Ensure the attestation step is correctly configured for older Redis versions.

# Test: Check the artifacts generated for Redis 3.0 to ensure they match the `subject-path` specified.
echo "List Redis 3.0-specific files in ${RUNNER_TEMP} to confirm match with '*.tar.zstd'"

Length of output: 152



Script:

#!/bin/bash
# Description: Inspect the build workflow for Redis 3.0 to understand artifact generation and paths used.

# Locate the build workflow file for Redis 3.0
workflow_file=$(fd build-redis-3.0.yml .github/workflows)

# Print the content of the build workflow file
cat "$workflow_file"

Length of output: 1828


28-31: Verify the appropriateness of permissions for older Redis version.

Given that this workflow handles an older version of Redis, confirm that the permissions contents: write, id-token: write, and attestations: write are appropriate and not excessive.

Verification successful

Permissions are appropriate for Redis 3.0 workflow.

The permissions contents: write, id-token: write, and attestations: write are necessary for the operations performed in the workflow, including checking out the repository, uploading release assets, and attesting build provenance.

  • actions/checkout@v4 requires contents: write.
  • GitHub CLI upload in the upload step requires contents: write.
  • actions/attest-build-provenance@v1 requires id-token: write and attestations: write.
Scripts executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Assess if the set permissions are appropriate for the older version of Redis.

# Test: Review the specific operations performed by Redis 3.0 in the workflow and check against GitHub Actions permissions documentation.
echo "Review operations for Redis 3.0 and verify permissions against GitHub documentation."

Length of output: 178



Script:

#!/bin/bash
# Extract the operations performed in the Redis 3.0 workflow

# Display the relevant section of the workflow file
echo "Operations in .github/workflows/build-redis-3.0.yml:"
awk '/jobs:/,/permissions:/' .github/workflows/build-redis-3.0.yml

Length of output: 548



Script:

#!/bin/bash
# Extract the detailed steps within the build job in the Redis 3.0 workflow

# Display the detailed steps of the build job
echo "Detailed steps in the build job of .github/workflows/build-redis-3.0.yml:"
awk '/jobs:/,/permissions:/ {flag=1; next} /permissions:/ {flag=0} flag {print}' .github/workflows/build-redis-3.0.yml

Length of output: 1505

.github/workflows/build-redis-3.2.yml (2)

34-37: Assess permissions for Redis 3.2 workflow.

Ensure that the permissions contents: write, id-token: write, and attestations: write are justified and minimal for the operations in the Redis 3.2 workflow.

Verification successful

Permissions for Redis 3.2 workflow are justified.

The specified permissions (contents: write, id-token: write, and attestations: write) are appropriate and necessary for the operations performed in the Redis 3.2 workflow.

  • contents: write: Required for checking out the repository and uploading build artifacts.
  • id-token: write: Likely required by the actions/attest-build-provenance step.
  • attestations: write: Necessary for the attestation step.
Scripts executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify the necessity and scope of the permissions for Redis 3.2.

# Test: Review the specific needs of Redis 3.2 in the workflow against the GitHub Actions permissions documentation.
echo "Assess permissions for Redis 3.2 against GitHub Actions documentation."

Length of output: 150



Script:

#!/bin/bash
# Extract and display the steps of the Redis 3.2 workflow to understand the necessity of the specified permissions.

# Display the steps in the workflow file
yq e '.jobs.build.steps' .github/workflows/build-redis-3.2.yml

Length of output: 132



Script:

#!/bin/bash
# Extract and display the steps of the Redis 3.2 workflow to understand the necessity of the specified permissions.

# Use sed to extract the steps section from the workflow file
sed -n '/jobs:/,/steps:/p' .github/workflows/build-redis-3.2.yml | sed -n '/steps:/,$p'

Length of output: 98



Script:

#!/bin/bash
# Extract and display the steps of the Redis 3.2 workflow to understand the necessity of the specified permissions.

# Use sed to extract the steps section from the workflow file, including the lines after 'steps:'
sed -n '/steps:/,$p' .github/workflows/build-redis-3.2.yml

Length of output: 1218


67-69: Check attestation configuration for Redis 3.2.

The attestation step configuration for Redis 3.2 should be verified to ensure that the subject-path accurately targets the artifacts produced.

Verification successful

Check attestation configuration for Redis 3.2.

The attestation step configuration for Redis 3.2 appears to be correctly set up to target the artifacts produced. The subject-path accurately references the temporary directory and matches the artifact naming pattern.

  • The subject-path is set to ${{ runner.temp }}/*.tar.zstd.
  • The artifacts are moved and uploaded using the same temporary directory and naming convention.
Scripts executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify the attestation step configuration for Redis 3.2.

# Test: Check the artifacts for Redis 3.2 in the runner's temporary directory to ensure they match the specified `subject-path`.
echo "Confirm attestation path for Redis 3.2 matches with '*.tar.zstd' files in ${RUNNER_TEMP}"

Length of output: 164



Script:

#!/bin/bash
# Description: Verify the attestation step configuration for Redis 3.2.

# Test: List the artifacts in the runner's temporary directory and check if they match the specified `subject-path`.
echo "Listing files in the runner's temporary directory:"
ls "${RUNNER_TEMP}"

echo "Checking for files matching '*.tar.zstd' in the runner's temporary directory:"
find "${RUNNER_TEMP}" -name '*.tar.zstd'

Length of output: 408



Script:

#!/bin/bash
# Description: Verify the attestation step configuration for Redis 3.2.

# Test: Ensure the temporary directory environment variable is set correctly.
if [ -z "${RUNNER_TEMP}" ]; then
  echo "RUNNER_TEMP environment variable is not set."
  exit 1
fi

# List the artifacts in the runner's temporary directory and check if they match the specified `subject-path`.
echo "Listing files in the runner's temporary directory:"
ls "${RUNNER_TEMP}"

echo "Checking for files matching '*.tar.zstd' in the runner's temporary directory:"
find "${RUNNER_TEMP}" -name '*.tar.zstd'

Length of output: 123



Script:

#!/bin/bash
# Description: Search the workflow file for references to the temporary directory.

# Locate the workflow file
workflow_file=$(fd build-redis-3.2.yml)

# Check if the workflow file exists
if [ -z "$workflow_file" ]; then
  echo "Workflow file not found."
  exit 1
fi

# Search for references to the temporary directory in the workflow file
echo "Searching for references to the temporary directory in the workflow file:"
grep -E 'RUNNER_TEMP|temp' "$workflow_file"

Length of output: 126



Script:

#!/bin/bash
# Description: List all YAML files in the .github/workflows directory to locate the correct workflow file.

# List all YAML files in the .github/workflows directory
echo "Listing all YAML files in the .github/workflows directory:"
fd .yml .github/workflows

# Check if the build-redis-3.2.yml file exists
if fd build-redis-3.2.yml .github/workflows; then
  echo "build-redis-3.2.yml file found."
else
  echo "build-redis-3.2.yml file not found."
  exit 1
fi

Length of output: 815



Script:

#!/bin/bash
# Description: Search the build-redis-3.2.yml workflow file for references to the temporary directory and artifact paths.

# Search for references to the temporary directory and artifact paths in the build-redis-3.2.yml file
echo "Searching for references to the temporary directory and artifact paths in the build-redis-3.2.yml file:"
grep -E 'RUNNER_TEMP|temp|artifact|subject-path' .github/workflows/build-redis-3.2.yml

Length of output: 597

.github/workflows/build-redis-4.0.yml (2)

35-38: Permissions set for attesting build provenance are appropriate.

The permissions contents: write, id-token: write, and attestations: write are essential for the new functionality to attest build provenance. This setup aligns with the security practices necessary for handling build artifacts and credentials.


68-70: New step to attest build provenance added correctly.

The use of actions/attest-build-provenance@v1 with the specified subject-path is correctly implemented. It ensures that the build artifacts are properly attested, which enhances the security and traceability of the build process.

.github/workflows/build-redis-5.0.yml (2)

35-38: Permissions set correctly for build provenance.

The permissions necessary for the attestation of build artifacts are correctly configured. This consistency across workflow files maintains a standard security level for all build processes.


68-70: Attest build provenance step correctly implemented.

The addition of the actions/attest-build-provenance@v1 step is consistent with the other workflow files, ensuring that all builds have verifiable provenance.

.github/workflows/build-redis-6.2.yml (2)

35-38: Permissions for attesting build provenance are correctly set.

The permissions contents: write, id-token: write, and attestations: write are essential for the new functionality to attest build provenance. This setup aligns with the security practices necessary for handling build artifacts and credentials.


68-70: Consistent implementation of the attest build provenance step.

The use of actions/attest-build-provenance@v1 with the specified subject-path is correctly implemented across different workflow files. This consistency is key to ensuring the security and traceability of the build process.

.github/workflows/build-redis-7.0.yml (2)

36-39: Permissions set correctly for build provenance.

The permissions necessary for the attestation of build artifacts are correctly configured. This consistency across workflow files maintains a standard security level for all build processes.


69-71: Attest build provenance step implemented correctly.

The addition of the actions/attest-build-provenance@v1 step is consistent with the other workflow files, ensuring that all builds have verifiable provenance.

.github/workflows/build-redis-6.0.yml (2)

41-44: Permissions Set Appropriately for Build Provenance

The permissions contents: write, id-token: write, and attestations: write are essential for the new build provenance step. This setup ensures the workflow has the necessary access to perform its tasks.


74-76: Ensure Correct Path Specification for Build Artifacts

The subject-path specified uses a wildcard pattern to select artifacts. Confirm that all relevant build artifacts are named appropriately and stored at ${{ runner.temp }} to match this pattern effectively.

Would you like assistance in setting up a test step to verify this before deployment?

Verification successful

Verification Successful: Correct Path Specification for Build Artifacts

The subject-path specified in the workflow correctly uses a wildcard pattern to select artifacts. The build artifacts are named appropriately and stored in ${{ runner.temp }} to match this pattern effectively.

  • The mv command ensures that the artifacts are placed in the ${{ runner.temp }} directory with names matching the pattern *.tar.zstd.
Scripts executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify the naming and location of build artifacts

# Test: List files in the temporary directory. Expect: Files matching the '*.tar.zstd' pattern.
ls -l ${{ runner.temp }}/*.tar.zstd

Length of output: 95



Script:

#!/bin/bash
# Search for the usage of `${{ runner.temp }}` within the GitHub Actions workflow files to gather more context.
rg --fixed-strings '${{ runner.temp }}' .github/workflows

Length of output: 980



Script:

#!/bin/bash
# Extract lines from the workflow files that lead up to the `subject-path` usage to gather more context.
rg -C 10 --fixed-strings 'subject-path: ${{ runner.temp }}/*.tar.zstd' .github/workflows

Length of output: 9499

.github/workflows/build-redis-2.8.yml (2)

45-48: Permissions Set Appropriately for Build Provenance

The permissions contents: write, id-token: write, and attestations: write are set correctly to support the build provenance attestation process.


78-80: Check Artifact Path Configuration

The subject-path is set to ${{ runner.temp }}/*.tar.zstd. Ensure that all artifacts follow this naming convention and are stored in the specified directory.

Would you like help in adding a pre-deployment verification step to ensure all artifacts meet the required criteria?

Verification successful

Artifact Path Configuration Verified

The subject-path is correctly set to ${{ runner.temp }}/*.tar.zstd and matches the artifact creation commands found in the repository.

  • build-redis-with-openssl3.sh
  • build-redis-with-openssl1.1.sh
  • build-redis.sh

These scripts create .tar.zstd files in the $RUNNER_TEMP directory, confirming the correct configuration.

Scripts executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify the naming and storage location of artifacts

# Test: List files in the specified temporary directory. Expect: Files matching the '*.tar.zstd' pattern.
ls -l ${{ runner.temp }}/*.tar.zstd

Length of output: 95



Script:

#!/bin/bash
# Search for artifact creation patterns in the repository
rg --glob '**/*.yml' 'tar.*\.zstd'

Length of output: 36



Script:

#!/bin/bash
# Search for tar commands in the repository
rg 'tar' --glob '**/*.yml'

Length of output: 112



Script:

#!/bin/bash
# Search for actions/upload-artifact steps in the repository
rg 'actions/upload-artifact' --glob '**/*.yml'

Length of output: 46



Script:

#!/bin/bash
# Search for tar commands across all files in the repository
rg 'tar'

Length of output: 16239

@shogo82148 shogo82148 merged commit 93d240f into main Jul 2, 2024
449 checks passed
@shogo82148 shogo82148 deleted the attest-build-provenance branch July 2, 2024 12:14
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.

1 participant