chore:: Update CLA check workflow to inherit secrets

[hudeng-go]

Summary by Sourcery

Build:

• Change CLA check workflow configuration to use secrets: inherit when calling the shared cla-check workflow.

[deepin-ci-robot]

deepin pr auto review

这段代码是 GitHub Actions 的工作流配置文件，具体是关于调用可复用工作流的部分。以下是对该 diff 的详细审查和改进意见：

1. 语法逻辑审查

• 当前状态：修改前显式地传递了 APP_PRIVATE_KEY 密钥，修改后使用了 secrets: inherit。
• 逻辑分析：
  • secrets: inherit 是 GitHub Actions 提供的一个便捷功能，它允许调用者工作流将当前上下文中所有的 Secrets 自动传递给被调用的可复用工作流。
  • 修改后的逻辑是合法的，前提是被调用的工作流（即 linuxdeepin/.github/.github/workflows/cla-check.yml）中声明的 secrets 输入名称与当前工作流中拥有的 Secrets 名称完全一致。
  • 潜在风险：如果被调用的工作流只需要 APP_PRIVATE_KEY，而当前工作流中还包含其他敏感信息（如数据库密码、API Token），使用 inherit 会将所有 Secrets 传递过去。这可能导致敏感信息泄露给不应该拥有这些权限的工作流或维护者（特别是当被调用的工作流位于外部仓库时）。

2. 代码质量审查

• 可读性与维护性：使用 secrets: inherit 简化了配置文件，减少了样板代码，使得工作流文件更简洁。如果后续被调用的工作流需要增加新的 Secret 参数，调用方无需修改代码，这在一定程度上提高了维护效率。
• 明确性：显式传递 APP_PRIVATE_KEY 虽然代码稍多，但具有更高的"显式性"。阅读代码的人可以一眼看出该工作流仅传递了这一个特定的密钥，明确了最小权限原则。

3. 代码安全审查（重点）

• 最小权限原则：这是安全审查中最关键的一点。
  • 显式传递（修改前）：严格遵守了最小权限原则。只传递了 APP_PRIVATE_KEY，即使当前环境有其他 Secrets，也不会泄露给被调用的工作流。
  • 继承传递（修改后）：打破了最小权限原则。它将调用者仓库的所有 Secrets 都传递给了被调用的工作流。
• 供应链安全：由于被调用的工作流位于 linuxdeepin/.github 仓库（看起来是一个组织级的共享仓库），如果该仓库被攻破，或者该工作流文件被恶意修改，攻击者将能够获取到调用者仓库的所有 Secrets，而不仅仅是 APP_PRIVATE_KEY。
• 建议：
  • 如果 linuxdeepin/.github 是完全受信任的内部仓库，且该工作流确实需要访问多个 Secrets，那么 inherit 是可以接受的，但需确保该仓库的权限控制严格。
  • 如果该工作流仅用于 CLA（Contributor License Agreement）检查，通常只需要一个私钥。在这种情况下，显式传递更安全。

4. 代码性能审查

• GitHub Actions 的 secrets: inherit 和显式传递在运行时性能上几乎没有区别。Secrets 的传递机制在底层是类似的，不会显著影响工作流的执行速度或资源消耗。

总结与改进建议

这段修改将代码从"显式传递特定密钥"改为"继承所有密钥"。

改进意见：

1. 推荐回退到显式传递（如果可能）：
   出于安全考虑，建议回退到修改前的写法，除非有明确的理由需要传递多个 Secrets。

   jobs:
     clacheck:
       uses: linuxdeepin/.github/.github/workflows/cla-check.yml@master
       secrets:
         APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}

2. 如果必须使用 inherit，请确保上下文安全：
   如果您确定要使用 secrets: inherit，请务必确认以下两点：

   • 被调用的 cla-check.yml 工作流是否真的需要访问当前仓库的所有 Secrets？
   • linuxdeepin/.github 仓库的安全性是否足够高？（例如，是否启用了分支保护、是否只有核心管理员可以修改工作流文件）。

3. 中间方案（推荐）：
   如果被调用的工作流需要多个密钥，但又不想传递所有密钥，可以在 secrets 块中列出所有需要的密钥，而不是使用 inherit。这样既保持了简洁性（相比复杂的逻辑），又保证了安全性。

结论：虽然修改后的代码语法正确且更简洁，但从安全角度来看，它增加了敏感信息泄露的风险。建议评估被调用工作流的实际需求，如果仅需 APP_PRIVATE_KEY，请不要使用 secrets: inherit。

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Updates the CLA check reusable workflow invocation to use GitHub Actions' secrets: inherit mechanism instead of manually mapping a single secret, allowing it to automatically inherit all appropriate secrets from the caller workflow.

Sequence diagram for CLA check workflow using secrets inherit

sequenceDiagram
  participant CallerWorkflow
  participant GitHubActions
  participant SecretsStore
  participant ReusableWorkflow

  CallerWorkflow->>GitHubActions: Trigger workflow run
  GitHubActions->>SecretsStore: Resolve secrets for caller workflow
  SecretsStore-->>GitHubActions: Return eligible secrets
  GitHubActions->>ReusableWorkflow: Invoke cla-check.yml with secrets inherit
  GitHubActions->>ReusableWorkflow: Provide all inherited secrets

Loading

File-Level Changes

Change	Details	Files
Switch CLA check workflow secrets configuration to use GitHub Actions secrets: inherit.	Remove explicit mapping of APP_PRIVATE_KEY secret in the reusable workflow call Configure the clacheck job to inherit all permitted secrets from the caller workflow via secrets: inherit	.github/workflows/call-clacheck.yml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path=".github/workflows/call-clacheck.yml" line_range="15" />
<code_context>
     uses: linuxdeepin/.github/.github/workflows/cla-check.yml@master
-    secrets:
-      APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}
+    secrets: inherit
</code_context>
<issue_to_address>
**🚨 issue (security):** Using `secrets: inherit` may overexpose secrets compared to the previous least-privilege setup.

The previous version exposed only `APP_PRIVATE_KEY`, while `secrets: inherit` makes all repo/org secrets available to the called workflow. If that workflow only needs `APP_PRIVATE_KEY`, prefer an explicit mapping (updated to the new `secrets` syntax if required) to minimize exposure should the downstream workflow change or be compromised.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

🚨 issue (security): Using secrets: inherit may overexpose secrets compared to the previous least-privilege setup.

The previous version exposed only APP_PRIVATE_KEY, while secrets: inherit makes all repo/org secrets available to the called workflow. If that workflow only needs APP_PRIVATE_KEY, prefer an explicit mapping (updated to the new secrets syntax if required) to minimize exposure should the downstream workflow change or be compromised.

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: hudeng-go, max-lvs

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment