你真的知道你正在运行哪个 PostgreSQL吗？

本文整理自 IvorySQL 2025 生态大会暨 PostgreSQL 高峰论坛的演讲分享，演讲嘉宾：Alvaro Hernandez。

个人简介：

OnGres 创始人&CEO
20年以上Postgres用户及数据库管理员经验
主要从事研发工作，基于Postgr0 es创建创新软件
累计开展140余场技术讲座，多数以Postgres为主题
非营利组织PostgreSQL基金会创始人及主席
AWS Data Hero
个人网站：aht.es

图片1.png

引言

你真的知道自己正在运行的 PostgreSQL 是什么版本吗？即便是官方发布的安装包，其编译者、构建方式和环境都可能影响最终二进制文件的可复现性和安全性。本文将围绕可复现构建、封闭式构建、自举构建，以及 SBOM、数字签名镜像和自动漏洞扫描等实践，探讨如何打造可追溯、可验证且安全的 PostgreSQL 发行版。

实验演示

对不同来源的 PostgreSQL 17.0-1 安装包提取二进制文件并计算 SHA256 摘要值，观察二进制文件的一致性差异。

首先，从官方 APT 仓库的 Debian 安装包提取二进制文件：

$ wget 
https://apt.postgresql.org/pub/repos/apt/pool/main/p/p
ostgresql-17/postgresql-17_17.0-1.pgdg%2B1_amd64.deb
$ ar x postgresql-17_17.0-1.pgdg+1_amd64.deb
$ tar xf data.tar.xz
$ sha256sum usr/lib/postgresql/17/bin/postgres
108a683af350bf496cfc9488f7e9083076004d8f08c48eb07e4085
9bdf75b83c

结果：Debian APT 包生成的二进制文件摘要值以 108 开头。

其次，从官方 RPM/YUM 仓库的安装包提取二进制文件：

$ wget 
https://download.postgresql.org/pub/repos/yum/17/redhat/r
hel-9-x86_64/postgresql17-server-17.0-1PGDG.rhel9.x86_64.
rpm
$ rpm2cpio 
postgresql17-server-17.0-1PGDG.rhel9.x86_64.rpm | cpio 
-idmv
$ sha256sum usr/pgsql-17/bin/postgres
8603bb3d4eb0e0304ddb5693b959fbedba4b6c217031fe116d5bc7385
32a4fe7

结果：RPM/YUM 包生成的二进制文件摘要值以 860 开头，与 Debian 包不同。

最后，从官方 Docker 镜像（基于 Debian APT 包构建）提取二进制文件：

$ git clone https://github.com/docker-library/postgres.git
$ cd postgres/17/bookworm; docker build .
$ git log -1 Dockerfile |grep '^ '
Update 17 to 17.0, bookworm 17.0-1.pgdg120+1, bullseye 
17.0-1.pgdg110+1
$ docker run --rm --name pg -it -e POSTGRES_PASSWORD=e 
f20f9db75912 sha256sum /usr/lib/postgresql/17/bin/postgres
852a27cf85ec935174a0cafd259b3936d7345d780b9991cf45a3be08312b
1652

结果：Docker 镜像生成的二进制文件摘要值以 852 开头，再次不同。

实验结果显示，即便是同一版本的 PostgreSQL，由于来源和构建方式的差异，最终生成的二进制文件存在显著差异。这说明构建环境、打包方式和来源对二进制文件的一致性具有直接影响，为可复现构建和安全性验证提供了技术依据。

源代码展示

二进制文件源自源代码，那么 PostgreSQL 的“真正源代码”究竟是哪一个？

首先，从 PostgreSQL 官方网站下载源代码压缩包，该压缩包中不包含二进制文件，因此无法直接计算二进制摘要，但可以计算源代码压缩包 tar 包的 SHA256 摘要值，计算结果以 bf81 开头：

$ wget 
https://ftp.postgresql.org/pub/source/v17.0/postgresql-17
.0.tar.gz
$ sha256sum postgresql-17.0.tar.gz
bf81c0c5161e456a886ede5f1f4133f43af000637e377156a02e7e835
69081ad

接着，从 PostgreSQL 官方 Git 仓库克隆源代码，并针对相同版本生成压缩包，计算出的 SHA256 摘要值，以 4fdd 开头，与官方网站下载的 tar 包不同：

$ git clone git://git.postgresql.org/git/postgresql.git
$ cd postgresql
$ git archive --format=tar.gz \
 -o ../git-postgresql-17.0.tar.gz REL_17_0
