Skip to content

fix: use repo visibility for actions_get and get_job_logs secrecy#2463

Merged
lpcox merged 1 commit intomainfrom
fix/secrecy-public-repos
Mar 24, 2026
Merged

fix: use repo visibility for actions_get and get_job_logs secrecy#2463
lpcox merged 1 commit intomainfrom
fix/secrecy-public-repos

Conversation

@lpcox
Copy link
Copy Markdown
Collaborator

@lpcox lpcox commented Mar 24, 2026

Summary

actions_get (artifact downloads) and get_job_logs were unconditionally labeled with [secret] secrecy in the Rust guard. This blocked the audit workflow from reading firewall-audit-logs and job logs for public repos like github/gh-aw.

Changes

guards/github-guard/rust-guard/src/labels/tool_rules.rs

  • actions_get: Removed the special-case that upgraded artifact downloads to secret_label(). Now uses apply_repo_visibility_secrecy() consistently for all actions_get/actions_list operations.
  • get_job_logs: Changed from unconditional secret_label() to apply_repo_visibility_secrecy().

Both tools now follow the same pattern as other repo-scoped resources:

Repo visibility Secrecy label
Public [] (empty — no restriction)
Private [private:owner/repo]
Unknown (runtime) [private:owner/repo] (fail-secure)

guards/github-guard/rust-guard/src/labels/mod.rs

  • Updated test_apply_tool_labels_get_job_logs assertion to match new behavior.

Motivation

The integrity filtering audit workflow (issue #2457) runs against the public github/gh-aw repo. When it tried to download firewall-audit-logs artifacts or read job logs, DIFC blocked access because the agent had no [secret] clearance — and there's no mechanism to grant it. Since the repo is public, these resources should have empty secrecy labels, just like other public repo data.

Fixes #2457

Previously, artifact downloads (actions_get with download_workflow_run_artifact)
and job logs (get_job_logs) were unconditionally labeled with [secret] secrecy.
This blocked the audit workflow from reading firewall-audit-logs and job logs
for public repos like github/gh-aw.

Fix: use apply_repo_visibility_secrecy() for both tools, matching the pattern
used by other repo-scoped resources. Public repos get empty secrecy labels,
private repos get private:owner/repo scope labels.

Fixes #2457

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings March 24, 2026 19:04
@lpcox lpcox merged commit f899c74 into main Mar 24, 2026
17 checks passed
@lpcox lpcox deleted the fix/secrecy-public-repos branch March 24, 2026 19:07
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR updates the Rust guard’s DIFC secrecy labeling for GitHub Actions artifact downloads (actions_get) and workflow run logs (get_job_logs) so they inherit secrecy from repository visibility (public => no secrecy labels; private/unknown => private-scoped labels). This unblocks audit workflows from reading artifacts/logs in public repos (e.g., github/gh-aw).

Changes:

  • actions_get / actions_list: remove the method-specific escalation to secret_label() for artifact downloads; use apply_repo_visibility_secrecy() consistently.
  • get_job_logs: switch from unconditional secret_label() to apply_repo_visibility_secrecy().
  • Update the get_job_logs unit test assertion to match the new behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
guards/github-guard/rust-guard/src/labels/tool_rules.rs Adjusts labeling rules for Actions artifact/log resources to follow repo visibility-based secrecy.
guards/github-guard/rust-guard/src/labels/mod.rs Updates the get_job_logs test to assert the new visibility-inherited secrecy behavior.
Comments suppressed due to low confidence (4)

guards/github-guard/rust-guard/src/labels/tool_rules.rs:452

  • apply_tool_labels already calls backend::is_repo_private(&owner, &repo) to populate repo_private before the match, and apply_repo_visibility_secrecy() calls is_repo_private() again. With this change, get_job_logs now triggers a second visibility lookup (even if it hits the cache), which is a small but unnecessary per-call overhead. Consider reusing the already-computed repo_private (or refactoring apply_repo_visibility_secrecy to accept it) to avoid the duplicate backend call.
        "get_job_logs" => {
            // S = inherits from repo visibility (public repo logs are public)
            // I = approved — CI output is system-generated, not user-controlled
            secrecy = apply_repo_visibility_secrecy(&owner, &repo, repo_id, secrecy, ctx);
            integrity = writer_integrity(repo_id, ctx);

guards/github-guard/rust-guard/src/labels/tool_rules.rs:452

  • SECRECY_TAG_SPEC.md currently documents get_job_logs as secret for both public and private repos, but this PR changes it to inherit repo visibility. Please update the spec (and any other docs referencing job logs secrecy) so the documentation matches the new policy.
        "get_job_logs" => {
            // S = inherits from repo visibility (public repo logs are public)
            // I = approved — CI output is system-generated, not user-controlled
            secrecy = apply_repo_visibility_secrecy(&owner, &repo, repo_id, secrecy, ctx);
            integrity = writer_integrity(repo_id, ctx);

guards/github-guard/rust-guard/src/labels/tool_rules.rs:320

  • The new comment for the actions_get/actions_list arm is workflow/artifact-specific, but this match arm also covers other Actions methods (e.g., secrets/variables/caches per proxy routing). Consider broadening the wording (or splitting by method) so the comment accurately describes the full surface area handled here.
            // S(workflow/artifact) = inherits from repo visibility
            // Public repos: artifacts are public. Private repos: artifacts are private-scoped.
            // I(workflow/artifact) = approved - maintained by repo team

guards/github-guard/rust-guard/src/labels/tool_rules.rs:323

  • This change removes the only method-specific secrecy logic for actions_get (download_workflow_run_artifact). There currently isn’t a unit test covering apply_tool_labels("actions_get", {method: "download_workflow_run_artifact", ...}) to prevent accidentally reintroducing secret_label() or other method-specific behavior later. Please add a focused test for this method under the labels tests.
        "actions_get" | "actions_list" => {
            // S(workflow/artifact) = inherits from repo visibility
            // Public repos: artifacts are public. Private repos: artifacts are private-scoped.
            // I(workflow/artifact) = approved - maintained by repo team
            secrecy = apply_repo_visibility_secrecy(&owner, &repo, repo_id, secrecy, ctx);
            integrity = writer_integrity(repo_id, ctx);
        }

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines 317 to 322
"actions_get" | "actions_list" => {
// S(workflow/artifact) = inherits from repo secrecy
// S(workflow/artifact) = inherits from repo visibility
// Public repos: artifacts are public. Private repos: artifacts are private-scoped.
// I(workflow/artifact) = approved - maintained by repo team
secrecy = apply_repo_visibility_secrecy(&owner, &repo, repo_id, secrecy, ctx);
integrity = writer_integrity(repo_id, ctx);
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

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

SECRECY_TAG_SPEC.md still documents artifact downloads (actions_get with download_workflow_run_artifact) as secret for both public and private repos, but this PR changes actions_get/actions_list to inherit repo visibility. Please update the spec so the documented labeling rules match the implementation.

This issue also appears in the following locations of the same file:

  • line 317
  • line 318
  • line 448
  • line 448

Copilot uses AI. Check for mistakes.
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.

[integrity-audit] Integrity Filtering Audit — github/gh-aw (2026-03-24)

2 participants