Fedora 安全更新与公告

This content is not available in your language yet.

Fedora 的更新与公告分成两套入口：一套跟着版本走（Release Notes），一套跟着仓库走（更新到底从哪里来）。本页把这两套入口串成一条可执行的流程，并说明第三方软件来源在合规场景下该怎么记账；版本状态见Fedora 当前版本表。

公告与更新渠道

官方 Release Notes 入口分两条：F43 的 Release Notes 是带版本号的历史入口，另有指向最新版的 latest 入口（本轮核对时该页顶部提示已有更新版本的文档，并给出 View Latest Release Notes）。

对运维来说，这两条入口对应两种任务：

把 Release Notes 当变更评审的输入：在升级前读，而不是升级后补课。
稳定版用户跟 latest 入口；要回查某个历史版本的变更，再用带版本号的那条入口。
官方入口之外的信息只当线索：论坛与博客能帮你定位问题，但结论要回到 Release Notes 与官方文档。

更新节奏特征

官方把升级前置写成三件事：备份数据、先读目标版本的 Release Notes、保证当前系统已完全更新；这三项在 F43 到 F44 这类版本间升级里同样适用。

三件事都不难，难的是把它们排进流程：

顺序不能换：先备份、再读 Release Notes、最后把当前系统补到最新。
日常更新与版本升级是两件事：前者在版本线内滚动，后者换的是版本线本身，风险量级不同。
别把待装的更新留到升级时一起处理：官方对「先更新到最新」这一步的措辞是 really important, please do not skip this step。

测试仓库的使用

测试用途的仓库只在需要验证某个更新时打开，验证完就关掉或移除。官方 Quick Docs 给出的仓库操作集中在 dnf config-manager 上：添加、启用、停用与移除都有对应写法。

把这条机制用在工作流里，只需要守住三条：

先确认仓库 ID：仓库 ID 与 .repo 文件名不一定一致，一个文件里可能有多个 ID，动手前先查清归属。
临时启用要有出口：验证完立刻停用，别让测试用途的来源长期留在启用状态。
移除就删干净：删掉对应的 .repo 文件，不要用注释留下半个配置。

完整的命令写法与两代包管理器的差异，见Fedora 仓库与 dnf5与迁移到 dnf5 的实操差异。

合规场景注意

官方 Quick Docs 把第三方软件单列为 Third Party Software 小节，其下包含启用 RPM Fusion 仓库、Flathub、Snap Store、AppImage 与从源码安装等条目；RPM Fusion 自己的配置页给出安装方式。配置页按版本线分别给出入口：F43、F44、Branched 与 Rawhide 各有一条。

第三方来源不是「不能用」，而是「要记账」。最低限度做到四条：

把来源清单化：来源、启用方式、负责人、上次复核时间，四项就够。
区分两类来源的更新责任：官方仓库里的包与第三方来源的包，审计口径要分开。
服务器与桌面分开定策略：桌面场景更依赖第三方分发渠道，服务器场景优先考虑可追溯性。
审计先回答一个问题：这台机器上有没有绕过官方仓库装进来的软件。