$ sha256sum ../git-postgresql-17.0.tar.gz
4fdd9abf3185ba835e88e71a2dd1f08812567bb1747bf6c9c5b2dfaad
64b7b0b

这种差异是已知问题，主要由不同版本的 tar 命令导致。实际上，源代码内容是一致的，但压缩包生成方式的差异会导致哈希值不同。这说明，即便源代码相同，其压缩包形式在不同构建环境下也可能产生不同的摘要值，从而增加了验证和复现的难度。

Postgres 发行版：面临的挑战

在分析 PostgreSQL 发行版的构建问题时，首先要面对的，是信任与可验证性的问题。模拟一段对话：

“你用的是开源软件吧？”
“对，我用的是开源的。”
“那你为什么用开源？”
“因为如果我用某个系统，随时能回到源代码，知道它在干什么，还能检查、分析。”

理论上，开源软件的价值之一就在于可追溯和可验证。然而在实际应用中，很多人并不清楚自己正在运行的二进制文件究竟来自何处，也无法确认这些文件是否在完全隔离、未被污染的环境中构建生成。换句话说，源代码是开放的，但最终运行的结果未必可验证。

开源软件与供应链安全风险

图片2.png

近期曝光的 XZ Utils 事件是典型的供应链攻击案例。

XZ 是 SSH 及多种系统组件所依赖的压缩库，虽然漏洞并非出现在 PostgreSQL 项目中，但部分 PostgreSQL 部署环境也可能直接或间接依赖该库。攻击者在受影响版本中植入恶意代码，使系统具备远程控制后门。

这一事件说明：即便开源代码本身安全可靠，如果构建或分发环节被污染，最终运行环境仍可能受到攻击。

可复现构建

供应链攻击暴露了一个更底层的问题——如何证明你运行的二进制文件确实来源于可信的源代码？要避免这种无法确认构建来源和安全性的风险，就需要一种系统化的方法——可复现构建（Reproducible Builds）。相关资料可参考https://reproducible-builds.org

可复现构建核心要求是：在不同环境、不同时间、不同架构上编译相同源代码，生成的二进制文件必须逐字节一致。验证方法可通过计算摘要值完成，元数据差异（如编译时间戳）可以忽略，但摘要值一致是最直接的判断标准。

理论上，编译器输入相同输出应一致，但实际情况却不同：只要构建方式或环境存在差异，生成的二进制文件就可能不同，这正是可复现构建要解决的问题。

可重现构建的重要性

没有可复现构建时，存在以下问题：

无法确保二进制文件的生成过程可控，也无法在不同环境中复现相同结果。
开发和测试环境无法使用与生产环境完全一致的二进制文件进行调试。
系统部署流程复杂，缓存利用效率下降，同时二进制文件的数量和管理成本增加。

可复现构建的重要意义在于：确保在开发、测试、生产环境中使用一致的二进制文件，便于性能问题排查和调试；同时提高大规模部署和缓存分发的效率。这也是 Facebook、Google 等大型互联网公司推动可复现构建的核心原因。

封闭式构建

封闭式构建系统会将构建过程与宿主系统的任何变化隔离开来，因此只要源码和配置相同，就能够生成一致的结果。封闭式构建一般能够实现以下效果：

可重现性。
防止环境污染。
能够生成自包含或静态的软件包。

“密封性”（Hermiticity）是封闭式构建的核心概念。理论上，编译相同源码就能得到相同结果，但实际情况往往不同。大多数构建系统都会受到宿主环境的影响：在不同电脑上编译相同软件，结果很可能不同，无法复现。这是因为系统中现有的库、工具甚至配置都会影响最终生成的二进制文件。

为保证构建结果一致，需要使用密封构建系统。密封系统会创建一个隔离环境，类似“沙箱”，在 Linux 上常为容器，在 macOS 上可能是虚拟化沙箱，并将构建所需的所有软件和工具以明确版本控制的方式引入环境中。这样，无论在哪台机器上构建，结果都一致，从而实现可复现。

封闭式构建的价值与优势

封闭式构建能够减少因环境差异导致的二进制文件差异，其主要原因包括：

