Pr0128

[wangrong1069]

Summary by Sourcery

Enable build hardening for release builds and bump application packaging versions across architectures.

Build:

• Enable compiler and linker hardening flags for Release builds in CMake configuration.

Deployment:

• Update linglong package version to 6.5.35.1 for all supported architectures.

[github-actions]

TAG Bot

TAG: 6.5.35
EXISTED: no
DISTRIBUTION: unstable

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Adds compiler and linker hardening flags for Release builds and bumps the application/package version across multiple linglong manifests, with an associated Debian changelog update stub.

Flow diagram for Release build hardening configuration

flowchart TD
    A[CMake_configure] --> B{CMAKE_BUILD_TYPE}
    B -->|Release| C[Print_Enable_build_hardening]
    B -->|Other| D[Use_default_flags]

    C --> E[Set_HARDENING_FLAGS]
    E --> F[Append_HARDENING_FLAGS_to_CMAKE_CXX_FLAGS]
    E --> G[Append_HARDENING_FLAGS_to_CMAKE_C_FLAGS]
    E --> H[Append_linker_hardening_flags_to_CMAKE_EXE_LINKER_FLAGS]

    D --> I[Continue_configuration]
    F --> I
    G --> I
    H --> I

Loading

File-Level Changes

Change	Details	Files
Introduce build hardening flags for Release configuration in the CMake build.	Guard hardening configuration with a CMAKE_BUILD_TYPE STREQUAL "Release" check Define a HARDENING_FLAGS variable including FORTIFY, stack protector, stack clash protection, format security, and control-flow protection options Append HARDENING_FLAGS to existing C and C++ compiler flags Augment executable linker flags with RELRO and immediate binding options	CMakeLists.txt
Bump application/package version from 6.5.34.1 to 6.5.35.1 across architectures.	Update version field in root linglong.yaml manifest Update version field in architecture-specific linglong.yaml manifests for arm64, loong64, mips64, and sw64	linglong.yaml arm64/linglong.yaml loong64/linglong.yaml mips64/linglong.yaml sw64/linglong.yaml
Prepare Debian changelog for a new release corresponding to the version bump.	Add or modify the latest entry in debian/changelog to reflect the new release (exact diff not shown)	debian/changelog

---

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 left some high level feedback:

• The hardening flags are appended directly to CMAKE_C_FLAGS/CMAKE_CXX_FLAGS for the generic Release build type; consider using CMAKE_*_FLAGS_RELEASE or target_compile_options/target_link_options so that configuration-specific flags are applied more explicitly and don’t interfere with other build types like RelWithDebInfo.
• You’re adding -g and -O2 in the HARDENING_FLAGS for Release; it might be clearer to keep optimization/debug flags in the standard CMake configuration (e.g., CMAKE_*_FLAGS_RELEASE) and limit HARDENING_FLAGS to security-related flags only to avoid duplication or conflicting toolchain settings.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The hardening flags are appended directly to CMAKE_C_FLAGS/CMAKE_CXX_FLAGS for the generic Release build type; consider using CMAKE_*_FLAGS_RELEASE or target_compile_options/target_link_options so that configuration-specific flags are applied more explicitly and don’t interfere with other build types like RelWithDebInfo.
- You’re adding -g and -O2 in the HARDENING_FLAGS for Release; it might be clearer to keep optimization/debug flags in the standard CMake configuration (e.g., CMAKE_*_FLAGS_RELEASE) and limit HARDENING_FLAGS to security-related flags only to avoid duplication or conflicting toolchain settings.

---

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.}

[deepin-ci-robot]

deepin pr auto review

这段代码在 CMake 构建配置中引入了编译器加固选项，这是一个很好的安全实践。以下是对这段代码的详细审查，包括语法逻辑、代码质量、性能和安全方面的改进建议：

1. 语法逻辑与代码质量

优点：

• 条件判断正确：使用 if(CMAKE_BUILD_TYPE STREQUAL "Release") 确保加固选项仅在发布版本中启用，避免在 Debug 模式下引入不必要的复杂性（例如 -O2 会覆盖 Debug 默认的 -O0 或 -g）。
• 变量作用域：使用了 set 命令设置变量，逻辑清晰。

改进建议：

1. 使用 message(STATUS ...) 代替 message(...)

   • 原因：message(...) 默认输出类型为 STATUS，但为了代码可读性和符合 CMake 最佳实践，显式指定 STATUS 更好。这可以区分普通状态信息和严重的错误或警告信息。
   • 修改：

     message(STATUS "Enable build hardening.")

2. 检查编译器兼容性

   • 原因：代码直接添加了 GCC/Clang 风格的标志（如 -fstack-protector-strong）。如果用户使用 MSVC (Visual Studio) 编译，这些标志会导致构建失败。
   • 修改：增加编译器类型检查。

     if(CMAKE_BUILD_TYPE STREQUAL "Release")
         if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
             message(STATUS "Enable build hardening for GCC/Clang.")
             # ... 原有的 set 命令 ...
         elseif(MSVC)
             message(STATUS "Enable build hardening for MSVC.")
             # 添加 MSVC 对应的安全标志，如 /GS, /sdl 等
         endif()
     endif()

