## SQLCipher SQLCipher 是 [SQLite](https://www.sqlite.org/) 数据库库的一个独立分支，它在数据库文件和其他功能上增加了 256 位 AES 加密，例如： - 实时加密 - 篡改检测 - 内存清理 - 强密钥派生 SQLCipher 基于 SQLite，并且会定期集成上游稳定版本的功能。虽然 SQLCipher 被维护为独立的源码树，但尽可能减少对核心 SQLite 代码的修改。 SQLCipher 由 Zetetic, LLC 维护，更多信息与文档请访问官方 [SQLCipher 网站](https://www.zetetic.net/sqlcipher/)。 ## 功能特性 - 快速性能，加密操作的开销仅为 5-15% - 数据库文件中的 100% 数据被加密 - 良好的安全实践（CBC 模式、HMAC、密钥派生） - 零配置和应用层加密 - 支持多种加密提供程序 ## 兼容性 SQLCipher 在同一主版本号内保持数据库格式兼容，因此任何平台上的应用都可以打开由其他应用创建的数据库，前提是两者使用相同的主版本号。然而，主版本更新（例如从 3.x 到 4.x）通常会更改默认设置。这意味着新主版本的 SQLCipher 默认无法打开旧版本创建的数据库，除非使用特殊设置。例如，SQLCipher 4 引入了许多新的性能与安全增强，新的默认算法、增加的关键派代迭代次数以及更大的页大小意味着 SQLCipher 4 默认无法打开 SQLCipher 1.x、2.x 或 3.x 创建的数据库。应用需要迁移旧数据库以使用新格式，或启用特殊的向后兼容模式。可用选项在 SQLCipher 的 [升级文档](https://discuss.zetetic.net/t/upgrading-to-sqlcipher-4/3283) 中有详细说明。 SQLCipher 也兼容标准 SQLite 数据库。如果未提供密钥，SQLCipher 的行为与标准 SQLite 库相同。也可以使用 [ATTACH 和 sqlcipher_export() 便捷函数](https://discuss.zetetic.net/t/how-to-encrypt-a-plaintext-sqlite-database-to-use-sqlcipher-and-avoid-file-is-encrypted-or-is-not-a-database-errors/868) 将明文数据库（标准 SQLite）转换为加密的 SQLCipher 数据库。 ## 贡献 SQLCipher 团队欢迎对核心库做出贡献。所有贡献（包括拉取请求与补丁）都应基于 `prerelease` 分支，并且必须附带 [贡献者协议](https://www.zetetic.net/contributions/)。我们强烈建议在开发与提交前先进行 [讨论](https://discuss.zetetic.net/c/sqlcipher)。 ## 编译 编译 SQLCipher 与编译常规的 SQLite 源码类似，但有几个小的区别。你必须： 1. 定义 `SQLITE_HAS_CODEC` 2. 定义 `SQLITE_TEMP_STORE=2` 或 `SQLITE_TEMP_STORE=3`（或使用 `configure` 的 `--with-tempstore=yes` 选项） 3. 定义 `SQLITE_EXTRA_INIT=sqlcipher_extra_init` 和 `SQLITE_EXTRA_SHUTDOWN=sqlcipher_extra_shutdown` 4. 定义 `SQLITE_THREADSAFE` 为 `1` 或 `2`（`configure` 会自动启用） 5. 编译并链接一个支持的加密提供程序（OpenSSL、LibTomCrypt、CommonCrypto/Security.framework 或 NSS） 以下示例使用 OpenSSL，这是大多数 Unix 类系统上 readily available 的提供程序。请注意，在此示例中，`--with-tempstore=yes` 设置了 `SQLITE_TEMP_STORE=2`，并且 `SQLITE_THREADSAFE` 默认值为 `1`。 ``` $ ./configure --with-tempstore=yes CFLAGS="-DSQLITE_HAS_CODEC -DSQLITE_EXTRA_INIT=sqlcipher_extra_init -DSQLITE_EXTRA_SHUTDOWN=sqlcipher_extra_shutdown" \ LDFLAGS="-lcrypto" $ make ``` ## 测试 完整 SQLite 测试套件在使用 SQLCipher 时无法全部成功完成，因为加密会干扰需要访问数据库文件数据或 SQLCipher 不支持的功能的低级测试。这些测试是为非 SQLCipher 实现设计的。此外，由于 SQLite 测试并非完全隔离，一个测试失败可能引发后续步骤的连锁错误。 因此，SQLCipher 包包含其自身的独立测试，用于验证 SQLCipher 扩展的核心功能。该测试套件旨在提供 SQLCipher 内部逻辑的简要验证；它不会执行整个 SQLite 数据库系统的详尽测试，也不会验证特定平台上的功能。因为 SQLCipher 基于稳定的 SQLite 上游版本，可以合理假设核心 SQLite 库代码运行正常（SQLCipher 核心几乎未作修改）。因此，额外的 SQLCipher 特定测试提供了在启用安全功能的情况下库按预期运行所需的必要验证。 要运行 SQLCipher 特定测试，请按此处说明配置，然后运行以下命令执行测试并获取结果报告： ``` $ ./configure --with-tempstore=yes --enable-fts5 CFLAGS="-DSQLITE_HAS_CODEC -DSQLITE_EXTRA_INIT=sqlcipher_extra_init -DSQLITE_EXTRA_SHUTDOWN=sqlcipher_extra_shutdown -DSQLCIPHER_TEST" \ LDFLAGS="-lcrypto" $ make testfixture $ ./testfixture test/sqlcipher.test ``` ## 加密数据库 要通过 SQL 接口为数据库指定加密密码，请使用 PRAGMA。你输入的密码会通过 PBKDF2 密钥派生，以 获取数据库的加密密钥 ``` PRAGMA key = 'passphrase'; ``` 或者，你可以使用 blob 字面量指定精确的字节序列。如果使用此方法，你需要确保提供的数据是一个 64 字符的十六进制字符串，它将被直接转换为 32 字节（256 位）的密钥数据而不进行密钥派生。 要通过编程方式加密数据库，可以使用 `sqlite3_key` 函数。`pKey` 中提供的数据会根据与 `PRAGMA key` 相同的规则转换为加密密钥。 `PRAGMA key` 或 `sqlite3_key` 应在打开数据库后作为第一个操作调用。 ## 更改数据库密钥 要更改现有数据库的加密密码，可以使用重新密钥 PRAGMA，在提供正确的数据库密码后执行； ``` PRAGMA key = 'passphrase'; -- start with the existing database passphrase PRAGMA rekey = 'new-passphrase'; -- rekey will reencrypt with the new passphrase ``` 也可以使用十六进制重新密钥 PRAGMA 重新密钥为特定的二进制值 ``` PRAGMA rekey = "x'2DD29CA851E7B56E4697B0E1F08507293D761A05CE4D1B628663F411A8086D99'"; ``` 这可以通过编程方式使用 sqlite3_rekey 完成； ``` sqlite3_rekey(sqlite3 *db, const void *pKey, int nKey) ``` ## 支持 完整的文档（设计、API、平台、使用）请访问 SQLCipher 官方网站： https://www.zetetic.net/sqlcipher/documentation 支持与讨论的主要途径是 SQLCipher 讨论网站： https://discuss.zetetic.net/c/sqlcipher 关于使用 SQLCipher 的问题或错误报告应提交至： GitHub 问题追踪器： https://github.com/sqlcipher/sqlcipher/issues 请不要在关于 SQLCipher 的博客文章中发布问题、支持请求或其他问题，因为我们不会频繁监控它们。 如果你在自己的软件中使用 SQLCipher，请告知我们： support@zetetic.net! ## 社区版开源许可证 Copyright (c) 2025, ZETETIC LLC 保留所有权利。 在满足以下条件的情况下，允许以源代码和二进制形式重新分发和使用本软件： * 重新分发源代码必须保留上述版权声明、条件列表以及以下免责声明。 * 重新分发二进制形式必须保留上述版权声明、条件列表以及以下免责声明。 * 不得使用 ZETETIC LLC 的名称或其贡献者名称来为衍生产品背书或推广，除非获得明确的书面许可。 本软件按“原样”提供，不附带任何明示或暗示的担保，包括但不限于对适销性、特定用途适用性和非侵权的暗示担保。在任何情况下，ZETETIC LLC 均不对任何直接、间接、偶然、特殊、示范性或后果性损害（包括但不限于替代商品或服务的采购、使用损失、数据或利润损失，或业务中断）承担责任，无论其责任理论是合同、严格责任还是其他理论，即使已被告知可能发生此类损害。 # 开始 SQLite README.md