二进制文件中与系统相关的嵌入内容：
　- 时间戳，编译时间不同会导致二进制文件差异。
　- RPATH（运行时库路径），路径硬编码进二进制文件，与环境相关。
　- GNU_BUILD_ID（构建标识）。
　- 含有构建路径、配置标志等信息的字符串或调试信息。
　- 反映构建系统的字符串，不同系统会导致文件差异。
　- 代码生成差异（例如 flex 的 #line 指令），不同版本的生成工具会导致结果不同。
依赖项和工具的版本不同，依赖库或编译工具版本差异会影响二进制文件生成。

封闭式构建虽然不能完全保证结果一致，但通常能够提升二进制文件的可重现性，避免环境污染对构建结果的干扰，并能够生成包含或静态的软件包。

密封构建是实现可复现构建的重要前提，也有助于防止环境污染，确保在任何地方都能生成一致、干净的二进制文件。如果能够进一步实现自包含的二进制文件，就可以明确知道软件不依赖外部库，从而避免因环境不同导致的差异。

Debian 的可重现构建，名副其实吗？

Debian 的 sid 分支中，大多数软件包已实现可重现构建，前提是构建路径和环境完全固定且事先定义清楚参考：https://wiki.debian.org/ReproducibleBuilds

对于 PostgreSQL 来说，情况并不完全相同。即便 Debian 的 PostgreSQL 安装包能够在特定条件下复现，普通用户在非标准环境中仍无法轻松生成与官方完全一致的二进制文件。换言之，构建路径、环境和依赖必须严格控制，否则无法保证复现性。

Postgres 源代码：在“一台黄金服务器”上打包生成

图片3.png

官方 PostgreSQL 源代码包的生成依赖于项目组的特定服务器，只有极少数开发者可以访问。这意味着，虽然源代码公开，但能够生成官方发布的、逐字节一致的源代码包的人非常有限。

这种集中式的打包方式限制了源代码的可验证性。如果构建环境能够实现密封化和隔离化，任何人都可以生成与官方一致的源代码包，从而提升 PostgreSQL 的安全性和可追溯性。

自举式构建

构建系统中有一个被称为“自举式构建（Bootstrapable Builds）”的概念，它探讨的是一个类似“先有鸡还是先有蛋”的问题。以编译器为例，构建一个编译器通常需要另一个已经存在的编译器来完成。那么，这个“最初的编译器”又是如何产生的？

自举式构建正是为了解决这一问题——通过从一个极小、可人工验证且可信的软件片段开始，逐步构建出完整系统。这样可以在整个构建过程中防止恶意代码注入，确保生成的软件完全可验证、可复现。

Guix：实现纯源码自举的方案

以 GNU Guix 为代表的部分自由软件项目，正在尝试实现“纯源码自举”方案。其思路是从一个极简的可信工具集出发，例如一个仅具备最基本功能的小型编译器，用它构建出稍复杂的编译工具，再逐步编译出 make、configure 等基础工具，接着构建早期版本的 GCC 2.95，最后再由该编译器生成现代版本的 GCC 以及用于编译 PostgreSQL 等软件的完整工具链。

通过这种方式，整个软件栈的构建路径都可被验证，且不依赖任何外部二进制环境，实现从源码到最终系统的完全可追溯和可控构建过程。

图片4.png

但目前，纯自举构建仍是一个理想目标，但这一方向的研究与实践正在持续推进。

Postgres 发行版：加强安全保障

将可复现与封闭式构建的理念应用于 PostgreSQL 发行版，可在构建过程中实现结果一致与环境可控，从而进一步提升系统的安全性与可信度。这一方向正成为发行版安全保障体系的重要发展路径。

SBOM

软件物料清单（SBOM，Software Bill of Materials）是一份记录代码库中所有开源和第三方组件的清单，列明各组件的版本、许可协议、补丁状态及依赖关系。其作用类似制造业中的物料清单：如同飞机制造中明确列出零部件的型号与数量，SBOM 列出了软件构建所需的全部依赖库及其来源信息。

在 PostgreSQL 发行版中，建立完整的 SBOM 能够实现组件可追溯，便于识别依赖库版本及其安全状态，例如确认是否使用了存在漏洞的特定库版本。

SBOM 的安全价值

SBOM 的应用能够在多个层面强化软件供应链安全：

提供合规与审计依据，确保组件使用符合法律与开源许可要求。
辅助防范与识别供应链攻击，提升整体可追溯性。
满足监管要求。2021 年 5 月，美国白宫发布行政命令，要求所有政府机构及承包商在软件交付中提供 SBOM，以确立安全透明的供应链标准。

随着全球供应链安全治理的加强，SBOM 正逐步成为软件交付与安全保障体系中的关键组成部分。

