在企业内网构建RPM软件分发体系时，最容易被忽视却又最致命的一环就是包的完整性校验。如果没有签名机制，任何一个能访问内网仓库的人都可以替换仓库中的RPM包，注入后门或恶意脚本，而下游的成百上千台服务器会毫无防备地安装它们。虽然GPG本地签名可以解决问题，但当团队规模扩大、需要多人协作管理签名时，把私钥放在每个打包者的机器上就成了明显的安全隐患。sigul正是为了解决这个矛盾而设计的签名桥接服务。
sigul是什么，它解决了什么问题
sigul是Fedora项目基础设施中使用的签名服务，核心目标是让RPM包的签名操作与私钥的持有彻底解耦。传统的做法是打包者自己在本地执行rpmsign命令，这要求私钥必须存在于打包者的工作机上。一旦某台机器被入侵或者笔记本丢失，整个软件分发链的信任基础就崩塌了。而sigul采用客户端-服务器架构，私钥永远保存在一台访问受严格限制的签名服务器上，打包者只需要通过客户端工具发起签名请求，服务器完成签名后返回结果。
sigul系统由三个主要角色组成：sigul服务器、sigul桥接器和sigul客户端。服务器是核心，负责管理密钥库和执行实际的签名操作；桥接器作为中间层，通常部署在外网与内网的交界处，负责转发和过滤客户端请求；客户端则是打包者日常使用的命令行工具。这种分层设计的好处是，即使客户端所在的机器被攻破，攻击者也无法直接拿到私钥，只能通过受控的接口发起有限的操作，而且每一次签名请求都会留下审计日志。
认证方面，sigul通常与Kerberos集成，也可以使用TLS客户端证书。在企业内网中如果已经有FreeIPA或Active Directory域环境，直接复用现有的Kerberos基础设施是最自然的做法，不需要为签名系统单独维护一套账号体系。
sigul服务器的安装与初始化
在CentOS或Fedora上安装sigul非常直接，直接通过yum或dnf安装服务端和客户端软件包即可。安装完成后需要进行初始化配置，包括生成服务器的CA证书、桥接器证书和数据库初始化。下面演示一个典型的安装与初始化流程：
# 安装服务端、桥接器与客户端 dnf install sigul-server sigul-bridge sigul-client -y # 初始化服务器，生成配置文件、证书与数据库 sigul-server-setup --all # 启动并设置开机自启 systemctl enable --now sigul-server
初始化完成后，配置文件位于/etc/sigul/server.conf，其中几个关键参数需要关注。[server]段的listen定义服务监听端口，[database]段默认使用SQLite，生产环境建议换成PostgreSQL以获得更好的并发能力。密钥库的安全至关重要，建议将密钥库目录放在单独的分区或加密磁盘上，并通过文件系统权限严格限制只有sigul服务账号可以访问。
桥接器的配置在/etc/sigul/bridge.conf中，它需要知道上游服务器的地址。如果部署结构简单，也可以暂时跳过桥接器让客户端直连服务器，但一旦涉及跨网段或需要给外部协作者提供签名服务，桥接器就成为网络隔离的必要组件。
创建密钥并签名RPM包的完整流程
服务器初始化完成后，第一步是创建管理账号和签名密钥。sigul中的密钥本质上是GPG密钥对，但私钥被导入到sigul自己的加密密钥库中，导出需要多方口令协作，单个人无法完成。创建流程如下：
# 使用管理员身份登录（依赖Kerberos票据或初始管理员证书）
sigul-admin --server-hostname signing.internal.example new-admin alice
# 创建一个新的签名密钥，指定密钥类型和口令
sigul-admin --server-hostname signing.internal.example new-key \
mycompany-el9 --key-admin alice --key-type gnupg
# 为密钥授权使用者
sigul-admin grant-key-access mycompany-el9 bob密钥创建好之后，普通使用者bob就可以对RPM包发起签名请求了。客户端命令会自动处理与桥接器的通信、Kerberos认证以及包文件的传输：
# 对单个RPM包签名
sigul sign-rpm -o mypackage-1.0-1.el9.signed.rpm \
mycompany-el9 mypackage-1.0-1.el9.rpm
# 批量签名一个目录下所有包
sigul sign-rpms -o /repo/signed/ --store-in-o mycompany-el9 /repo/unsigned/*.rpm签名完成后，用rpmsign或rpm -K验证签名是否有效。为了让下游所有机器都能校验，还需要把公钥分发到各节点的/etc/pki/rpm-gpg目录，并在仓库配置中通过gpgkey参数指向公钥URL，同时在/etc/yum.conf或仓库文件中开启gpgcheck=1。只有完成了这一步，签名体系才算真正闭环，否则签名只是摆设。
与本地GPG签名方案的对比及落地建议
对比本地GPG签名，sigul的优势集中在安全和管理两个方面。安全性上，私钥集中管控、无法单点导出，配合Kerberos认证和审计日志，可以满足多数企业的合规审计要求；管理上，密钥轮换、权限回收、多人协作都通过服务端统一完成，不需要在每个打包机上重新导入密钥。代价是部署复杂度：需要维护服务器、桥接器、数据库和证书体系，对小型团队来说可能得不偿失。
实践中有一个常见的折中方案值得参考：如果企业已经使用Koji构建系统，sigul可以直接与Koji集成，构建完成的包通过koji-sigul或Koji的签名任务自动完成签名并写回仓库，全程无需人工干预。如果是自建的打包流水线，也可以在CI阶段通过sigul客户端发起签名请求，把签名凭证集中保护在服务端，流水线本身不接触任何私钥材料。
落地时的几个细节提醒：第一，签名服务器的网络访问要尽可能收紧，只允许桥接器地址访问服务端口；第二，密钥库要定期备份，但要使用离线介质并妥善保管，备份本身也是敏感资产；第三，建议为不同用途（比如测试仓库和生产仓库）创建不同的签名密钥，避免一把钥匙开所有的门。做好这些细节，sigul就能为企业内网的RPM分发提供一条完整且可审计的信任链。