3. 使用 list(APPEND ...) 代替字符串拼接

   • 原因：虽然字符串拼接 ${CMAKE_CXX_FLAGS} ${HARDENING_FLAGS} 在 CMake 中很常见，但使用 list(APPEND CMAKE_CXX_FLAGS ...) 在语义上更准确，因为编译器标志本质上是一个列表。
   • 修改：

     list(APPEND CMAKE_CXX_FLAGS ${HARDENING_FLAGS})
     list(APPEND CMAKE_C_FLAGS ${HARDENING_FLAGS})
     list(APPEND CMAKE_EXE_LINKER_FLAGS "-Wl,-z,relro" "-Wl,-z,now")

2. 代码性能

• 优化级别冲突：
  • 问题：HARDENING_FLAGS 中包含了 -O2。在 CMake 中，CMAKE_CXX_FLAGS_RELEASE 默认通常包含 -O3 -DNDEBUG。直接追加 -O2 可能会导致优化级别被覆盖或产生冲突（取决于命令顺序和编译器行为，通常后面的参数生效，但显式指定更安全）。
  • 建议：不要在通用标志中硬编码 -O2。CMake 变量 CMAKE_CXX_FLAGS_RELEASE 专门用于 Release 模式的标志。
  • 修改：从 HARDENING_FLAGS 中移除 -O2 和 -g（调试符号通常也由 CMake 默认管理），让 CMake 处理优化级别。

    # 移除 -O2 和 -g，仅保留安全相关的标志
    set(HARDENING_FLAGS "-Wdate-time -D_FORTIFY_SOURCE=2 -ffile-prefix-map=${CMAKE_SOURCE_DIR}=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security")

3. 代码安全

优点：

• 标志选择优秀：引入的标志涵盖了多个安全方面：
  • -fstack-protector-strong：栈溢出保护。
  • -D_FORTIFY_SOURCE=2：缓冲区溢出检查。
  • -Wformat -Werror=format-security：防止格式化字符串漏洞。
  • -Wl,-z,relro -Wl,-z,now：链接时重定位只读和保护，防止 GOT 覆盖攻击。

改进建议：

1. 位置无关可执行文件 (PIE)

   • 原因：现代 Linux 系统通常需要 ASLR (地址空间布局随机化) 支持。虽然较新的 GCC 默认可能开启，但显式开启 -fPIE (编译) 和 -pie (链接) 是更安全的做法。
   • 修改：

     set(CMAKE_POSITION_INDEPENDENT_CODE ON) # 编译选项 -fPIE
     # 链接选项通常较新系统默认开启，若需显式控制可添加到 CMAKE_EXE_LINKER_FLAGS

2. 关于 -ffile-prefix-map

   • 注意：这个选项主要用于构建可重现性，防止绝对路径泄露在二进制文件中。这是一个很好的安全特性，但要注意 ${CMAKE_SOURCE_DIR} 路径中如果包含特殊字符或空格，可能会导致编译错误。目前的写法是安全的，但值得留意。

3. Fortify Source 依赖性

   • 注意：_FORTIFY_SOURCE=2 需要配合优化级别 (-O1 或更高) 才能生效。由于前面建议移除硬编码的 -O2，你需要确保 CMAKE_CXX_FLAGS_RELEASE 或 CMAKE_C_FLAGS_RELEASE 中确实包含优化选项（通常默认包含 -O3 或 -O2）。

综合改进后的代码示例

if(CMAKE_BUILD_TYPE STREQUAL "Release")
    message(STATUS "Enable build hardening.")

    if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
        # 定义安全标志，移除 -O2 和 -g，由 CMake 变量管理
        set(HARDENING_FLAGS
            "-Wdate-time"
            "-D_FORTIFY_SOURCE=2"
            "-ffile-prefix-map=${CMAKE_SOURCE_DIR}=."
            "-fstack-protector-strong"
            "-fstack-clash-protection"
            "-Wformat"
            "-Werror=format-security"
            "-fPIE" # 显式开启 PIE 编译支持
        )

        # 将标志追加到相应的变量中
        list(APPEND CMAKE_CXX_FLAGS ${HARDENING_FLAGS})
        list(APPEND CMAKE_C_FLAGS ${HARDENING_FLAGS})
        
        # 链接器标志：开启 RELRO (Relocation Read-Only) 和立即绑定
        list(APPEND CMAKE_EXE_LINKER_FLAGS "-Wl,-z,relro" "-Wl,-z,now" "-Wl,-pie")
        
    elseif(MSVC)
        # 如果需要支持 MSVC，在此处添加对应的安全标志
        message(STATUS "MSVC detected, consider adding /GS, /sdl flags.")
    endif()
endif()

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: lzwind, wangrong1069

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

[wangrong1069]

/merge