SBOM示例

这是一个 SBOM 示例，本质上是一个 JSON 文件，用于列出所有依赖项及其版本等信息。

图片5.png

可验证的 SBOM

可验证的 SBOM 是通过可复现构建生成的清单，能够对软件构建过程进行完整审查和验证。单独提供二进制文件和 SBOM 并不足以保证安全，关键在于能够在可复现、密封的环境中重新生成 SBOM，从而确认其真实性。

这种方式不仅提升供应链透明度和信任度，还为合规审计提供依据，帮助企业验证组件符合许可和安全要求，实现 PostgreSQL 发行版的安全可控。

数字签名的（容器）镜像

容器镜像可以进行数字签名，以验证软件包的作者身份。SBOM 同样可以进行数字签名。二者结合能够形成完整的验证闭环，从作者身份到组件来源，再到供应链的可靠性，实现端到端的安全保障。

在分发软件时，使用数字签名的容器镜像能够提升安全性。与单独签名安装包相比，容器镜像的生态更成熟，现有工具可直接进行签名和验证，使签名操作高效且可靠。

自动漏洞（CVE）扫描

容器镜像能够方便地进行自动化安全扫描，以识别潜在漏洞。在容器镜像的构建过程中，应当包含漏洞扫描环节，并可实现完全自动化。

大多数漏洞检测工具通过安装包指纹来识别漏洞，但如果提供可信的 SBOM，工具可以直接分析 SBOM 中列出的依赖版本，从而准确判断软件所使用组件的安全状态，提升检测效率和可靠性。

从技术到发行版的整合

前文介绍了可复现构建、密封构建、SBoM、数字签名镜像等多个技术点。结合这些原则，可以构建一个遵循安全和可控标准的 PostgreSQL 发行版，即“Monogres”项目。

Monogres

Monogres 是 PostgreSQL 的单体仓库（Monorepo），将 PostgreSQL 本体、扩展和衍生版本统一集中管理。单体仓库的核心价值在于创建连贯的软件构建环境，确保所有代码使用相同的库和构建系统，并能够一次性完成构建。

Monogres：目标

Monogres 的目标是建立一个集中式仓库，用于索引、构建和打包 PostgreSQL 及其所有扩展。通过单体仓库，能够实现完全密封、可复现的构建，并为下游发行版提供上游源代码和构建脚本。用户可以在任意环境中生成逐字节一致的二进制文件，并通过 SBoM 完整追溯构建过程和依赖。

Monogres：开源上游发行版

Monogres 旨在建立一个安全、可控的上游发行版，核心原则是从源代码开始，以完全封闭且可复现的方式构建整个 PostgreSQL 生态及其扩展。主要特点包括：

采用完全封闭且可复现的构建流程，确保构建结果一致且可验证。
Monogres 以 Apache 2.0 许可证开源，便于下游使用与扩展。
作为上游发行版，允许下游衍生版本复用并重新打包。
提供二进制版本，同时可能提供源码发行版以便审计和构建。

Monogres 与 Bazel：二选其一

为了实现可复现、密封构建，Monogres 使用 Bazel 作为构建工具。Bazel 是由 Google 开源的成熟构建系统，设计原则强调可复现性和构建正确性，适用于管理大型项目及多版本构建。通过 Bazel，Monogres 能够统一编译 PostgreSQL 本体和扩展，确保构建结果在不同环境中保持一致。

图片6.png

下一步计划

将 Monogres 仓库开源，提供完整的源代码及构建脚本。
开发 Monobot 自动化工具，用于生成扩展和版本的 repo.json 文件，实现构建自动化。
添加更多扩展，目前已包含所有 contrib 扩展及部分 PGXS 扩展。
支持多版本 glibc 和多个 PostgreSQL 衍生分支，包括 Babelfish、IvorySQL、OrioleDB、OpenHalo、PgEdge 等。
确保衍生版本与扩展兼容性，通过自动化构建验证每个扩展在各衍生版本上的适用性。

结语

开源 PostgreSQL 的价值不仅在于源代码公开，更在于运行结果的可验证性。然而，不同来源、不同构建环境生成的二进制文件可能存在显著差异，使得最终软件的安全性和可靠性难以确认。建立可靠的构建和分发体系，确保软件从源代码到运行环境的全程可控和可追溯，是提升供应链安全和软件可信度的关键。这不仅让企业和开发者能够更安心地使用开源软件，也为 PostgreSQL 的生态发展提供了坚实的基础。