Delete .github/workflows/call-synchronize-to-dtk6.yml

[asterwyx]

No description provided.

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: asterwyx

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

[deepin-ci-robot]

deepin pr auto review

这段代码展示的是一个被删除的 GitHub Actions 工作流文件 call-synchronize-to-dtk6.yml。以下是对该工作流配置的审查意见，主要关注其安全性、逻辑和设计：

1. 安全性审查

严重风险：pull_request_target 触发器

• 问题：该工作流使用了 pull_request_target 事件。这个事件的关键特性是它会在**基础分支（通常是 master/main）**的上下文中运行，并且拥有基础分支的权限（包括 secrets: inherit 继承的仓库密钥），而不是 PR 提交者的上下文。
• 风险：工作流中使用了 secrets: inherit，这意味着它继承了仓库的所有敏感信息（如 Token、密码等）。虽然该工作流调用了外部仓库 linuxdeepin/dtk 的复用工作流，但通过 with 传递的参数（特别是 source_ref）来自 PR 的提交者。
  • 如果被调用的 linuxdeepin/dtk/.github/workflows/synchronize-to-dtk6.yml@master 工作流内部逻辑不严谨（例如，直接 git checkout 传入的 source_ref 并执行代码），攻击者可以通过提交恶意 PR 来窃取仓库的 Secrets，或者在目标仓库上执行恶意操作。
• 建议：
  • 检查被调用方逻辑：必须确保 linuxdeepin/dtk 仓库中的 synchronize-to-dtk6.yml 工作流具有严格的安全检查。例如，它必须先检出基础仓库代码，然后再以只读或受控的方式处理传入的 source_ref，绝不能盲目地检出并运行来自未验证 PR 分支的代码。
  • 权限最小化：如果不需要写入权限，尽量限制 GITHUB_TOKEN 的权限。如果使用了自定义的 Secret，确保只有必要的 Secret 被传递。
  • 替代方案：如果可能，考虑使用 pull_request 事件。虽然 pull_request 默认没有对 fork 仓库的写权限和 Secrets 访问权限，但它更安全。如果必须使用 pull_request_target，必须配合严格的代码审查和硬编码的引用检查（如只允许特定仓库的 PR）。

2. 逻辑审查

• 路径过滤逻辑 (paths-ignore)：

  • 配置忽略了 debian, archlinux, rpm, .obs, .github 目录的变更。
  • 逻辑：这看起来是为了避免打包文件或 CI 配置文件的变更触发同步逻辑，这是合理的。
  • 潜在问题：如果代码的核心逻辑变更分散在多个目录中，或者有新的目录加入，可能需要更新此列表。

• 复用工作流 (uses)：

  • 使用了 uses: linuxdeepin/dtk/...@master。
  • 建议：引用工作流时最好使用具体的 commit hash 或 tag（如 @v1.0.0），而不是 @master。如果 master 分支上的工作流发生了破坏性变更或被恶意修改，所有依赖它的仓库都会受到影响。

3. 代码质量与规范

• 命名规范：工作流名称 Call synchronize to dtk6 和 Job 名称 call-synchronize 清晰易懂。
• 参数传递：使用 with 传递 dest_repo, source_repo 等参数，结构清晰，符合 GitHub Actions 的最佳实践。

4. 性能

• 该工作流本身只是一个调用器，主要性能消耗在被调用的 linuxdeepin/dtk 工作流中。
• 由于使用了 paths-ignore，可以有效减少不必要的 CI 运行，从而节省资源和时间。

总结与改进建议

该文件已被删除，这通常意味着该同步逻辑已被废弃或重构。如果这是为了修复安全漏洞而删除的，那么是正确的决定。如果需要保留类似功能，建议进行以下改进：

1. 安全性加固：
   • 如果必须保留此功能，请务必审查 linuxdeepin/dtk 仓库中被调用工作流的安全性，防止通过 source_ref 注入恶意代码。
   • 考虑移除 secrets: inherit，除非绝对必要，并明确传递哪些特定的 secret。
2. 引用稳定性：
   • 将 @master 改为具体的版本号（Tag 或 Commit SHA）。
3. 触发条件：
   • 确认是否真的需要 pull_request_target，能否用更安全的 pull_request 替代。

改进后的代码示例（仅供参考，需根据实际被调用工作流的安全机制调整）：

name: Call synchronize to dtk6
on:
  pull_request_target:
    paths-ignore:
      - "debian/**"
      - "archlinux/**"
      - "rpm/**"
      - ".obs/**"
      - ".github/**"
    # 建议添加检查，只允许特定仓库的 PR 触发，防止来自任意 Fork 的恶意 PR
    types: [opened, synchronize, reopened]

permissions:
  contents: read # 仅赋予读取权限，除非被调用工作流明确需要写权限

jobs:
  call-synchronize:
    uses: linuxdeepin/dtk/.github/workflows/synchronize-to-dtk6.yml@v1.0.0 # 使用固定版本
    secrets: inherit # 或者使用: secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }
    with:
      dest_repo: linuxdeepin/dtk6widget
      source_repo: ${{ github.event.pull_request.head.repo.full_name }}
      source_ref: ${{ github.event.pull_request.head.ref }}
      pull_number: ${{ github.event.pull_request.number }}

[zccrs]

同步到gitee的这个失败了不影响这个提交，这个改动是github action的变化，本次未同步过去不要紧，直接合入了。