SQLite 源代码仓库

本仓库包含 [SQLite 数据库引擎](https://sqlite.org/) 的完整源代码，包括 许多测试。更多测试和大部分文档 是单独管理的。 有关 SQLite 的更多信息以及它如何工作，请参阅 [在线文档](https://sqlite.org/) 。本 README 文件关注的是用于构建 SQLite 的源代码， 而不是如何使用 SQLite。 ## 版本控制 SQLite 源码使用 [Fossil](https://fossil-scm.org/) 进行版本控制，这是一个专门为 SQLite 开发设计的分布式版本控制系统。 [ Fossil 仓库](https://sqlite.org/src/timeline) 包含原始版本（urtext）。 如果你在 GitHub 或其他 Git 仓库或服务上阅读此内容，你看到的是镜像。Git 镜像中的检入名称和其他工件与官方版本不同。官方检入名称可以在检入注释的页脚找到。 官方检入名称也可以在根目录的 `manifest.uuid` 文件中找到。始终使用官方名称，而不是 Git 名称，来进行关于 SQLite 检入的沟通。 如果你从次要来源拉取了 SQLite 源码并希望验证其完整性，可以在 [验证代码真实性](#vauth) 部分找到相关提示。 ## 联系 SQLite 开发者 询问或评论关于 SQLite 或报告 SQLite 错误的首选方式是访问 [SQLite 论坛](https://sqlite.org/forum) ，网址为 。 允许匿名发帖。 如果你认为你发现了具有安全影响的错误，并且不想在公共论坛上报告，可以向 drh at sqlite dot org 发送私人邮件。 ## 公共领域 SQLite 源代码属于公共。详细信息请参见 。因为 SQLite 属于公共领域，我们通常不接受拉取请求，因为如果接受了拉取请求，该请求中的更改可能带有版权，从而使 SQLite 源代码不再完全属于公共领域。 ## 获取 SQLite 源代码 源代码 tar 包或 ZIP 存档可在以下位置获取： * [最新主干检入](https://sqlite.org/src/rchvdwnld/trunk)。 * [最新发布版本](https://sqlite.org/src/rchvdwnld/release) * 对于其他检入，可以浏览 [项目时间线](https://sqlite.org/src/timeline?y=ci) 并点击你希望下载的检入哈希值。 在生成的“信息”页面中，点击“**下载：**”标签右侧的选项之一 以获取源代码。 要直接使用 [Fossil](https://fossil-scm.org/home) 获取源代码， 首先安装 Fossil 版本 2.0 或更高版本。 源代码 tar 包和 Fossil 预编译二进制文件可在 获取。Fossil 是一个独立程序。安装时，只需下载或编译单个可执行文件，并将其放入你的 `$PATH` 或 `%PATH%`。 然后运行以下命令： ``` mkdir -p ~/sqlite cd ~/sqlite fossil open https://sqlite.org/src ``` 初始的 `fossil open` 命令将耗时两到三分钟。之后， 你可以快速、带宽高效地更新任意版本的 SQLite。示例如下： ``` fossil update trunk ;# latest trunk check-in fossil update release ;# latest official release fossil update trunk:2024-01-01 ;# First trunk check-in after 2024-01-01 fossil update version-3.39.0 ;# Version 3.39.0 ``` 或者输入 `fossil ui` 以获取基于 Web 的用户界面。 ## 在 Unix-like 系统上编译 首先创建一个用于存放 构建产物的目录。推荐（但非必需）将该目录与源码目录分开。进入构建目录后，运行源码树根目录下的 `configure` 脚本。然后运行 `make`。 例如： ``` apt install gcc make tcl-dev ;# Make sure you have all the necessary build tools tar xzf sqlite.tar.gz ;# Unpack the source tree into "sqlite" mkdir bld ;# Build will occur in a sibling directory cd bld ;# Change to the build directory ../sqlite/configure ;# Run the configure script make sqlite3 ;# Builds the "sqlite3" command-line tool make sqlite3.c ;# Build the "amalgamation" source file make sqldiff ;# Builds the "sqldiff" command-line tool # Makefile targets below this point require tcl-dev make tclextension-install ;# Build and install the SQLite TCL extension make devtest ;# Run development tests make releasetest ;# Run full release tests make sqlite3_analyzer ;# Builds the "sqlite3_analyzer" tool ``` 请参考 Makefile 获取更多目标选项。对于调试构建，核心开发者通常运行如下 `configure` 选项： ``` ../sqlite/configure --enable-all --enable-debug CFLAGS='-O0 -g' ``` 对于发布构建，核心开发者通常执行： ``` ../sqlite/configure --enable-all ``` 几乎所有 makefile 目标都需要 `tclsh` TCL 解释器版本 8.6 或更高版本。`tclextension-install` 目标以及后续的测试目标还需要 TCL 开发库（`apt install tcl-dev`）。安装 SQLite TCL 扩展（`tclextension-install`）有助于但不是必需运行测试。`releasetest` 目标还需要 `valgrind`。 在命令行中使用 `make` 时，可以添加 `OPTIONS=...` 来指定额外的编译时选项。例如，要编译时忽略已弃用的功能，可以执行： ``` ./configure --enable-all make OPTIONS=-DSQLITE_OMIT_DEPRECATED sqlite3 ``` configure 脚本使用 autoconf 2.61 和 libtool。如果 configure 脚本不适用于你，可以复制并编辑顶级目录中的通用 makefile 文件 `Makefile.linux-gcc` 以满足你的需求。通用 makefile 中的注释说明了需要做哪些更改。 ## 在 Windows 上使用 MSVC 编译 在 Windows 上，所有内容都可以使用 MSVC 编译。 你还需要一个可用的 TCL 安装，如果要运行测试的话。 如果只构建 SQLite 本身，则不需要 TCL。 请参见 [compile-for-windows.md](doc/compile-for-windows.md) 文档以获取更多关于如何安装 MSVC 和 TCL 以及配置构建环境的详细信息。 如果需要运行测试，你需要让 SQLite 知道你的 TCL 库位置，示例如下： ``` set TCLDIR=c:\Tcl ``` SQLite 在构建过程中使用 `tclsh.exe`，因此该程序需要位于你的 `%PATH%` 中。SQLite 本身不包含任何 TCL 代码，但它使用 TCL 来运行测试。 你可能需要安装 TCL 开发库才能成功完成某些 makefile 目标。 建议（但非必需）在运行测试前安装 SQLite TCL 扩展（`tclextension-install`）目标。 使用 Makefile.msc 构建。示例： ``` nmake /f Makefile.msc sqlite3.exe nmake /f Makefile.msc sqlite3.c nmake /f Makefile.msc sqldiff.exe # Makefile targets below this point require TCL development libraries nmake /f Makefile.msc tclextension-install nmake /f Makefile.msc devtest nmake /f Makefile.msc releasetest nmake /f Makefile.msc sqlite3_analyzer.exe ``` Makefile.msc 中还有许多其他目标。请参见 Makefile.msc 中的注释以获取详细信息。 与 Unix Makefile 一样，可以通过在 nmake 命令行上传递 `OPTIONS=...` 来启用新的编译时选项。例如： ``` nmake /f Makefile.msc OPTIONS=-DSQLITE_OMIT_DEPRECATED sqlite3.exe ``` ## 源代码树结构 * **src/** - 主要包含 SQLite 核心源代码。测试代码也以 `test` 开头放在此处。TCL 接口文件 `tclsqlite3.c` 和 `tclsqlite3.h` 也在此目录，但不属于核心部分。 * **test/** - 包含用于测试的代码。扩展名为 `.test` 的文件是运行测试的 TCL 脚本，使用名为 "testfixture" 的增强 TCL 解释器执行。使用命令 `make testfixture`（Unix）或 `nmake /f Makefile.msc testfixture.exe`（Windows）构建该解释器，然后运行类似 `testfixture test/main.test` 的命令执行单个测试。该目录还包含其他 C 代码模块和脚本用于其他类型的测试。 * **tool/** - 包含用于构建部分自动生成代码的程序和脚本，以及构建和运行测试的工具。 [Lemon 解析器生成器](./doc/lemon.html) 的源代码位于此目录。还有用于构建和/或转换源代码文件的 TCL 脚本。例如，tool/mksqlite3h.tcl 读取 src/sqlite.h.in 文件并用它构建可交付的 "sqlite3.h" 文件。 * **ext/** - 此目录包含各种 SQLite 扩展。例如，FTS5 子系统在 "ext/fts5/" 中。其中一些扩展（如 FTS3/4、FTS5、RTREE）可能会被编译进 SQLite 合并文件，但不是全部。`ext/misc/` 子目录包含多种单一文件扩展，许多未包含在 SQLite 核心，但包含在 [SQLite CLI](https://sqlite.org/cli.html) 中。 * **doc/** - 包含有关 SQLite 内部的一些文档文件。请注意，主要面向应用开发人员和用户使用 SQLite 的文档位于完全独立的仓库中。请注意，主要的 API 文档是从 src/sqlite.h.in 文件中的特殊注释派生的。 ### 自动生成的源文件 SQLite 中有几个 C 语言源文件是自动生成的，而不是由程序员手动编写的。本节将总结这些自动生成的文件。要创建所有自动生成的文件，只需运行 `make target_source`。 `target_source` 目标会将 `tsrc/` 子目录创建并填充所有构建 SQLite 所需的源文件，包括手动编辑的文件和自动生成的文件。 SQLite 接口由 **sqlite3.h** 头文件定义，该文件从 src/sqlite.h.in、./manifest.uuid 和 ./VERSION 生成。Tcl 脚本 tool/mksqlite3h.tcl 执行转换。 manifest.uuid 文件包含该特定检入的 SHA3 哈希值，用于生成 SQLITE_SOURCE_ID 宏。VERSION 文件包含当前 SQLite 版本号。sqlite3.h 头文件实际上是 src/sqlite.h.in 的副本，其中插入了 source-id 和版本号。请注意，sqlite3.h 文件中的注释文本用于生成大部分 SQLite API 文档。生成这些文档的 Tcl 脚本位于单独的源代码仓库中。 SQL 语言解析器是 **parse.c**，它由 src/parse.y 文件中的 LALR(1) 语法生成。parse.y 到 parse.c 的转换由 [Lemon](./doc/lemon.html) LALR(1) 解析器生成器完成。Lemon 的源代码位于 tool/lemon.c。Lemon 使用 tool/lempar.c 文件作为生成解析器的模板。 **opcodes.h** 头文件包含定义 "VDBE" 虚拟机操作码编号的宏。该文件通过扫描 src/vdbe.c 源文件生成。Tcl 脚本 ./mkopcodeh.tcl 执行此扫描并生成 opcodes.h。 第二个 Tcl 脚本 ./mkopcodec.tcl 扫描 opcodes.h 以生成 **opcodes.c** 源文件，其中包含用于 EXPLAIN 输出的操作码编号到名称的反向映射。 **keywordhash.h** 头文件包含一个哈希表，用于将 SQL 语言关键字（如 "CREATE"、"SELECT"、"INDEX" 等）映射到 parse.c 解析器使用的数字代码。该文件由工具中的 C 程序 tool/mkkeywordhash.c 生成。 **pragma.h** 头文件包含用于解析和实现 PRAGMA 语句的各种定义。该头文件由脚本 **tool/mkpragmatab.tcl** 生成。如果要添加新的 PRAGMA，请编辑 **tool/mkpragmatab.tcl** 文件以插入解析新 PRAGMA 所需的信息，然后运行该脚本以重新生成 **pragma.h** 头文件。 ### 合并文件 所有独立的 C 源文件和头文件（手动编辑和自动生成）都可以合并为一个大的源文件 **sqlite3.c**，称为"合并文件"。合并文件是推荐的使用 SQLite 的方式，因为它允许 C 编译器执行更多的跨分析并生成更好的代码。SQLite 从合并文件编译时比从单独源文件编译快约 5%。 合并文件由工具 **mksqlite3c.tcl** 生成。首先，将所有独立的源文件收集到 **tsrc/** 子目录中（相当于执行 "make target_source"），然后运行 **tool/mksqlite3c.tcl** 脚本以按正确顺序复制它们，同时解析内部的 "#include" 引用。 合并文件超过 200K 行。一些符号调试器（尤其是 MSVC）无法处理超过 64K 行的文件。为解决此问题，单独的 Tcl 脚本 **tool/split-sqlite3c.tcl** 可以将合并文件拆分为一个小的 C 文件 **sqlite3-all.c** 和大约七个名为 **sqlite3-1.c**、**sqlite3-2.c**、...、**sqlite3-7.c** 的文件。这样，所有源代码都包含在一个翻译单元中，使编译器能够进行额外的跨过程优化，而不会使任何单个源文件超过 32K 行。 ## 各部分如何协同工作 SQLite 的设计是模块化的。 请参阅 [架构描述](https://sqlite.org/arch.html) 获取详细信息。其他有助于理解 SQLite 工作方式的文档包括： [文件格式](https://sqlite.org/fileformat2.html) 描述， [虚拟机](https://sqlite.org/opcode.html) （用于运行预处理语句）， [事务工作原理](https://sqlite.org/atomiccommit.html) 的描述，以及 [查询规划器概述](https://sqlite.org/optoverview.html)。 几十年的努力已经投入到优化 SQLite 中，既为了小体积也为了高性能。优化往往导致代码复杂。因此，当前 SQLite 实现包含大量复杂性。它可能不是世界上最容易修改的库。 ### 关键源代码文件 * **sqlite.h.in** - 此文件定义了 SQLite 库的公共接口。在尝试理解库内部工作原理之前，读者需要熟悉此接口。该文件实际上是一个模板，通过 makefile 调用的脚本将其转换为可交付的 "sqlite3.h"。 * **sqliteInt.h** - 此头文件定义了 SQLite 内部使用的许多数据对象。此外，SQLite 的某些子系统拥有自己的头文件。这些内部接口不供应用程序使用。它们可能随每个 SQLite 版本更改。 * **parse.y** - 此文件描述了 SQLite 用于解析 SQL 语句的 LALR(1) 语法以及每个步骤采取的动作。该文件由 [Lemon 解析器生成器](./doc/lemon.html) 处理以生成实际的 C 代码用于解析。 * **vdbe.c** - 此文件实现了运行预处理语句的虚拟机。有各种名称以 "vdbe" 开头的辅助文件。VDBE 有访问 vdbeInt.h 头文件的权限，其中定义了内部数据对象。SQLite 的其余部分通过 vdbe.h 定义的接口与 VDBE 交互。 * **where.c** - 此文件（及其辅助文件 named "where*.c"）分析 WHERE 子句并生成用于高效运行查询的虚拟机代码。此文件有时称为"查询优化器"。它拥有自己的私有头文件 whereInt.h，定义内部使用的数据对象。 * **btree.c** - 此文件包含 SQLite 使用的 B-Tree 存储引擎的实现。其接口由 "btree.h" 定义。"btreeInt.h" 头文件定义了 btree.c 内部使用的对象，不会发布给系统其余部分。 * **pager.c** - 此文件包含"pager"实现，即管理事务的模块。"pager.h" 头文件定义了 pager.c 与系统其余部分之间的接口。 * **os_unix.c** 和 **os_win.c** - 这两个文件实现了 SQLite 与底层操作系统之间的接口，使用可插拔的 VFS 接口。 * **shell.c.in** - 此文件不是 SQLite 核心库的一部分。它用于生成 "sqlite3.exe" 命令行 shell，在链接 sqlite3.a 后生成。"shell.c.in" 文件在构建过程中转换为 "shell.c"。 * **tclsqlite.c** - 此文件实现了 SQLite 的 Tcl 绑定。它不是核心 SQLite 库的一部分。但由于此仓库中的大多数测试都是用 Tcl 编写的，因此 Tcl 语言绑定很重要。 * **test\*.c** - 文件中以 "test" 开头的 src/ 文件夹文件用于构建 "testfixture.exe" 程序。testfixture.exe 程序是一个增强的 Tcl shell。testfixture.exe 程序运行 test/ 文件夹中的脚本来验证核心 SQLite 代码。程序（以及一些其他测试程序）是在你输入 "make test" 时构建和运行的。 * **VERSION**, **manifest**, 和 **manifest.uuid** - 这些文件定义了当前 SQLite 版本号。"VERSION" 文件是人工生成的，但 "manifest" 和 "manifest.uuid" 文件由 [Fossil 版本控制系统](https://fossil-scm.org/) 自动生成。 有许多其他源文件。每个文件都有一个简洁的注释头，描述了其用途和在更大系统中的角色。 ## 验证代码真实性 `manifest` 文件位于源代码树的根目录，包含仓库中每个源文件的 SHA3-256 或 SHA1 哈希值。 整个源代码树的版本名称就是 `manifest` 文件本身的 SHA3-256 哈希值，可能在最后一行以 "`# Remove this line`" 开头时会被省略。 `manifest.uuid` 文件应包含 `manifest` 文件的 SHA3-256 哈希值。如果所有上述哈希比较都正确，那么你可以确信你的源码树是真实且未被篡改的。 `manifest` 文件格式的详细信息在 Fossil 网站上可用。 验证源代码真实性的过程由 makefile 自动执行： 或在 Windows 上： 使用 makefile 验证源代码完整性有助于检测对源代码树的意外更改，但恶意更改可能通过同时修改 makefile 来隐藏。 ## 联系方式 SQLite 主页是 [https://sqlite.org/](https://sqlite.org/)， 其地理分布式备份位于 [https://www2.sqlite.org/](https://www2.sqlite.org)、 [https://www3.sqlite.org/](https://www3.sqlite.org)。 请通过 [SQLite 论坛](https://sqlite.org/forum/) 联系 SQLite 开发者。如需紧急情况，可将私人邮件发送至 drh at sqlite dot org。

标签：AES-256, CBC模式, HMAC, SQLCipher, SQLite, Zetetic, 企业级安全, 全盘加密, 兼容升级, 内存清理, 加密数据库, 安全测试工具, 完整性校验, 客户端加密, 密钥派生, 数据库加密, 漏洞评估, 移动端加密, 网络安全, 跨平台数据库, 透明加密, 防篡改, 隐私保护, 零配置加密, 高性能加密